WebLogic class loading conflict causing ClassCastException
Hi everyone,
I am using Oracle XML Parser v2 for my JCA adapter and I am getting the following exception when method from my adapter is invoked.
java.lang.ClassCastException: weblogic.xml.jaxp.RegistryDocumentBuilderFactory cannot be cast to oracle.xml.jaxp.JXDocumentBuilderFactory
I have already placed Oracle XML Parser v2 library (xmlparserv2.jar) inside $DOMAIN_DIR/lib. Below is the line that throws above exception.
JXDocumentBuilderFactory factory =(JXDocumentBuilderFactory)JXDocumentBuilderFactory.newInstance();
So it seems like WebLogic is using different JXDocumentBuilderFactory and there seems to be problem with class loading. How can I resolve this issue? Thanks in advance.
Regards,
K.H
Edited by: K Hein on Dec 16, 2010 12:38 AM
HI,
You can use Class Loader Filtering feature of WebLogic to isolate the Classloaders....as described in the following link: http://middlewaremagic.com/weblogic/?page_id=192
Thanks
Jay SenSharma
http://middlewaremagic.com/weblogic (Middleware Magic Is Here)
Similar Messages
-
Hi all!
Let me explain my problem.
I have an EJB which has in its same Java package some support classes
& also a startup class. I created an EJB jar file (containing the home,
remote, bean, the deployment descriptors & the container generated stubs)
for deployment. I also compiled all the support classes & the startup class
into the /weblogic/myserver/serverclasses directory. I also added the
required entries in the weblogic.properties file for the startup class.
Now the problem is that the support classes & the startup class contain
methods & constructors which have package level access (i.e the default
access in Java). At runtime, when my bean tries to access one of these
methods, an IllegalAccessException is thrown.
I understand that this exception is thrown when one tries to access a
method which should not be accessed (like private/protected/cross-package
access). However, both the EJB & these classes are in the same package.
So this should not be thrown.
Now the next thing I thought is that the EJB & the support classes are
being loaded by 2 different classloaders. I guess the classes under
/weblogic/myserver/serverclasses are being loaded by the WebLogic
Server ClassLoader & the EJB bean classes are being loaded by the
specialized EJB ClassLoader.
Now my question is,
1) Is it the case that the WebLogic Server does not recognize that the
EJB Bean class is in the same package as the support classes because
they are loaded by 2 separate class loaders? Please note that the EJB
jar file does not contain any support classes - so there is no
duplicate classes here.
2) Is this a bug?
3) What should I do to prevent this problem?
Some workarounds that I have done are:
1) Copied the Bean.class (implementation class of EJB bean) into the
serverclasses directory. Now the server does not throw any
IllegalAccessException. -- This, however, does not appeal as a solution
since it looks like the Bean class is now being loaded by the WebLogic
Class Loader instead of from the EJB jar file.
2) I changed all the default package access methods to public methods.
Works like a charm. -- Problem is that this is a third party set of classes
which I would like to avoid modifying.
Hope this is not too confusing. Please let me know if you need any further info.
Thanks much in advance,
--DasYou have to tell WLAS where to load your new classes. You can change
workingDir of your JSP configuration in weblogic.properties to point to your
new class directory.
Cheers - Wei
Hyung-Jin Kim <[email protected]> wrote in message
news:[email protected]..
> It seems that if I compile a class that a JSP uses while Weblogic is
> running, Weblogic's class loader has this nasty habit of caching/writing
> the class that already has loaded into memory into:
>
> weblogic/myServer/classfiles
>
> Weblogic then refers to the older class file under the above directory
> when the server is started again. Is there any way to turn this "class
> loader caching" off in Weblogic? Thanks!
>
> -hjk
>
-
Note: I am not sure what is the best suitable subject for this issue.
Stack Trace:
Error 1)
<Dec 30, 2011 11:02:51 AM GMT+05:30> <Error> <HTTP> <BEA-101017> <[ServletContext@29472630[app:EM11X module:Web path:/Web spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@14d05d1[
POST /Web/GenerateMealPlanAction.do HTTP/1.1
Via: 1.1 INDCHN-MGMT01
Cookie: org.ditchnet.jsp.tabs:CommercialFormulaTabs=; org.ditchnet.jsp.tabs:KitchenTabs=; JSESSIONID=sZQFT9MJQc6vS6MCSXtdjWwSTLCcG6nqL12Fdyj1NFHcp4WnpkCB!1348500068
Referer: http://130.78.88.83:7001/Web/GenerateMealPlanAction.do?vo.viewCode=generateMealPlanFrame&method=1&&menu_id=DS_DFLT&module_id=DS&function_id=DS_GEN_MEAL_PLAN&function_name=Generate%20Meal%20Plan&function_type=R&access=YYYYN&desktopFlag=N&vo.functionId=DS_GEN_MEAL_PLAN
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1)
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-us
Pragma: no-cache
Connection: Keep-Alive
Content-Length: 488
]] Root cause of ServletException.
java.lang.IllegalArgumentException: Cannot invoke com.vo.GenerateMealPlanVO.setServingDate on bean class 'class com.vo.GenerateMealPlanVO' - argument type mismatch - had objects of type "java.lang.String" but expected signature "com.core.util.Date"
at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2181)
at org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2141)
at org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1948)
at org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2054)
at org.apache.commons.beanutils.BeanUtilsBean.setProperty(BeanUtilsBean.java:1015)
Truncated. see log file for complete stacktrace
Caused By: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.commons.beanutils.PropertyUtilsBean.invokeMethod(PropertyUtilsBean.java:2155)
Truncated. see log file for complete stacktrace
>
Error 2)
<Dec 30, 2011 11:11:19 AM GMT+05:30> <Error> <HTTP> <INDCHN-EPORT01> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1325223679258> <BEA-101017> <[ServletContext@29472630[app:EM11X module:Web path:/Web spec-version:2.5], request: weblogic.servlet.internal.ServletRequestImpl@1da8bfe[
POST /Web/LookupAction.do HTTP/1.1
Via: 1.1 INDCHN-MGMT01
Cookie: org.ditchnet.jsp.tabs:CommercialFormulaTabs=; org.ditchnet.jsp.tabs:KitchenTabs=; JSESSIONID=GhG4T9TJ0ytD8dhRSGBFv2c3v1hNLftTTCJQHp6Qn9C5SnMGTVYF!1348500068
Referer: http://130.78.88.83:7001/Web/core/lookup/jsp/LookupCriteria.jsp?undefined
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; InfoPath.1)
Accept: */*
Accept-Language: en-us
Pragma: no-cache
Connection: Keep-Alive
Content-Length: 304
]] Root cause of ServletException.
java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String
at com.lookup.pojo.web.LookupAction.doActionQuery(LookupAction.java:107)
at com.core.pojo.web.BaseAction.execute(BaseAction.java:97)
at org.springframework.web.struts.DelegatingActionProxy.execute(DelegatingActionProxy.java:106)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:421)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:226)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
>
[b]Analysis:
Migrating J2EE Application from Oracle 10g Application Server to Oracle 11g Weblogic Server. I am stuck with above two issues. This issue not present while running in Oracle 10g Application Server
1) I was thinking it is something to do with JSTL versions and the below command is executed to make the JSTL version to jstl 1.1.2
java weblogic.Deployer -adminurl t3://localhost:7001 -user weblogic -password weblogic -deploy -library D:/Oracle/Middleware/wlserver_10.3/common/deployable-libraries/jstl-1.1.2.war
The problem remains same.
2) Now <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes> is added to weblogic.xml to make the Web application to load application specific libraries from WEB-INF/lib directory.
The problem remains same.
3) I checked Class Loader Analysis Tool and found conflicting classes and based on CAT recommendation the below list is added to weblogic.xml and <wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes> is removed since both cannot co-exist.
<wls:prefer-application-packages>
<wls:package-name>antlr.*</wls:package-name>
<wls:package-name>antlr.collections.*</wls:package-name>
<wls:package-name>antlr.collections.impl.*</wls:package-name>
<wls:package-name>antlr.debug.misc.*</wls:package-name>
<wls:package-name>com.mysql.jdbc.*</wls:package-name>
<wls:package-name>javax.ejb.*</wls:package-name>
<wls:package-name>javax.ejb.spi.*</wls:package-name>
<wls:package-name>javax.enterprise.deploy.*</wls:package-name>
<wls:package-name>javax.jms.*</wls:package-name>
<wls:package-name>javax.management.j2ee.*</wls:package-name>
<wls:package-name>javax.resource.*</wls:package-name>
<wls:package-name>javax.resource.cci.*</wls:package-name>
<wls:package-name>javax.resource.spi.*</wls:package-name>
<wls:package-name>javax.security.jacc.*</wls:package-name>
<wls:package-name>javax.servlet.*</wls:package-name>
<wls:package-name>javax.servlet.http.*</wls:package-name>
<wls:package-name>javax.servlet.jsp.*</wls:package-name>
<wls:package-name>javax.transaction.*</wls:package-name>
<wls:package-name>javax.transaction.xa.*</wls:package-name>
<wls:package-name>javax.xml.*</wls:package-name>
<wls:package-name>javax.xml.datatype.*</wls:package-name>
<wls:package-name>javax.xml.namespace.*</wls:package-name>
<wls:package-name>javax.xml.parsers.*</wls:package-name>
<wls:package-name>javax.xml.registry.*</wls:package-name>
<wls:package-name>javax.xml.transform.*</wls:package-name>
<wls:package-name>javax.xml.validation.*</wls:package-name>
<wls:package-name>javax.xml.xpath.*</wls:package-name>
<wls:package-name>oracle.core.lmx.*</wls:package-name>
<wls:package-name>oracle.core.lvf.*</wls:package-name>
<wls:package-name>oracle.jdbc.*</wls:package-name>
<wls:package-name>oracle.jdbc.aq.*</wls:package-name>
<wls:package-name>oracle.jdbc.connector.*</wls:package-name>
<wls:package-name>oracle.jdbc.dcn.*</wls:package-name>
<wls:package-name>oracle.jdbc.diagnostics.*</wls:package-name>
<wls:package-name>oracle.jdbc.driver.*</wls:package-name>
<wls:package-name>oracle.jdbc.internal.*</wls:package-name>
<wls:package-name>oracle.jdbc.oci.*</wls:package-name>
<wls:package-name>oracle.jdbc.oracore.*</wls:package-name>
<wls:package-name>oracle.jdbc.pool.*</wls:package-name>
<wls:package-name>oracle.jdbc.rowset.*</wls:package-name>
<wls:package-name>oracle.jdbc.util.*</wls:package-name>
<wls:package-name>oracle.jdbc.xa.*</wls:package-name>
<wls:package-name>oracle.jpub.runtime.*</wls:package-name>
<wls:package-name>oracle.jsp.provider.*</wls:package-name>
<wls:package-name>oracle.net.ano.*</wls:package-name>
<wls:package-name>oracle.net.aso.*</wls:package-name>
<wls:package-name>oracle.net.jdbc.*</wls:package-name>
<wls:package-name>oracle.net.jndi.*</wls:package-name>
<wls:package-name>oracle.net.ns.*</wls:package-name>
<wls:package-name>oracle.net.nt.*</wls:package-name>
<wls:package-name>oracle.net.resolver.*</wls:package-name>
<wls:package-name>oracle.security.o3logon.*</wls:package-name>
<wls:package-name>oracle.security.o5logon.*</wls:package-name>
<wls:package-name>oracle.sql.*</wls:package-name>
<wls:package-name>oracle.sql.converter.*</wls:package-name>
<wls:package-name>org.apache.commons.*</wls:package-name>
<wls:package-name>org.apache.derby.*</wls:package-name>
<wls:package-name>org.apache.oro.*</wls:package-name>
<wls:package-name>org.apache.xerces.*</wls:package-name>
<wls:package-name>org.apache.xmlcommons.*</wls:package-name>
<wls:package-name>org.gjt.mm.*</wls:package-name>
<wls:package-name>org.joda.time.*</wls:package-name>
<wls:package-name>org.w3c.dom.*</wls:package-name>
<wls:package-name>org.xml.sax.*</wls:package-name>
</wls:prefer-application-packages>
The problem remains same.
Your help is greatly appreciated as I am stuck with this issue.No I cannot ignore this error while deplyment. I'm not able to deploy the war.
More ovet this needs to be working as during startup, the servlet loads some xml files and convert into tables for the kiosk in the airport to be working.
Edited by: [email protected] on Mar 27, 2009 12:24 PM -
Weblogic Class Loader caching/writing classes to weblogic/myServer/classfiles
It seems that if I compile a class that a JSP uses while Weblogic is
running, Weblogic's class loader has this nasty habit of caching/writing
the class that already has loaded into memory into:
weblogic/myServer/classfiles
Weblogic then refers to the older class file under the above directory
when the server is started again. Is there any way to turn this "class
loader caching" off in Weblogic? Thanks!
-hjk
You have to tell WLAS where to load your new classes. You can change
workingDir of your JSP configuration in weblogic.properties to point to your
new class directory.
Cheers - Wei
Hyung-Jin Kim <[email protected]> wrote in message
news:[email protected]..
> It seems that if I compile a class that a JSP uses while Weblogic is
> running, Weblogic's class loader has this nasty habit of caching/writing
> the class that already has loaded into memory into:
>
> weblogic/myServer/classfiles
>
> Weblogic then refers to the older class file under the above directory
> when the server is started again. Is there any way to turn this "class
> loader caching" off in Weblogic? Thanks!
>
> -hjk
>
-
Servlet can't be found outside of weblogic/classes??
Hi there!
I wrote a servlet that I've placed into a directory that's in my CLASSPATH
(set inside startWebLogic.bat). It's clearly identified within the System
java.class.path variable as well (when the logs scroll by).
However, the Servlet (although it's been registered in Weblogic.properties)
refuses to be found unless I finally move it into weblogic/classes.
Does anybody know why??
-joe
Joe,
Servlets are loaded by the weblogic class loader. For that reason, the
base directory for your servlets has to be in the weblogic.class.path.
Since weblogic/classes is part of this class path, they were found by
the WL class loader. Basically, add the base dir for your servlet
package to the WL class path and you will be fine.
If you're starting WL from the command line, see the
/weblogic/startweblogic.??? scripts.
Jason
-
Can I get a weblogic Initial context without importing all weblogic classes ?
can I get a weblogic Initial context (with weblogic.jndi.WLInitialContextFactory)
without importing all weblogic classes ?I ran my client through all its functions.
I then took the access.log file and parsed out a list of all the class
files that were downloaded and built a script to create my
weblogiclient.jar file.
Before running the client we had to:
With WL5.1 I think we had to unjar the weblogicaux.jar file into the
serverclasses directory so the client could load them all individually.
Make sure you clean up after you are done with this.
With WL 6 we did not have to do that.
The access.log file is the key to building your own client jar file.
We also require the use of the Java 1.3 plug-in by our clients (for
Applets) so we can do multiple Jar caching.
Tom
Dominique Jean-Prost wrote:
Hello tom
What do you mean by "use the Weblogic class loader" ?
Could you explain whath you exactly did to find all the classes you need ?
regards.
dom
<nospam@nospam> a écrit dans le message news: 3ABF3EC2.9010200@nospam...
You need the classes one way or another. BUT you do not have to
redistribute the whole Weblogic.jar file. Use the Weblogic class
loader then run your program. The weblogic access.log should have a
listing of all the classes you need to use and you can build your own
sub-jar. My experience is that this new jar is significantly smaller.
Ours is around 600K instead of 15MB.
Tom
Dimitri Rakitine wrote:
Yes, if, for example, you can network classload from WebLogic. Talking
to a WebLogic
server means WebLogic RMI (unless you use RMI/IIOP in which case youdont need any
WebLogic classes) which needs WebLogic-specific classes, so you clientapplication needs
to get them from somewhere - local classpath or remote WebLogic server.
David Dahan <[email protected]> wrote:
I mean without a classpath to all weblogic classes.
can I get a weblogic Initial context (with
weblogic.jndi.WLInitialContextFactory)
without importing all weblogic classes ? -
How to write a class loader to solve the class confliction in rt.jar?
Hello guys:
The weblogic.jar has the javax.management.*, it is conflict with rt.jar's
I want to use JMX 1.0 to communicate with weblogic 8.1. The client should be run in the Java 1.5
It throw
java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359
java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359I know the reason is java 1.5 has JMX 1.2 in it.
So how can I program a class loader to load the weblogic.jar classes in? I have tried a lot of code, but failed.
Is there any sample here?
I want to use the JMX 1.0 in weblogic.jar at jdk1.5 run time
Thanks a lot,
QiangHello guys:
The weblogic.jar has the javax.management.*, it is conflict with rt.jar's
I want to use JMX 1.0 to communicate with weblogic 8.1. The client should be run in the Java 1.5
It throw
java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359
java.io.InvalidClassException: javax.management.ObjectName; local class incompatible:
stream classdesc serialVersionUID = -5467795090068647408, local class serialVersionUID = 1081892073854801359I know the reason is java 1.5 has JMX 1.2 in it.
So how can I program a class loader to load the weblogic.jar classes in? I have tried a lot of code, but failed.
Is there any sample here?
I want to use the JMX 1.0 in weblogic.jar at jdk1.5 run time
Thanks a lot,
Qiang -
Class Loader Hierarchy in Weblogic 7.0
I have read the BEA documentation on the class loader hierarchy in Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several utility jars. The
web apps' manifests contain the Class-Path entry for the utility jars. My understanding
of this is that each web app SHOULD have its own class loader. Also, the utility
jars will be scoped in a separate class loader and WILL NOT have visibility to
the web app classes. The web app classes should have visibility to the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the class loader
for each servlet when it was loaded. I also printed the class loader from a class
that is DEFINITELY contained in one of the utility jars. Here is the result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Utility Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet 2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders (i.e. one
for each class above). I believe the above printout says that all 3 classes are
being loaded by the SAME class loader instance (Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on?I rechecked the classpath for the user that starts Weblogic, and in the classpath
I found the project "src" directory (must have missed it earlier). When we did
our build, the classes are placed in the src structure then copied to the build
area. That's the reason I was not seeing the appropriate class loader hierarchy.
Thanks for all of the comments.
"Sanjeev Chopra" <[email protected]> wrote:
>
"Mark Cotherman" <[email protected]> wrote in message
news:[email protected]...
Thanks for your comments again Mark. I'm just trying to get a goodhandle
on how
this is working.
I'll assume that somehow my web app classes are being loaded into theroot
classloader.
The next question is... why??Just to be sure - is there any way these classes are sneaking into the
system classpath ?
My ear file contains the following:
a.war
b.war
c.war
lib/util1.jar
lib/util2.jar
lib/util3.jar
lib/util4.jar
The manifest in all three wars reference all util jars. This ear deployssuccessfully
on Weblogic with no errors.
How could these separate servlets (one in each war) not have seperateclass loaders
seperate from the root where the utils should reside. I don't thinkthat
I have
any control over where Weblogic loads the war classes, or do I?
See comments below....
Mark Spotswood <[email protected]> wrote:
Mark Cotherman wrote:
Thanks for the follow-up.
I want to make sure I follow what you are saying. All classes in
the
manifest
Class-Path of WARs are exported to the parent classloader.That's right.
To me this is the correct behavior since the manifest Class-Path
is
meant to provide
a way to share common utility classes among several web apps. AllEJB jars and
manifest Class-Path entries should be loaded by the same class loader.Its a way to share class definitions, but not necessarilly class
instances. I don't think that a web application should be extending
the classpath of its parent's classloader. This leads to namespace
problems as well as reloadability issues.
Ok, you lost me here. Shouldn't delegation handle the namespacecollisions??
If the web app class loader has a class definition (webapp:com.xyz.ClassA) with
exactly the same name in the same package as the root class loader(rootloader:
com.xyz.ClassA), I thought the web app would use (delegate loading)the
class
definition from the root class loader when PreferWebInf is set to false.
Isn't this why the PreferWebInf attribute, when set to true, can causeClassCastExceptions??
The web app when creating an instance of (webapp: com.xyz.ClassA)from
the web
app class loader can potentially pass a reference to this instanceto a
class
instance loaded from the root loader. The root class loader has adifferent class
definition for ClassA.
REALLY what makes since is that all common jar files be defined
in
the manifest
Class-Path OF THE ear FILE (if the WAR(s) are in an ear). These
jar
files should
then be loaded by the same class loader as the EJB jars. There shouldbe no need
for the WARs to have any reference to the utility jars since the
EJB
class loader
is the parent of the WAR class loaders.The ear file doesn't have a manifest classpath, but what you are getting
at makes sense. If you add a manifest to any EJBs in your app, theall
webapps (as well as all other EJBs) will be able to see it, sincewith
our structure, EJBs are loaded into the application's root classloader.
My problem is that the ACTUAL SERVLET classes are NOT being loadedby a separate
class loader from the EJB and common jar class loader. This is
completely
against
what is being said in the Weblogic documentation. The Manifest
Class-Path
should
have nothing to do with where the classes that reside in
WEB-INF/classes
of my
servlet are loaded.Classloaders will ask their parent for the class first before loading
it
themselves. So if the parent classloader somehow has visibility to
classes that your webpapp references, then it will get loaded by the
parent classloader.
I am in the middle of migrating an app from an older version of
Weblogic,
and
it would be helpful to have the ACTUAL class loading hierarchy welldocumented.
The basic hierarchy is all EJBs are in a root shared classloader and
each web application is loaded by a classloader that is a child of
that root.
Again, am I missing something here???My suspicion is that somehow these servlets are in the classpath ofthe
root classloader, so when the webapp classloaders delegate to thatone,
it will come up with the class.
mark
Mark Spotswood <[email protected]> wrote:
I believe what you are seeing is a bug in the servlet container.
The classloader organization is what you expect, but each webapp
is exporting the classpath information from its manifest to the
classloader above its classloader (which is common to all
three webapps) rather than to its own classloader. So because
of the delegation that happens with classloading, the common
parent classloader is the one that loads the class.
I believe that this behavior exists as an attempt to avoid
ClassCastExceptions, but I don't think that it is the right
solution to this problem. In our 8.1 release, this behavior
has been changed. That is, web applications no longer export
manifest classpath information to the parent of their classloader.
This change has not been ported back to the 7.x line, but a bug
report has been created (CR099889). You should be able to follow
up with support with this CR number.
mark
Mark Cotherman wrote:
I have read the BEA documentation on the class loader hierarchy
in
Weblogic Server,
and I have some questions regarding some behavior I am seeing.
I am running Weblogic Server 7.0.
I have an ear file that contains 3 web apps (wars) and several
utility
jars. The
web apps' manifests contain the Class-Path entry for the utility
jars.
My understanding
of this is that each web app SHOULD have its own class loader.
Also,
the utility
jars will be scoped in a separate class loader and WILL NOT have
visibility
to
the web app classes. The web app classes should have visibility
to
the utility
jars.
Is this correct????
I added a static segment of code in each web app and printed the
class
loader
for each servlet when it was loaded. I also printed the class loaderfrom a class
that is DEFINITELY contained in one of the utility jars. Here is
the
result:
Utility Class ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04
Utility
Class
Parent ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 1 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet1 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
Servlet 2 ClassLoader: sun.misc.Launcher$AppClassLoader@b9d04 Servlet2 Parent
ClassLoader: sun.misc.Launcher$ExtClassLoader@71732b
I'm a little confused.... I expected to see 3 different class loaders(i.e. one
for each class above). I believe the above printout says that all
3
classes are
being loaded by the SAME class loader instance
(Launcher$AppClassLoader@b9d04).
Am I interpreting this correctly? If so, what's going on? -
Cocoon2 weblogic (5.1 sp6) class loader security problem
Hello folks,
System:
Cocoon: v2.0
JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
OS: NT4 SP5
Servlet: v2.2
AppServer: Weblogic 5.1 SP6
Symptoms:
I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
figured out what libraries I need on the Weblogic's classpath, I managed
to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
servlet and wrap the HttpServletRequest in MyRequest to provide the XML
content. I changed the line <map:generators default="request"> in
sitemap.xmap to specify the location of the source. Configuration files
seem to be read correctly and the file
<myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
is generated (but there is no class file generated)!
I looked at the cocoon.log file and looks like a class loader security
problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
problem? Any help is much appreciated!
cocoon.log file generated:
DEBUG 62 [cocoon ] (ExecuteThread-11): Using configuration file:
/cocoon.xconf
INFO 62 [cocoon ] (ExecuteThread-11): Reloading from:
file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
DEBUG 93 [cocoon ] (ExecuteThread-11): New Cocoon object.
DEBUG 93 [cocoon ] (ExecuteThread-11): Using parser:
org.apache.cocoon.components.parser.JaxpParser
DEBUG 109 [cocoon ] (ExecuteThread-11): Creating Repository with
this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 109 [cocoon ] (ExecuteThread-11): Classpath =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
DEBUG 109 [cocoon ] (ExecuteThread-11): Work directory =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 125 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 390 [cocoon ] (ExecuteThread-11): Root configuration:
cocoon
DEBUG 390 [cocoon ] (ExecuteThread-11): Configuration version:
2.0
DEBUG 390 [cocoon ] (ExecuteThread-11): Setting up components...
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.parser.Parser =
org.apache.cocoon.components.parser.JaxpParser)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.generator.ProgramGenerator =
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.url.URLFactory =
org.apache.cocoon.components.url.URLFactoryImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.saxconnector.SAXConnector =
org.apache.cocoon.components.saxconnector.NullSAXConnector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.datasource.DataSourceComponentSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.pool.PoolController =
org.apache.cocoon.components.ComponentPoolController)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
= org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.store.Store =
org.apache.cocoon.components.store.MemoryStore)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.classloader.ClassLoaderManager =
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
DEBUG 422 [cocoon ] (ExecuteThread-11): Setting up the sitemap.
DEBUG 422 [cocoon ] (ExecuteThread-11): Sitemap location =
sitemap.xmap
DEBUG 703 [cocoon ] (ExecuteThread-11): ComponentFactory creating
new instance of org.apache.cocoon.components.url.URLFactoryImpl.
DEBUG 703 [cocoon ] (ExecuteThread-11): Getting the URLFactories
DEBUG 703 [cocoon ] (ExecuteThread-11): for protocol:
resource org.apache.cocoon.components.url.ResourceURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): for protocol: context
org.apache.cocoon.components.url.ContextURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): Beginning sitemap
regeneration
DEBUG 718 [cocoon ] (ExecuteThread-11): Making URL from
file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
DEBUG 718 [cocoon ] (Thread-1): Could not find ComponentHandler,
attempting to create one for role:
org.apache.cocoon.components.language.generator.ServerPagesSelector
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.GeneratorSelector.
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element:
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: markup-languages
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
xsp
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
for sitemap
DEBUG 734 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 734 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: programming-languages
DEBUG 750 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.programming.java.JavaLanguage.
DEBUG 750 [cocoon ] (Thread-1): Looking up
org.apache.cocoon.components.classloader.ClassLoaderManager
DEBUG 750 [cocoon ] (Thread-1): Setting the parameters
DEBUG 750 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.programming.java.JavaLanguage for
java
DEBUG 765 [cocoon ] (Thread-1): The instance was not accessible,
creating it now.
DEBUG 765 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 1718 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 1718 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 4109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4109 [cocoon ] (Thread-1): Can't load ServerPage
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4359 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 4359 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 6109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
ERROR 6109 [cocoon ] (Thread-1): Error compiling sitemap
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (ExecuteThread-11): Changing Cocoon
context(sitemap.xmap) to prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): from
context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): at URI
DEBUG 6109 [cocoon ] (ExecuteThread-11): New context is
file:/D:/Programs/cocoon-1.8.2/samples/
ERROR 6140 [cocoon ] (ExecuteThread-11): Problem with servlet
org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
not available.
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
INFO 6187 [cocoon ] (ExecuteThread-11): '' Processed by Apache
Cocoon 2.0a4 in 5.75 seconds.
================================================================
Regards,
GeorgiHello folks,
System:
Cocoon: v2.0
JDK: Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C),
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)
OS: NT4 SP5
Servlet: v2.2
AppServer: Weblogic 5.1 SP6
Symptoms:
I've updated our application from Cocoon 1.7.4 to Cocoon2. After I
figured out what libraries I need on the Weblogic's classpath, I managed
to envoke the MyServlet (MyServlet extends CocoonServlet). The technique
I am using is the one I used with the Cocoon v1.7.4: extend Cocoon
servlet and wrap the HttpServletRequest in MyRequest to provide the XML
content. I changed the line <map:generators default="request"> in
sitemap.xmap to specify the location of the source. Configuration files
seem to be read correctly and the file
<myWebAppContext>/WEB-INF/_tmp_war/org/apache/cocoon/www/sitemap_xmap.java
is generated (but there is no class file generated)!
I looked at the cocoon.log file and looks like a class loader security
problem: the \WEB-INF\_tmp_war gets locked! Is there any workaround this
problem? Any help is much appreciated!
cocoon.log file generated:
DEBUG 62 [cocoon ] (ExecuteThread-11): Using configuration file:
/cocoon.xconf
INFO 62 [cocoon ] (ExecuteThread-11): Reloading from:
file:D:/Programs/cocoon-1.8.2/samples/cocoon.xconf
DEBUG 93 [cocoon ] (ExecuteThread-11): New Cocoon object.
DEBUG 93 [cocoon ] (ExecuteThread-11): Using parser:
org.apache.cocoon.components.parser.JaxpParser
DEBUG 109 [cocoon ] (ExecuteThread-11): Creating Repository with
this directory: D:\programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 109 [cocoon ] (ExecuteThread-11): Classpath =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\classes;D:\Programs\cocoon-1.8.2\samples\WEB-INF\lib\javac.jar;D:\avue\lib\servlet.jar;D:\avue\lib\jaxp.jar;D:\avue\lib\xerces.jar;D:\avue\lib\xalan.jar;D:\avue\lib\cocoon.jar;D:\avue\lib\avalonapi.jar;D:\avue\lib\logkit.jar;D:\avue\lib\maybeupload.jar;D:\avue\lib\jakarta-regexp-1.2.jar;D:\avue\lib\jstyle.jar;D:\avue\lib\javac.jar;D:\weblogic\lib\weblogic510sp6boot.jar;D:\weblogic\classes\boot;
DEBUG 109 [cocoon ] (ExecuteThread-11): Work directory =
D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war
DEBUG 125 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 140 [cocoon ] (Thread-0): ComponentFactory creating new
instance of org.apache.cocoon.components.parser.JaxpParser.
DEBUG 390 [cocoon ] (ExecuteThread-11): Root configuration:
cocoon
DEBUG 390 [cocoon ] (ExecuteThread-11): Configuration version:
2.0
DEBUG 390 [cocoon ] (ExecuteThread-11): Setting up components...
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.parser.Parser =
org.apache.cocoon.components.parser.JaxpParser)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.generator.ProgramGenerator =
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.url.URLFactory =
org.apache.cocoon.components.url.URLFactoryImpl)
DEBUG 406 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.saxconnector.SAXConnector =
org.apache.cocoon.components.saxconnector.NullSAXConnector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.datasource.DataSourceComponentSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.avalon.util.pool.PoolController =
org.apache.cocoon.components.ComponentPoolController)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.programming.ProgrammingLanguageSelector
= org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.language.markup.MarkupLanguageSelector =
org.apache.cocoon.components.CocoonComponentSelector)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.store.Store =
org.apache.cocoon.components.store.MemoryStore)
DEBUG 422 [cocoon ] (ExecuteThread-11): Adding component
(org.apache.cocoon.components.classloader.ClassLoaderManager =
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl)
DEBUG 422 [cocoon ] (ExecuteThread-11): Setting up the sitemap.
DEBUG 422 [cocoon ] (ExecuteThread-11): Sitemap location =
sitemap.xmap
DEBUG 703 [cocoon ] (ExecuteThread-11): ComponentFactory creating
new instance of org.apache.cocoon.components.url.URLFactoryImpl.
DEBUG 703 [cocoon ] (ExecuteThread-11): Getting the URLFactories
DEBUG 703 [cocoon ] (ExecuteThread-11): for protocol:
resource org.apache.cocoon.components.url.ResourceURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): for protocol: context
org.apache.cocoon.components.url.ContextURLFactory
DEBUG 718 [cocoon ] (ExecuteThread-11): Beginning sitemap
regeneration
DEBUG 718 [cocoon ] (ExecuteThread-11): Making URL from
file:/D:/Programs/cocoon-1.8.2/samples/sitemap.xmap
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.
DEBUG 718 [cocoon ] (Thread-1): Could not find ComponentHandler,
attempting to create one for role:
org.apache.cocoon.components.language.generator.ServerPagesSelector
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.generator.GeneratorSelector.
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element:
DEBUG 718 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 718 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: markup-languages
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.xsp.XSPMarkupLanguage for
xsp
DEBUG 734 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage
for sitemap
DEBUG 734 [cocoon ] (Thread-1): ComponentFactory creating new
instance of org.apache.cocoon.components.CocoonComponentSelector.
DEBUG 734 [cocoon ] (Thread-1): CocoonComponentSelector setting
up with root element: programming-languages
DEBUG 750 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.programming.java.JavaLanguage.
DEBUG 750 [cocoon ] (Thread-1): Looking up
org.apache.cocoon.components.classloader.ClassLoaderManager
DEBUG 750 [cocoon ] (Thread-1): Setting the parameters
DEBUG 750 [cocoon ] (Thread-1): Adding
org.apache.cocoon.components.language.programming.java.JavaLanguage for
java
DEBUG 765 [cocoon ] (Thread-1): The instance was not accessible,
creating it now.
DEBUG 765 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 1718 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 1718 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 4109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:163)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4109 [cocoon ] (Thread-1): Can't load ServerPage
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:172)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 4109 [cocoon ] (Thread-1): ComponentFactory creating new
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
DEBUG 4359 [cocoon ] (Thread-1): Making URL from
jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
DEBUG 4359 [cocoon ] (Thread-1): Logicsheet
Used:jar:file:/D:/avue/lib/cocoon.jar!/org/apache/cocoon/components/language/markup/sitemap/java/sitemap.xsl
WARN 6109 [cocoon ] (Thread-1): Could not load class for program
'org\apache\cocoon\www\sitemap_xmap'
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:272)
at
java.security.AccessController.checkPermission(AccessController.java:399)
at
java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at java.net.URLClassLoader$5.run(URLClassLoader.java:463)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.getPermissions(URLClassLoader.java:461)
at
java.security.SecureClassLoader.getProtectionDomain(SecureClassLoader.java:162)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:248)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:297)
at java.lang.ClassLoader.loadClass(ClassLoader.java:253)
at
org.apache.cocoon.components.classloader.ClassLoaderManagerImpl.loadClass(ClassLoaderManagerImpl.java:58)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:121)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): Language Exception
org.apache.cocoon.components.language.LanguageException: Could not load
class for program 'org\apache\cocoon\www\sitemap_xmap' due to a
java.security.AccessControlException: access denied
(java.io.FilePermission
\D:\Programs\cocoon-1.8.2\samples\WEB-INF\_tmp_war\- read)
at
org.apache.cocoon.components.language.programming.java.JavaLanguage.loadProgram(JavaLanguage.java:124)
at
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:119)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.generateResource(ProgramGeneratorImpl.java:245)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:210)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (Thread-1): ComponentFactory decommissioning
instance of
org.apache.cocoon.components.language.markup.sitemap.SitemapMarkupLanguage.
ERROR 6109 [cocoon ] (Thread-1): Error compiling sitemap
org.apache.avalon.ComponentManagerException: Could not add component for
class: org.apache.cocoon.www.sitemap_xmap
at
org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:61)
at
org.apache.cocoon.components.language.generator.GeneratorSelector.select(GeneratorSelector.java:50)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.select(ProgramGeneratorImpl.java:263)
at
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:219)
at org.apache.cocoon.sitemap.Handler.run(Handler.java:173)
at java.lang.Thread.run(Thread.java:484)
DEBUG 6109 [cocoon ] (ExecuteThread-11): Changing Cocoon
context(sitemap.xmap) to prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): from
context(file:/D:/Programs/cocoon-1.8.2/samples/) and prefix()
DEBUG 6109 [cocoon ] (ExecuteThread-11): at URI
DEBUG 6109 [cocoon ] (ExecuteThread-11): New context is
file:/D:/Programs/cocoon-1.8.2/samples/
ERROR 6140 [cocoon ] (ExecuteThread-11): Problem with servlet
org.apache.cocoon.ProcessingException: The sitemap handler's sitemap is
not available.
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:106)
at org.apache.cocoon.Cocoon.process(Cocoon.java:218)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:417)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:123)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:761)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:708)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:252)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:346)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:246)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:135)
INFO 6187 [cocoon ] (ExecuteThread-11): '' Processed by Apache
Cocoon 2.0a4 in 5.75 seconds.
================================================================
Regards,
Georgi -
Class loader: saaj-api conflict
I need to load saaj-api from my application which is newer than the one that comes w/ith oc4j 10.1.3 which is loaded by the system class loader with name api from webservices/lib/saaj-api.jar.
remove-inherited doesn't seem to do the trick.
Any suggestions would be appreciated.
Thanks,
Jindong.While I understand where you're coming from, it sounded to me that oc4j lacks the flexibility to allow application to use newer version of certain component.
For example, certain JDK level supports certain JAXP, but there is indeed an extension mechnism to allow application plug in newer JAXP?
I believe other j2ee contains are a lot flexbile in terms of this...I don't think J2EE spec says that applications running in its container can not use newer software components?
I think it only makes sense that the minimum supported level is j2ee 1.4, but nothing should stop applications from having their own version of any thing.
I strongly suggest that this to be considered for what ever release you guys are working on or a work around can be provided for the current version we're using.
Jindong. -
Apparent EJB Class Loader Issue
I am having a problem loading narrowing an EJB. It appears to be a class loader
problem. I am getting a ClassCastException with the following message: Cannot
narrow remote object to com.dte.ejb.facade.AccessoryServiceHome.
Here is my code that looks up the EJB (I've ommitted the 'catch' clauses):
EJBHome ejbHome = (EJBHome) cache.get(homeClass);
try {
Object temp = ctx.lookup("ejb/" + homeClass.getName());
if (ejbHome == null) {
ejbHome = (EJBHome) PortableRemoteObject.narrow(temp, homeClass);
cache.put(homeClass, ejbHome);
Here is the output of some debugging information from the above method. Here I've
displayed the class.getName and the class.getClassLoader for the Class object
passed to this method and the remote object being cast by the narrow method:
homeClass : com.dte.ejb.facade.AccessoryServiceHome
homeClass : weblogic.utils.classloaders.ChangeAwareClassLoader@29164c finder:
weblogic.utils.classloaders.MultiClassFinder@300ec4
From Lookup: com.dte.ejb.facade.AccessoryServiceBean_krx5el_HomeImpl
From Lookup: weblogic.utils.classloaders.GenericClassLoader@1ea02f finder: weblogic.utils.classloaders.MultiClassFinder@6fca08
As you can see, the Class passed into this method has been loaded with the ChangeAwareClassLoader
but the HomeImpl class was loaded with the GenericClassLoader. I think that is
the problem (please correct me if I am wrong).
The application in question is an .ear with 2 .war modules and a ejb.jar file.
It was my understanding that all classes needed by any module in a .ear were all
loaded with the same class loader. Is this true? If so, then why am I having this
problem?
Thank you in advance for your help.I just want to add few comments hoping the iPlanet engineer will be able to help me.
I mange to get one deployment of a war file with the client weblogic EJB to work; only if I add the Installation Directory path of the war file plus “web-inf/classes” to the classpath of the JVM configuration.
This tells me that the class loader looks for the JVM classpath to load the EJB home class at run time. I think; if I can make iPlanet class loader to look for the application classpath instead of the JVM my problem will go away.
Thank you in advance,
Nad -
Hi all,
We are experiencing a strange behaviour of the Application Class Loader. Our main issue is that if we deploy 2 applications using our code, the first application is okay, and the second application fails its loading. During the loading, we instantiate a customized InitialContextFactory (two times at all: one time per application). As a result, we have a ClassCastException in our customized InitialContext. Above a more detailed explanation of what happen. To sum up, we think that our InitialContextFactory is loaded by a master class loader, only one time for the 2 applications, and that the second application reaches the customized InitialContextFactory instantiated for the first application, so the classes loaded for the second application are not compatible.
Details:
- Each Application create a new InitialContext with the parameter "java.naming.factory.initial" equals to "com.test.CustomInitialContextFactory".
- In the class com.test.CustomInitialContextFactory we access to other code from our application, which are passed to the context factory by the environment hashtable. In the method public javax.naming.Context getInitialContext(java.util.Hashtable env), we get some parameters from the env parameter like that: CustomObject o = (CustomObject)env.get("com.test.customObject");
When the first application launches, it works very well.
When the second application launches, it fails with a ClassCastException on the class com.test.CustomObject. We think that the class com.test.CustomObject is not loaded by the good class loader so it throws a ClassCastException.
Thank you for your helpWe have found how the JNDI layer builds the specified context factory:
ClassLoader cl = (ClassLoader) AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
return Thread.currentThread().getContextClassLoader();
But OC4J has specific Thread ClassLoader: this is the cause of all our problem. So there is a solution: create a specific context factory which calls the good class loader to load the context factory.
Bye -
Hi,
I have a static block within a JSP page that get executed twice when it's being executed!
Based on the output, you can see that it's being loaded by two separated class loaders:
'weblogic.utils.classloaders.RecursiveReloadOnModifyClassLoader$Slave' and 'weblogic.servlet.jsp.OneOffJspLoader'.
Can anyone shed some light on this issue? I can see that this might cause a lot
of problem if the logic relies on the static block only executing once.
thanks,
-vu
/** Code starts here **/
<%!
static
System.out.println("\n\nThis is the static block!!!!");
try {
System.out.println("Static classloader: " +
Class.forName("jsp_servlet._helloworld").getClassLoader().getClass().getName()
+ "\n\n");
catch (java.lang.ClassNotFoundException cne) { }
%>
<%
System.out.println("Hello World.");
System.out.println("Class name: " + this.getClass().getName());
System.out.println("Class loader: " +
page.getClass().getClassLoader().getClass().getName());
%>
/** code ends here **/
/** Program's Output to Stdout **/
This is the static block!!!!
Static classloader: weblogic.utils.classloaders.RecursiveReloadOnModifyClassLoader$Slave
This is the static block!!!!
Static classloader: weblogic.servlet.jsp.OneOffJspLoader
Hello World.
Class name: jsp_servlet._helloworld
Class loader: weblogic.servlet.jsp.OneOffJspLoader
/** End OUtput **/
Well, I wouldn't say expected - obviously this poster (and others)
don't expect it, and correct is debatable.
Why in the *&^%* is it necessary to load the class twice? And I
don't mean two hours apart either - when you hit a JSP for the
first time, it gets loaded twice - one right after the other.
This wastes time and memory. When the JVMs and WLS clusters are
failing (and they are) because of too much class loading - it is
a big problem.
Mike
"Cameron Purdy" <[email protected]> wrote:
>Don't rely on static code only being executed once. What
>you are seeing is
>not only legal, it is expected and correct behavior.
>
>BTW - don't put static blocks in your JSP page. Use lazy
>initializers that
>store the result in app scope if you have to.
>
>Peace,
>
>--
>Cameron Purdy
>Tangosol, Inc.
>http://www.tangosol.com
>+1.617.623.5782
>WebLogic Consulting Available
>
>
>"Vu Nguyen" <[email protected]> wrote in message
>news:[email protected]...
>>
>> Hi,
>>
>> I have a static block within a JSP page that get executed
>twice when it's
>being executed!
>> Based on the output, you can see that it's being loaded
>by two separated
>class loaders:
>> 'weblogic.utils.classloaders.RecursiveReloadOnModifyClassLoader$Slave'
>and
>'weblogic.servlet.jsp.OneOffJspLoader'.
>> Can anyone shed some light on this issue? I can see
>that this might
>cause a lot
>> of problem if the logic relies on the static block only
>executing once.
>>
>> thanks,
>> -vu
>>
>>
>>
>> /** Code starts here **/
>> <%!
>> static
>> {
>> System.out.println("\n\nThis is the static block!!!!");
>> try {
>> System.out.println("Static classloader:
>" +
>>
>Class.forName("jsp_servlet._helloworld").getClassLoader().getClass().getName
>()
>> + "\n\n");
>> }
>> catch (java.lang.ClassNotFoundException cne) { }
>> }
>> %>
>>
>> <%
>> System.out.println("Hello World.");
>> System.out.println("Class name: " + this.getClass().getName());
>> System.out.println("Class loader: " +
>> page.getClass().getClassLoader().getClass().getName());
>> %>
>> /** code ends here **/
>>
>>
>> /** Program's Output to Stdout **/
>> This is the static block!!!!
>> Static classloader:
>weblogic.utils.classloaders.RecursiveReloadOnModifyClassLoader$Slave
>>
>>
>>
>>
>> This is the static block!!!!
>> Static classloader: weblogic.servlet.jsp.OneOffJspLoader
>>
>>
>> Hello World.
>> Class name: jsp_servlet._helloworld
>> Class loader: weblogic.servlet.jsp.OneOffJspLoader
>>
>> /** End OUtput **/
>
>
-
Questin on class loader hierarchy issue
Hi -we are running weblogic 81sp2 on Sun
We are expericenceing a problem in the following scenario
EJB in Earfile 1 makes an rmi call to EJB2 in Ear file 2.
the EJB tries to reference a class in a jar in its ear's APP-INF/lib
Both Ears are deployed to the same weblogic server instance
the exception we get is java.rmi.RemoteException: EJB Exception: ; nested exception is:
java.lang.NoClassDefFoundError: org/exolab/castor/xml/ValidationException
the jar file in question taht contains this class is not in the system class path - (unless weblogic uses this internally in some of its jars)
Any hints as to what could be causing this?
THanks
RajU are saying that jar file that contains this class is not in system classpath. From the error, it is clear that this class is not part of extensions class loader also. Hence, I guess the best way would be incl. this jar in the class path and try it out.
-
Help! -- different class loader issue
From within an EJB I am trying to cast a serializable object, that was passed into this EJB, to its original type. The process ended with a ClassCastException, even though I have double checked that the object being casted is of the correct type and fully qualified package path. It turns out that the problem is caused by the involvment of 2 different class loaders -- The class loader that loads the object is not the same one that loads the EJB doing the casting. The thing that confuses me the most is that this program used to work fine without the exception when it was running in an older environment. Is this a VM issue? Do we have control over what class loader to use when load certain classes/objects? What's the fix to the problem?
Please help!
Thanks in advance.
LifengIt is a Java platform version issue. Since Java 2 The classloaders are lay out in a hierarchy. You can read about it in the public chapters of the book "Inside the Java 2 Virtual Machine" by Bill Venners at
www.artima.com
This may be helpful for you . It specifies the class loaders used by a thread to load subsequent classes: aThread.setContextClassLoader(aClassLoader)
Other soulution is to have the object and EJB being loaded by the same class loader, which could be a common parent class loader for the ones that in your code are actually asked to load these objects
Otherwise, java.lang.reflect can deal with objects whose type is not known by the compiler.
Maybe you are looking for
-
Login with password and screen zooms to maximum size
This just started happening. Startup my Quad Core 2.66, with 10.6.8 (all SW updates), login, and screen zooms to maximum zoom with giant cursor in the middle. The only easy way get it back down to normal res is to do command+esc to get to Front Row,
-
Plsss help me: how to set default values in html:file and html:radio
Hai, To set default value to text box i use the following code. It works well. <html:text property="modifyserverdesc" value="<%= serverDesc%>" styleClass="text" size="38"/>But for file i use the code <html:file styleClass="file" property="modifyserve
-
GL account to be changed for a return by using AUART
Can someone please advice on how I can go about doing this. I looked at the help and the substitutions and found that to add AUART to KOMKCV it needs to be in VBRK and the substitutions have BKPF and BSEG so I am still trying to find a way to do this
-
How to change volume on your ringBACK tones?
It's way too loud, but I don't know how to change it. Curve 9300 THANKS!
-
Problems with Dynamic PDF design
I have created a dynamic PDF Form having 30 text fields in a row. All these fields are bounded to XSD. The design is like, a row of fields display a single user informations. When I import a XML with 100 user informations, then my PDF crashes. If I i