Re: Java Client refuses to use Client-Side classes once deployed
Re: Java Client refuses to use Client-Side classes once deployed
- Subject: Re: Java Client refuses to use Client-Side classes once deployed
- From: Pierre Bernard <email@hidden>
- Date: Fri, 22 Jun 2007 15:04:41 +0200
Are you sure you are looking at the JARs cached during the failed
attempt? You might want to clear the cache first.
On the server, the JARs that are downloaded to the client are those
located in WebServerResources. Try unpacking you SSDD/WAR and have a
look inside those JAR files.
Pierre
On Jun 22, 2007, at 1:04 PM, David Avendasora wrote:
On Jun 21, 2007, at 6:03 PM, Johan Henselmans wrote:
On 22-jun-2007, at 0:24, Pierre Bernard wrote:
That's one of the bad things of JavaClient. The little bits that
make it hard to debug. In this instance, JavaClient silently
falls back to EOGenericRecord when it doesn't find the
appropriate class.
You should check the JAR downloaded to the client. Probably your
classes aren't in there. I don't exactly know how XCode works for
this, but there must be some copying that did not take place
during the Deployment build. In XCode this may be a matter of
adding classes to the right target or of adding a file copy build
phase. I use Eclipse - so should you ;-)
Pierre
If you are using WebStart (like any Java app should use), then you
can take a look in your java cace. On a Mac that is in ~/Library/
Caches/Java/cache/javaws/http/ (or any other folders over there).
You might find that not all the jars are downloaded, or not the
right ones.
Okay, my application JAR is there (in the Cache directory), and it
has all the classes in it. I'm guessing the way the WOA file and
all the JARs are named (prefixed with DM, RM, etc) is just part of
Java WebStart's caching strategy and is normal, yes?
If so, maybe it is a class-path thing?
Dave
On Jun 21, 2007, at 9:52 PM, David Avendasora wrote:
A little clarification. The difference isn't Development vs
Deployment builds, it is the difference between the application
running using the build-and-go functionality of Xcode, and the
app running inside of Tomcat.
It doesn't call the client-side classes when run inside of
Tomcat on either Mac or Windows2000.
Does anyone have any idea why the WebObjects would run
differently in Tomcat than through build-and-go?
Dave
On Jun 21, 2007, at 2:35 PM, David Avendasora wrote:
Hi all,
I have a java client application (I know, I know) that refuses
to use my client-side classes when built for deployment. When
building for development in Xcode (I know, I know) it uses the
client-side classes flawlessly. When deployed, it simply uses
EOGenericRecord instead of the classes defined in the EOModel.
Oh, and it is deployed as a SSDD to Tomcat.
Does anyone have any idea why WebObjects would work differently
in deployment than in development?
Thanks!
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@avendasora.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
- - -
Houdah Software s. à r. l.
http://www.houdah.com
HoudahGeo: One-stop photo geocoding
HoudahSpot: Powerful Spotlight frontend
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40netsense.nl
This email sent to email@hidden
Regards,
Johan Henselmans
http://www.netsense.nl
Tel: +31-20-6267538
Fax: +31-20-6273852
- - -
Houdah Software s. à r. l.
http://www.houdah.com
HoudahGeo: One-stop photo geocoding
HoudahSpot: Powerful Spotlight frontend
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden