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,
Georgi

Similar Messages

Dynamic class loading. *Problem*

Hi.
This is a strange one:
I'm compiling a java file dynamically and i try to load it using the current class loader. The usual way to do so is- this.getClass().getClassLoader() etc.
Now the strange part: the class loader is looking for the class file only in the class-path in which the java application was first run. There is no way to tell it to look in other directories, including the user current directory!
Changing the System properties of class path and library path do not help. The loader just remembers the initial class path and looks only there. It can't be told to look anywhere else!
Anyone has any idea how to make it look elsewhere ???? is it possible ???
Thanks!
Gil

2. i need to load the class to the same JVM (i.e. to
the same environment) of the current running
aplication, so that when the loaded class is run, it
would be able to invoke methods on it!!!
ClassLoader(s) do this. Try the URLClassLoader.
(I was talking about relatively esoteric "security"
issues when I mentioned the stuff about Class objects
"scope".) You might use the URLClassLoader kind of
like this.
Pseudo-code follows:
// setup the class loader
URL[] urls = new URL[1];
urls[0] = new URL("/path/to/dynamic/classes");
URLClassLoader ucl = new URLClassLoader(urls);
// load a class & use make an object with the default constructor
Object tmp = ucl.loadClass("dynamic.class.name").newInstance();
// Cast the object to a know interface so that you can use it.
// This may be used to further determine which interface to cast
// the class to. Or it may simply be the interface to which all
// dynamic classes have to conform in your program.
InterfaceImplementedByDynamicClass loadedObj =
(InterfaceImplementedByDynamicClass)tmp;It's really not as hard as it sounds, just write a little test of
this and you will see how it works.

JVMPI class load event problem

Hi
I'm trying to write a simple profiler using JVM Profiler Interface to
display classes loaded while running my application.
For this, I have registered callback to notify two events
JVMPI_EVENT_CLASS_LOAD and JVMPI_EVENT_CLASS_LOAD_HOOK.
Now the problem is that, for some system classes which are loaded
initialy(during JVM initialization) I'm not getting
JVMPI_EVENT_CLASS_LOAD_HOOK event. However JVMPI_EVENT_CLASS_LOAD gets
called for each of them. ( I want .._LOAD_HOOK for all classes)
I gone through some documents/links which says that
JVMPI_EVENT_CLASS_LOAD_HOOK will be sent only after
JVMPI_EVENT_JVM_INIT_DONE event is sent.
I want JVMPI_EVENT_CLASS_LOAD_HOOK event for all classes, even they
are loaded before JVM initialization is complete.
Is there any way to achieve this? Any work arround?
I'm using J2SDK 1.4.2.
Thanks in advance
Rohan

I want JVMPI_EVENT_CLASS_LOAD_HOOK event for allThe JVMPI api was always experimantal. It has now been superseded by the JVM TI work done for Tiger as part of JSR-163.
This article describes the new API and how to make the transition:
The JVMPI Transition to JVMTI
http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/
Is there any way to achieve this? Any work arround?When your monitoring agent gets control after JVMTI_EVENT_VM_INIT, use the GetLoadedClasses method to return all of the classes loaded up to that point.
If you also request notification for all subsequently loaded classes (via JVMTI_EVENT_CLASS_FILE_LOAD_HOOK) then after suspending the VM you should have information on all classes loaded since the genesis of the VM.
The HPROF profiling agent was converted to use the new class loading notification mechanism. Refer to the
I'm using J2SDK 1.4.2.I suggest you update your project to use the new APIs provided with JSRs 163 and 174.

Class Loading Security Restrictions

Hi,
Does WebLogic Server have any feature through which application code "may not" get access to BEA system classes (like classes in weblogic.jar or any security sensitive classes) ? As I understand, any application user can walk their way to BEA internal classes through classloading heirarchy or reflection ?
Thanks,
Krish

Hi Krish,
Welcome to the world of Java, where nothing is ever really inaccessible. In answer to you question, some of the functionality in terms of security is marked as private or protected internally to protect the functionality from other Java classes and inheritence, but not the ones you'd expect. The security around the Licensing classes is a substantial step above those that exist around actual authentication providers and encryption services.
To be fair though, using tools like WLST/Jython renders all internal functionality protection moot anyway, as Jython will happily run methods and classes that are scoped as private. This is a particular problem with WebLogic internal credential encryption.
Cheers,
Trevor Nielsen
londonmiddleware.org

