Classpath
Locked
 
|
... for your info.
And it is NO spam. Tom. -------------- next part -------------- An embedded message was scrubbed... From: Bruce Skelly <[hidden email]> Subject: **** SPAM **** Re: [RexxLA] Ok guys. . . (6.1) Date: Mon, 8 Feb 2010 16:58:45 -0800 Size: 21418 Url: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100209/4adb2d74/RexxLAOkguys...6.1.eml
Tom. (ths@db-123.com)
|
|
|
Thomas,
I think it is your software that is flagging it as SPAM. I checked my outgoing messages, and none of them have SPAM in the Subject line. Bruce On Feb 9, 2010, at 5:51 AM, Thomas Schneider wrote: > ... for your info. > And it is NO spam. > Tom. > > > From: Bruce Skelly <[hidden email]> > Date: February 8, 2010 4:58:45 PM PST > To: RexxLA Members mailing list <[hidden email]> > Subject: **** SPAM **** Re: [RexxLA] Ok guys. . . (6.1) > Reply-To: RexxLA Members mailing list <[hidden email]> > > > Kermit, > > I think that we are on the same page now. The default classpath, > does include a lot of stuff, and yes the current directory is the > last place searched. > > On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote: > >> Bruce ; >> >> My bad, I guess I failed to make it clear that the default >> classpaths include the period (current directory) and that your >> classpath is deleting it which is causing your problem. When you >> "unset" the CLASSPATH you are actually re-adding the current >> directory to the classpath. >> >> Your logic for not setting the CLASSPATH environment variable is >> exactly why the Java developers deprecated it and added the "- >> classpath" operand to all of the Java commands (java, javac, etc). >> >> -- Kermit >> >> Bruce Skelly wrote: >>> >>> See below >>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote: >>> >>>> Bruce ; >>>> >>>> Did you read my note? I am pretty sure that if you use the >>>> correct classpath with a period added for the current directory >>>> as I mentioned in item #3 that you will not need to "unset" the >>>> classpath to execute your program. >>> Kermit, did you read my note. I said that the only change I made >>> was to unset the CLASSPATH. The default CLASSPATH must contain the >>> current directory or some other trickery. Everything else that is >>> java on my machine seems to work just fine *without* a CLASSPATH. >>> I choose just set the CLASSPATH for the duration of the NetRexxC. >>> My concern is that by having a CLASSPATH in the environment, I may >>> cause other things to stop working. I would then be on an endless >>> journey of tweaking my CLASSPATH so that things work. >>>> >>>> BTW: The CLASSPATH environment variable has been "deprecated" >>>> since Java 1.3 and is not recommended for various reasons. The >>>> correct way to call Java is now with a "-classpath" operand which >>>> specifies the path on the command line. That would give you a >>>> much simpler way to specify the classpath differently in the >>>> stages in your shell script. >>>> >>>> -- Kermit >>>> >>>> >>>> Bruce Skelly wrote: >>>>> >>>>> I don't know, we may be saying the same thing. >>>>> >>>>> I do know that even though both classes.jar and NetRexxC.jar are >>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail >>>>> trying to create the '.java' file. That is before the java >>>>> compiler is invoked. In fact, using the -verbose argument to >>>>> java, showed me that many classes were loaded from both .jar >>>>> files. >>>>> >>>>> If I gave it a CLASSPATH that contained just classes.jar, then >>>>> it would fail, looking for a NetRexx class. If I gave it a >>>>> CLASSPATH that contained just NetRexxC.jar, it would fail >>>>> looking for a java class. Specifying both classes.jar and >>>>> NetRexxC.jar would produce a .java file that could then be >>>>> compiled into a .class file. >>>>> >>>>> At that point if I tried to execute the program, i.e. java >>>>> hello.class, it would fail. If I then *unset* the CLASSPATH, I >>>>> could then type java hello.class and it would execute. >>>>> >>>>> I modified the distributed NetRexxC.sh file to do this on Darwin >>>>> systems (Mac OS X), since it appears on my system, CLASSPATH is >>>>> only needed in the translation phase from .nrx to .java. >>>>> ... >>>>> # For Mac OS X with NetRexxC.jar installed in /Library/Java/ >>>>> Extensions >>>>> if [ "`uname`" = "Darwin" ] >>>>> then >>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/Library/ >>>>> Frameworks/JavaVM.framework/Classes/classes.jar >>>>> export CLASSPATH >>>>> fi >>>>> ... >>>>> # Again for Mac OS X; >>>>> if [ "`uname`" = "Darwin" ] >>>>> then >>>>> unset CLASSPATH >>>>> fi >>>>> ... >>>>> >>>>> Bruce >>>>> >>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote: >>>>> >>>>>> Hi Bruce; >>>>>> >>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-) >>>>>> >>>>>> 2) There are three stages to compiling and running a NetRexx >>>>>> program - first the NetRexx translator (NetRexxC) parses your >>>>>> code and converts it to Java code, second the translator calls >>>>>> the Java compiler (javac) to convert the Java code to >>>>>> "bytecode", third the Java virtual machine loads the bytecode, >>>>>> links it and executes it. At each stage a different program is >>>>>> handling your code and each one has to be able to find all the >>>>>> related classes. Sometimes they don't use the same procedure/ >>>>>> path to find things but generally they will all obey the >>>>>> CLASSPATH environment variable. Each program has an internal >>>>>> default classpath but the environment variable willoverridethe >>>>>> internal paths. >>>>>> >>>>>> 3) Solution: When you specify the CLASSPATH, you must include >>>>>> the code directory, usually with a "." (a period) or your >>>>>> program will not be found. Likewise you must include the Java >>>>>> classes and the NetRexx classes because you are overriding the >>>>>> default paths. >>>>>> >>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so >>>>>> Java can find it in it's default path search but that may not >>>>>> help NetRexxC to find the classes it needs. >>>>>> >>>>>> 5) You may find that it is simpler to install the jEdit IDE >>>>>> with NetRexxDE and NetRexxScript plugins to compile and >>>>>> interpret NetRexx code, since the NetRexxC.jar file is >>>>>> automatically installed that way. (You will still need to >>>>>> download the NetRexx zip if you want the samples and docs.) If >>>>>> you wish to use the jEdit environment with the NetRexxScript >>>>>> plugin, be aware that jEdit uses custom classloaders to >>>>>> dynamically load things. Therefore if NetRexxC.jar is in the >>>>>> extensions directory for the Java VM that runs jEdit, >>>>>> NetRexxScript will encounter "invocation" errors when >>>>>> interpreting scripts due to the conflict between multiple >>>>>> classloader versions of the NetRexx classes. >>>>>> >>>>>> Hope some of this info helps, >>>>>> >>>>>> -- Kermit >>>>>> >>>>>> >>>>>> Bruce Skelly wrote: >>>>>>> >>>>>>> If I understand this correctly, after spending some time >>>>>>> playing with it, it isn't really that NetRexx doesn't execute >>>>>>> unless you specify the CLASSPATH. What I *think* is happening >>>>>>> is that the NetRexx Compiler, in the course of generating java >>>>>>> code needs to look at the classes to determine their >>>>>>> dependancies. Kind of like header files in C. After the >>>>>>> compile is complete, the "headers" are no longer needed, and >>>>>>> the compiled NetRexx (java) program runs just fine without the >>>>>>> CLASSPATH. >>>>>>> >>>>>>> Please note in my messages, that NetRexxC was executing, but >>>>>>> issuing error messages stating that it couldn't find things >>>>>>> (classes). Also, my compiled NetRexx program executes just >>>>>>> fine when I unset CLASSPATH, so it can find both the NetRexx >>>>>>> runtime, and the Java runtime. >>>>>>> >> >> _______________________________________________ >> rexxla-members mailing list --mailto:[hidden email] >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members > > _______________________________________________ > rexxla-members mailing list -- mailto:[hidden email] > http://rice.safedataisp.net/mailman/listinfo/rexxla-members > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://ns.hursley.ibm.com/pipermail/ibm-netrexx/attachments/20100209/3a0ca1a2/attachment-0001.html |
**** SPAM **** Re: [Ibm-netrexx] Classpath (6.1)
|
|
I do have a licensed (paid) Copy of SPAM-Fighter ...
No idea where those ***SPAM*** previxes do come from. I'm getting some 40-100 mails by day. Sorry. Tom. ================================================= Bruce Skelly schrieb: > Thomas, > > I think it is your software that is flagging it as SPAM. I checked my > outgoing messages, and none of them have SPAM in the Subject line. > > Bruce > On Feb 9, 2010, at 5:51 AM, Thomas Schneider wrote: > >> ... for your info. >> And it is NO spam. >> Tom. >> >> >> *From: *Bruce Skelly <[hidden email] >> <mailto:[hidden email]>> >> *Date: *February 8, 2010 4:58:45 PM PST >> *To: *RexxLA Members mailing list <[hidden email] >> <mailto:[hidden email]>> >> *Subject: ****** SPAM **** Re: [RexxLA] Ok guys. . . (6.1)* >> *Reply-To: *RexxLA Members mailing list >> <[hidden email] <mailto:[hidden email]>> >> >> >> Kermit, >> >> I think that we are on the same page now. The default classpath, >> does include a lot of stuff, and yes the current directory is the >> last place searched. >> >> On Feb 8, 2010, at 12:27 PM, Kermit Kiser wrote: >> >>> Bruce ; >>> >>> My bad, I guess I failed to make it clear that the default >>> classpaths include the period (current directory) and that your >>> classpath is deleting it which is causing your problem. When you >>> "unset" the CLASSPATH you are actually re-adding the current >>> directory to the classpath. >>> >>> Your logic for not setting the CLASSPATH environment variable is >>> exactly why the Java developers deprecated it and added the >>> "-classpath" operand to all of the Java commands (java, javac, etc). >>> >>> -- Kermit >>> >>> Bruce Skelly wrote: >>>> See below >>>> On Feb 8, 2010, at 11:50 AM, Kermit Kiser wrote: >>>> >>>>> Bruce ; >>>>> >>>>> Did you read my note? I am pretty sure that if you use the correct >>>>> classpath with a period added for the current directory as I >>>>> mentioned in item #3 that you will not need to "unset" the >>>>> classpath to execute your program. >>>> Kermit, did you read my note. I said that the only change I made >>>> was to unset the CLASSPATH. The default CLASSPATH must contain the >>>> current directory or some other trickery. Everything else that is >>>> java on my machine seems to work just fine *without* a CLASSPATH. I >>>> choose just set the CLASSPATH for the duration of the NetRexxC. My >>>> concern is that by having a CLASSPATH in the environment, I may >>>> cause other things to stop working. I would then be on an endless >>>> journey of tweaking my CLASSPATH so that things work. >>>>> >>>>> BTW: The CLASSPATH environment variable has been "deprecated" >>>>> since Java 1.3 and is not recommended for various reasons. The >>>>> correct way to call Java is now with a "-classpath" operand which >>>>> specifies the path on the command line. That would give you a much >>>>> simpler way to specify the classpath differently in the stages in >>>>> your shell script. >>>>> >>>>> -- Kermit >>>>> >>>>> >>>>> Bruce Skelly wrote: >>>>>> I don't know, we may be saying the same thing. >>>>>> >>>>>> I do know that even though both classes.jar and NetRexxC.jar are >>>>>> in the default (implicit) CLASSPATH, that NetRexxC would fail >>>>>> trying to create the '.java' file. That is before the java >>>>>> compiler is invoked. In fact, using the -verbose argument to >>>>>> java, showed me that many classes were loaded from both .jar files. >>>>>> >>>>>> If I gave it a CLASSPATH that contained just classes.jar, then it >>>>>> would fail, looking for a NetRexx class. If I gave it a CLASSPATH >>>>>> that contained just NetRexxC.jar, it would fail looking for a >>>>>> java class. Specifying both classes.jar and NetRexxC.jar would >>>>>> produce a .java file that could then be compiled into a .class file. >>>>>> >>>>>> At that point if I tried to execute the program, i.e. java >>>>>> hello.class, it would fail. If I then *unset* the CLASSPATH, I >>>>>> could then type java hello.class and it would execute. >>>>>> >>>>>> I modified the distributed NetRexxC.sh file to do this on Darwin >>>>>> systems (Mac OS X), since it appears on my system, CLASSPATH is >>>>>> only needed in the translation phase from .nrx to .java. >>>>>> ... >>>>>> # For Mac OS X with NetRexxC.jar installed in >>>>>> /Library/Java/Extensions >>>>>> if [ "`uname`" = "Darwin" ] >>>>>> then >>>>>> CLASSPATH=/Library/Java/Extensions/NetRexxC.jar:/System/Library/Frameworks/JavaVM.framework/Classes/classes.jar >>>>>> export CLASSPATH >>>>>> fi >>>>>> ... >>>>>> # Again for Mac OS X; >>>>>> if [ "`uname`" = "Darwin" ] >>>>>> then >>>>>> unset CLASSPATH >>>>>> fi >>>>>> ... >>>>>> >>>>>> Bruce >>>>>> >>>>>> On Feb 8, 2010, at 10:49 AM, Kermit Kiser wrote: >>>>>> >>>>>>> Hi Bruce; >>>>>>> >>>>>>> 1) I don't know much about Mac stuff. (OK, zero ;-) >>>>>>> >>>>>>> 2) There are three stages to compiling and running a NetRexx >>>>>>> program - first the NetRexx translator (NetRexxC) parses your >>>>>>> code and converts it to Java code, second the translator calls >>>>>>> the Java compiler (javac) to convert the Java code to >>>>>>> "bytecode", third the Java virtual machine loads the bytecode, >>>>>>> links it and executes it. At each stage a different program is >>>>>>> handling your code and each one has to be able to find all the >>>>>>> related classes. Sometimes they don't use the same >>>>>>> procedure/path to find things but generally they will all obey >>>>>>> the CLASSPATH environment variable. Each program has an internal >>>>>>> default classpath but the environment variable will*override*the >>>>>>> internal paths. >>>>>>> >>>>>>> 3) Solution: When you specify the CLASSPATH, you must include >>>>>>> the code directory, usually with a "." (a period) or your >>>>>>> program will not be found. Likewise you must include the Java >>>>>>> classes and the NetRexx classes because you are overriding the >>>>>>> default paths. >>>>>>> >>>>>>> 4) You can add NetRexxC.jar to the Java extensions directory so >>>>>>> Java can find it in it's default path search but that may not >>>>>>> help NetRexxC to find the classes it needs. >>>>>>> >>>>>>> 5) You may find that it is simpler to install the jEdit IDE with >>>>>>> NetRexxDE and NetRexxScript plugins to compile and interpret >>>>>>> NetRexx code, since the NetRexxC.jar file is automatically >>>>>>> installed that way. (You will still need to download the NetRexx >>>>>>> zip if you want the samples and docs.) If you wish to use the >>>>>>> jEdit environment with the NetRexxScript plugin, be aware that >>>>>>> jEdit uses custom classloaders to dynamically load things. >>>>>>> Therefore if NetRexxC.jar is in the extensions directory for the >>>>>>> Java VM that runs jEdit, NetRexxScript will encounter >>>>>>> "invocation" errors when interpreting scripts due to the >>>>>>> conflict between multiple classloader versions of the NetRexx >>>>>>> classes. >>>>>>> >>>>>>> Hope some of this info helps, >>>>>>> >>>>>>> -- Kermit >>>>>>> >>>>>>> >>>>>>> Bruce Skelly wrote: >>>>>>>> If I understand this correctly, after spending some time >>>>>>>> playing with it, it isn't really that NetRexx doesn't execute >>>>>>>> unless you specify the CLASSPATH. What I *think* is happening >>>>>>>> is that the NetRexx Compiler, in the course of generating java >>>>>>>> code needs to look at the classes to determine their >>>>>>>> dependancies. Kind of like header files in C. After the compile >>>>>>>> is complete, the "headers" are no longer needed, and the >>>>>>>> compiled NetRexx (java) program runs just fine without the >>>>>>>> CLASSPATH. >>>>>>>> >>>>>>>> Please note in my messages, that NetRexxC was executing, but >>>>>>>> issuing error messages stating that it couldn't find things >>>>>>>> (classes). Also, my compiled NetRexx program executes just fine >>>>>>>> when I unset CLASSPATH, so it can find both the NetRexx >>>>>>>> runtime, and the Java runtime. >>>>>>>> >>> >>> _______________________________________________ >>> rexxla-members mailing list --mailto:[hidden email] >>> http://rice.safedataisp.net/mailman/listinfo/rexxla-members >> >> _______________________________________________ >> rexxla-members mailing list -- mailto:[hidden email] >> http://rice.safedataisp.net/mailman/listinfo/rexxla-members >> >> >> _______________________________________________ >> Ibm-netrexx mailing list >> [hidden email] <mailto:[hidden email]> >> > > ------------------------------------------------------------------------ > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > >
Tom. (ths@db-123.com)
|
|
|
Then SPAM-Fighter is the first place I would look, Tom. See how
aggressive it is being about protecting you from "spam". There is almost always a mechanism by which you can adjust its paranoia down to a workable level of "false positives". You seem to be using the latest version of Thunderbird 2 (Release 3 came out just 20 days ago) which can be set to depend on a specific spam filter, or to use its own adaptive heuristics. I've had pretty good success with both its internal Bayesian filter, as well as having it depend on the evaluation of SpamAssassin. This is set in "Tools->Account Settings...->[email account]->Junk Settings". The false positive may be set by your Internet Service Provider, too. If so, the headers of your incoming email should have a header line indication that. While viewing a note in your Inbox that is flagged as "spam", click "View->Message Source" and look for header lines like "X-Spam..." and "X-Scanned-By:" for clues. There are many things that may trigger a false positive for spam, but a few that might have played a part in this particular case are having many levels of quotation, having the word "***SPAM***" embedded in the text, overuse of emphasis in the form of text highlighting and capitalization, and believe or not, too many uses of words that include "exx". At the very least, you should remove the "Re: ***SPAM***" string from the Subject: line before replying, forwarding, rerouting, etc. -Chip- On 2/9/10 16:08 Thomas Schneider said: > I do have a licensed (paid) Copy of SPAM-Fighter ... > > No idea where those ***SPAM*** previxes do come from. > I'm getting some 40-100 mails by day. Sorry. > Tom. > ================================================= > Bruce Skelly schrieb: >> Thomas, >> >> I think it is your software that is flagging it as SPAM. I checked >> my outgoing messages, and none of them have SPAM in the Subject line. |
The SPAM-Fighter on my machine(s) ....
|
|
Hi Chip,
sorry to say, but I had to *BUY* a SPAM-Fighter License, as obviously some *culprits* did find it nice, to sen *SPAM* to both the www.REXXLA.org and, long years ago, to IBM-NetRexx as well, under my PUBLISHED e-mail address [hidden email] (for years, it's always the same). Hence, I (personally) did get problems. Somebody has thronw me out from IBM-NetRexx, and I have not been able to respond, because (whoever did it) *Did it without **ANY Notification** * to me ... But That's History.... I'm currently busy with other tasks, and I''m happy that I am on this group again... Tom. ======================================================================= Chip Davis schrieb: > Then SPAM-Fighter is the first place I would look, Tom. See how > aggressive it is being about protecting you from "spam". There is > almost always a mechanism by which you can adjust its paranoia down to > a workable level of "false positives". > > You seem to be using the latest version of Thunderbird 2 (Release 3 > came out just 20 days ago) which can be set to depend on a specific > spam filter, or to use its own adaptive heuristics. I've had pretty > good success with both its internal Bayesian filter, as well as having > it depend on the evaluation of SpamAssassin. This is set in > "Tools->Account Settings...->[email account]->Junk Settings". > > The false positive may be set by your Internet Service Provider, too. > If so, the headers of your incoming email should have a header line > indication that. While viewing a note in your Inbox that is flagged > as "spam", click "View->Message Source" and look for header lines like > "X-Spam..." and "X-Scanned-By:" for clues. > > There are many things that may trigger a false positive for spam, but > a few that might have played a part in this particular case are having > many levels of quotation, having the word "***SPAM***" embedded in the > text, overuse of emphasis in the form of text highlighting and > capitalization, and believe or not, too many uses of words that > include "exx". > > At the very least, you should remove the "Re: ***SPAM***" string from > the Subject: line before replying, forwarding, rerouting, etc. > > -Chip- > > On 2/9/10 16:08 Thomas Schneider said: >> I do have a licensed (paid) Copy of SPAM-Fighter ... >> >> No idea where those ***SPAM*** previxes do come from. >> I'm getting some 40-100 mails by day. Sorry. >> Tom. >> ================================================= >> Bruce Skelly schrieb: >>> Thomas, >>> >>> I think it is your software that is flagging it as SPAM. I checked >>> my outgoing messages, and none of them have SPAM in the Subject line. > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > >
Tom. (ths@db-123.com)
|
«
Return to ibm-netrexx
|
1 view|%1 views
| Free forum by Nabble | Edit this page |