I would definitely load those at the web
app level. I tend to load most everything at the web app level to avoid
integration issues just like the one you’re dealing with right now. When
you say fop.jar is in web-inf, is it in the server web-inf ( shared for all web
apps ) or the web app’s web-inf?
____________________________________________ From:
flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jaime Bermudez I couldn't find a way to turn on classloader tracing (at least I didn't
see anything in the weblogic 8.1 docs), however I think the problem may be in
the setup. My fop.jar, batik.jar and other supporting files (i.e.
avalon-framework-cvs*.jar) are in the WEB-INF/lib directory of the app
server. The flex jars, including all of the batik-*** files, are located
under WEB-INF/flex/jars. From what I understand about the
prefer-web-inf-classes parameter, it loads jars under the WEB-INF directory before
loading jars that are part of the weblogic server classpath - in my case
the fop jars are NOT in weblogic's startup classpath. So, I'm guessing
the fact that both sets of batik jars are under the WEB-INF directory, albeit
in different subdirectories, is why the app still has a problem
loading. Does that sound right? Where do you keep your fop related jars
and do you load them at the server level as opposed to the application level? On 12/9/05, Carson
Hager <[EMAIL PROTECTED]>
wrote: Interesting. The next thing I would do is verify where
the css parser errors are getting loaded from. WLS should have a way to
turn on classloader tracing so that it will log out the physical location from
where it loaded the classes. See if you can enable that and let me know what it
says.
____________________________________________ From: flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com]
On Behalf Of Jaime Bermudez Hey
Carson, I'm
trying out your technique, but I'm still getting LocatorParser errors...
here's a snippet of my weblogic.xml: <weblogic-web-app>
</security-role-assignment> This
solution worked for you guys? On
9/16/05, Carson Hager <
[EMAIL PROTECTED]> wrote: My pleasure. The only impact will be a small increase
in memory utilization by the server at startup. Basically, appservers like WLS
like to use hierarchical classloaders so that classes which are shared by
multiple web applications are not loaded for each web app. By using a
shared classloader, there is savings in memory and ( to a small degree )
runtime performance due to the need to only load/verify the class a single
time. The reality is that these things are basically negligible. The kicker
with hierarchical classloaders is exactly what you're seeing here...the need to
override at a child level. I'm sure you'll find this to be a good
solution. ____________________________________________
From: flexcoders@yahoogroups.com
[mailto:
flexcoders@yahoogroups.com] On Behalf Of Kevin
Towes (New Toronto Group)
Thanks, From :
"Carson Hager" <[EMAIL PROTECTED]> Kevin, This is a classloader issue. Check out prefer-web-inf-classes
in the following URL to turn off the default behavior of the WLS classloader to
allow for classes in web apps to be loaded in preference of the server level
classloader. http://e-docs.bea.com/wls/docs81/programming/classloading.html ____________________________________________ From: flexcoders@yahoogroups.com
[mailto:
flexcoders@yahoogroups.com] On Behalf Of Kevin
Towes (New Toronto Group) Hey Gang - YAHOO! GROUPS
LINKS
SPONSORED
LINKS
YAHOO!
GROUPS LINKS
|
- RE: [flexcoders] URGENT Problem on Flex installed on BEA We... Carson Hager
- Re: [flexcoders] URGENT Problem on Flex installed on B... Jaime Bermudez