Weblogic Class Loading issue

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

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?

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)

Implementing a secure class loader..

Hello,
We have a custom class loader which loads in custom packages from the database or from the file system. We want to ensure that these custom classes do not read or write into the file system. I want to restrict access to these classes when creating them. I read that by setting the proper permissions when defining the class, this could be possible. Here is my implementation of the class loader :
import java.io.File;
import java.io.FileInputStream;
import java.io.FilePermission;
import java.io.IOException;
import java.net.SocketPermission;
import java.net.URL;
import java.security.AccessController;
import java.security.CodeSource;
import java.security.PermissionCollection;
import java.security.Permissions;
import java.security.PrivilegedExceptionAction;
import java.security.SecureClassLoader;
public class TestClassLoader extends SecureClassLoader {
        JarParser jp;
        public TestClassLoader(JarParser jp) {
          super();
                this.jp = jp;
        public Class findClass(final String name) throws ClassNotFoundException {
               try {
                   return(Class)
                           AccessController.doPrivileged (
                                 new PrivilegedExceptionAction() {
                                               public Object run() throws ClassNotFoundException {
                                                     byte[] buf = null;
                                                        try {
                                                           if(jp == null)
                                                                  throw new ClassNotFoundException("Jar file not found");
                                                                String className = name.replace( '.', '/' ) + ".class";
                                                                buf = jp.getResource(className);
                                                                if(buf == null || buf.length == 0)
                                                                      throw new ClassNotFoundException("Class not found");
                                                                CodeSource cs = getCodeSource(name);
                                                                return defineClass(name, buf, 0, buf.length, cs);
                                                       catch(Exception e) {
                                                            throw new ClassNotFoundException(name, e);
               catch(Exception e) {
                    throw new ClassNotFoundException(name, e);
      * @param name
     protected CodeSource getCodeSource(String name) {
               try {
                   return new CodeSource(new URL("file", "localhost", name), null);
               catch(Exception e){
                     e.printStackTrace();
                return null;
        protected PermissionCollection getPermissions(CodeSource cs) {
          PermissionCollection pc = new Permissions();
                pc.add(new RuntimePermission("exitVM"));
                pc.add(new FilePermission("${user.home}${/}*", "read"));
                pc.add(new FilePermission("${user.dir}${/}*", "read"));
         pc.add(new SocketPermission("localhost", "resolve"));
                return pc;
        public static void main(String[] args) {
                try {
                   byte[] bytes = new byte[8192];
                  long ttlBytesRead = 0;
                  int noOfBytesToRead = 0;
                        File readFile = new File("test.jar");
                        // "length" here indicates the total no of bytes to read.
                      // This is equal to the file size sans the offset value.
                        long length = readFile.length();
                        Long temp;
                      FileInputStream readFis = null;
                        // Create the RandomAccessFile
                  try{
                             readFis = new FileInputStream(readFile);
                       catch(Exception e) {
                            throw new IOException(e.getMessage());
                       long tempLong;
                  StringBuffer buffer = new StringBuffer();
                        do {
                            if ((length - ttlBytesRead) > 8192)
                                     tempLong = 8192;
                                else
                                    tempLong = (length - ttlBytesRead);
                             temp = new Long((length - ttlBytesRead) > 8192 ? 8192 : (length - ttlBytesRead));
                               noOfBytesToRead = temp.intValue();
                              if(noOfBytesToRead == 0)
                                        break;
                          // Read the specified no of bytes into the byte
                                // array from the file.
                         try {
                                   readFis.read(bytes,0,noOfBytesToRead);
                               catch(Exception e1) {
                                   throw new IOException(e1.getMessage());
                               String str = new String(bytes, 0, noOfBytesToRead);
                            buffer.append(str);
                                ttlBytesRead += noOfBytesToRead;
                        } while(ttlBytesRead < length);
                 try {
                           readFis.close();
                       catch(Exception e1) {}
                        JarParser jp = new JarParser("test.jar", buffer.toString().getBytes());
                 TestClassLoader tcl = new TestClassLoader(jp);
                  Class class1 = tcl.findClass("com.test.TestFileWrite");
                 Object obj = class1.newInstance();
               catch(Exception e) {
                    e.printStackTrace();
}JarParser is the class which parses through the jar file and caches the contents as bytes.
The test.jar contains a single class which writes into the user's home directory. As you can see, I have granted only read access on the home dir.
When I run this however, the newly loaded class does manage to write into the file system with no problems. Is there anything further that I need to do to enable restriction on the file system ?
Thanks.

If I've been reading correctly, they don't want you
subclassing SecurityManager for security any more.
Everything should be handled by the AccessController
using Permission objects. The easiest way to configure
the AccessController is through policy files.erg. where did you read this? I checked the 1.5.0 beta API just now, and nothing is officially deprecated.
:{ I don't have time to figure out the AccessController API right now.
I have yet to find a good tutorial on the matter of
security and classloaders. If anyone has a good
reference, it would be much appreciated.I second that.
And as a temporary solution (because we're already behind schedule), I went ahead and wrote my own SecurityManager, using the ideas I mentioned above.
I'm posting it at the site below in case anyone can offer any feedback (such as pointing out fatal weaknesses). We tried yesterday for an hour or so to break it, and it withstood all our tests; but security is not our specialty, so there's probably room for improvement.
(I'd post it in this message, but it's a wee bit large.)
www.personal.utulsa.edu/~jeremy-wood/software/ThreadBasedSecurityManager.java
(And if it passes your scrutiny and looks useful, feel free to use it. But note the disclaimers.)

Weblogic Class Loader issues.

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,
--Das

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
          >

Bug in weblogic 8.1 SP6 at weblogic.security.SSL.SSLCertificate.verify()

Hi, I got an java.lang.NullPointerException
at weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:235)
at weblogic.security.SSL.SSLCertificate.input(SSLCertificate.java:116)
at weblogic.security.SSL.Handshake.input(Handshake.java:121)
at weblogic.security.SSL.SSLSocket.getHandshake(SSLSocket.java:1117)
at weblogic.security.SSL.SSLSocket.clientInit(SSLSocket.java:432)
at weblogic.security.SSL.SSLSocket.initialize(SSLSocket.java:276)
at weblogic.security.SSL.SSLSocket.<init>(SSLSocket.java:222)
at weblogic.security.SSL.SSLSocketFactory.createSocket(SSLSocketFactory.java:213)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:238)
at weblogic.net.http.HttpsClient.openServer(HttpsClient.java:389)
at weblogic.net.http.HttpsClient.<init>(HttpsClient.java:209)
at weblogic.net.http.HttpClient.New(HttpClient.java:228)
at weblogic.net.http.HttpsURLConnection.getHttpClient(HttpsURLConnection.java:246)
at weblogic.net.http.HttpsURLConnection.connect(HttpsURLConnection.java:217)
at weblogic.net.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:189)
when a small piece of code running in weblogic 8.1 SP6 and trying to make url connection to a https server.
I have verified that the runtime environment has the cacerts file including the CA ( issuer for the server certificate for the server the code was trying to connect to ).
I wonder that anybody has the same problem. Or you can give a hint how to fix it.
Thank you.

Sorry, i saw the forum about your problem in BEA 8.1 SP 6 about a
weblogic.security.SSL.SSLCertificate.verify(SSLCertificate.java:235)
error and you said that bea sent a path named CR295205_810sp6.jar.
I have the same problem
Do you have this patch?
Could you send it to me?
my email address is
[email protected]

Class Loading Strategy for Security MBeans

Hi, can someone point me to a good reference or explain how security mbeans load referenced classes? I'm trying to reference my auditor class, which is archived in an audit.jar, from within my authentication provider mbean implementation class. I've added the attribute class-path:audit.jar in the manifest file of the mbean jar file containing the authentication provider class. Every time I start the server I get a "NoClassDefFoundError" exception. Any ideas?

Someone else can probably answer with more authority, but I think that statement is true because Java 2 introduced context class loaders, or at least formalized the hierarchical relationship between context class loaders.
Each thread by definition has a context class loader, possibly (probably) through inheritance from its parent thread.
According to the API doc, Class.forName() loads a class using the current class's classLoader, whereas getContextClassLoader().loadClass() loads a class using the thread's context class loader.
I think there could be cases where a context class loader could have access to resoures that the class's class loader doesn't. If anyone can shed more light on this, that would be helpful.
There's some discussion of this here:
http://java.sun.com/products/jndi/tutorial/beyond/misc/classloader.html, mainly in regards to JNI.

No security manager: RMI class loader disabled

i tried to add a filter to my client jmx
my filter is:
class Filter implements NotificationFilter {
public boolean isNotificationEnabled(Notification n) {
          return (n.getType().equals("example.user.remove"))
          ? true
          : false;
in my client i use:
Filter filter=new Filter();
Listener listener=new Listener();
mbeanServer.addNotificationListener(mbeanName, listener, filter, null);
if i dont put the filter(if i use null) my client works but when i include the filter I have this error:
java.rmi.UnmarshalException: java.lang.ClassNotFoundException: Filter (no security manager: RMI class loader disabled); nested exception is:
     java.lang.ClassNotFoundException: Filter (no security manager: RMI class loader disabled)
what is wrong?

You need to make sure that Filter.class is on your classpath, either directly as the .class file or in a JAR file that is on the classpath.

No security manager: RMI class loader disabled Error at RMI client programm

Got following error on invoking remote method from RMI client,
java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: com.rmi.RmiImpl_Stub (no security manager: RMI class loader disabled)
Please let me know solution.

Hello JAAZ,
I got the same error yesterday. I was a little frustrated, because the day before everything was fine...
java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: uk.co.it.ete.server.ETE_Server (no security manager: RMI class loader disabled)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)The solution was, that I did some refactoring and some of the classes were now in different packages. I updated the system on the client-side and now everything works again.
I think debugging RMI-applications is not as easy as "normal" applications ..
maybe this helps..
Regards
tk

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
          >

Simple RMI/IIOP app : "no security manager: RMI class loader disabled"

Hello colleagues!
I do not understand the problem at all, and asking for your kind help.
This is my first code for RMI/IIOP. We are using JBoss as application server.
What I've done :
1) created test.Command interface , extending Remote
2) created test.CommandImpl , implementing above mentioned interface and java.io.Serializable, and extending javax.rmi.PortableRemoteObject.
BTW, Serializable is not implemented in some tutorials, but absence of Serializable causes NotSerializableException when trying to rebind (next step).
3) in server code, created initial context and called
context.rebind("test/Command",new CommandImpl());
4) Ran rmic -iiop test.CommandImpl . A result was two new cass files, CommandImplTie.class and CommandStub.class , both are also in package "test".
5) Created remote client and put CommandStub.class to client
classpath (under package "test", too).
6) In client code, initialized the context and called
context.lookup("test/Command").
On this line (lookup), the following exception is being raised :
javax.naming.CommunicationException. Root exception is java.lang.ClassNotFoundException: test.CommandImpl (no security manager: RMI class loader disabled)
     at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:368)
     at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:161)
     at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:631)
     at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:257)
     at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:200)
     at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1513)
     at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435)
     at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626)
     at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274)
     at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324)
     at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
     at org.jnp.interfaces.MarshalledValuePair.get(MarshalledValuePair.java:30)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:514)
     at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:471)
     at javax.naming.InitialContext.lookup(InitialContext.java:347)
Is _Stub class all that client needs from server classes, to obtain
the reference ? I tried to put _Tie also to client, but with the same result.
All Jndi paths to JBoss server are correct, as I've used them successfully in other applications.
Many thanks in advance,
Daniel

Next few words to the topic.
I made tests with canonical RMI/IIOP tutorial from Sun.
When I use Sun's ORB (orbd.exe) , everything work fine. I started
orbd on the same PC as JBoss, and client and server are running
remotely.
But with JBoss ORB, I have the same exception as described above.
Server starts and registers in JNDI successfully, but client can not
obtain a remote reference. Exception is being thrown on
context.lookup().
So the difference is definitely in security managers for two ORBs.
I also tried to create new RMISecurityMananger and set it, but with
no effect.
Any ideas ?
TIA,
Daniel.

Cocoon2 weblogic (5.1 sp6) class loader security problem

Similar Messages

Maybe you are looking for