Well, I guess it goes back to the old days of all classes being in
the "default" package. Probably the "default" package was searched
first for classes. If you look at the source with jad/jadclipse (for
educational and debugging purposes only of course), you will see that
WebObjects just searches for any class named "Session" and grabs the
first one it finds.
You may have one Session.java in your project, but there are many
common classes named "Session" and probably one of those other jars
in your classpath (any jar in any framework you use or in /Library/
Java/Extensions or /Library/WebObjects/Extensions) had a *.Session
that was being found before your project's Session.
This "patch" simply looks specifically in the *same* package as your
Application class instead of letting WO do its search everywhere
thing with _NSUtilities.
IMHO, packahe everything and avoid using the dir /Library/WebObjects/
Extensions and /Library/Java/Extensions for WebObjects in your
servers and dev machines. Especially /Library/WebObjects/Extensions
since this is dynamically added to the classpath in deployment on
server but is not in the classpath in Eclipse development. Ideally
try to keep development environment/classpath/conditions the same as
deployment to avoid different behaviour/problems.
Regards, Kieran
On Oct 25, 2007, at 2:13 PM, Fred Shurtleff wrote:
> This did the trick - the app now runs ok. Thank you very much.
>
> But it does raise the question WHY this code is needed when there
> is only one Session file in all the projects I have imported into
> Eclipse. Seems very odd to me.
>
> Fred (see further below)
>
> Kieran Kelleher wrote:
>> Just copy/paste this code below into your Application class and
>> assuming your Session class is in the same package as your
>> Application class, this will solve the WebObjects bad
>> implementation for identifying the Session class
>>
>> private Class _ourSessionClass;
>>
>> /* (non-Javadoc)
>> *..ee com.webobjects.appserver.WOApplication#_sessionClass()
>> * WebObjects searches the classpath and uses the first class
>> it finds with
>> * the name Session ... crazy huh? This ensures that Session
>> from the same package as the
>> * Application class is used
>> */
>> ..verride
>> protected Class _sessionClass()
>> {
>> if (_ourSessionClass == null) {
>> String ourSessionClassName = null;
>> try {
>> ourSessionClassName = getClass().getPackage
>> ().getName() + ".Session";
>> System.out.println("Using " + ourSessionClassName
>> + " as the application's Session class.");
>> _ourSessionClass = Class.forName
>> ( ourSessionClassName );
>> } catch ( Exception e ) {
>> System.err.println( "What have you done with your
>> " + ourSessionClassName + " class?!\n" + e.getStackTrace() );
>> }
>> } //~ if (_ourSessionClass == null)
>> return _ourSessionClass;
>> }
>>
>>
>> HTH, Kieran
>>
>> On Oct 24, 2007, at 12:51 PM, Chuck Hill wrote:
>>
>>> It sounds like you may have a classpath issue and that the
>>> Session class getting loaded is something like java.mail.Session
>>> instead of the Session class in this project.
>>>
>>> Try adding this to the constructor in Main:
>>>
>>> NSLog.out.appendln("Session class is " + session().getClass
>>> ().getName());
>>>
>>> Chuck
>>>
> This statement did not report nothing (that is no fixed text nor
> the Session name). But I don't know why - perhaps I positioned in
> the wrong place (I put it in public Main - right after the super
> (context) statement.
This archive was generated by hypermail 2.0.0 : Thu Oct 25 2007 - 15:36:19 EDT