[JBoss JIRA] Updated: (JBAS-3188) Reduce the dependencies specified by web-console so it can be installed in more profiles.
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3188?page=all ]
Dimitris Andreadis updated JBAS-3188:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
Darran, I'm deferring this, unless you want to do it for 4.0.5.CR1
> Reduce the dependencies specified by web-console so it can be installed in more profiles.
> -----------------------------------------------------------------------------------------
>
> Key: JBAS-3188
> URL: http://jira.jboss.com/jira/browse/JBAS-3188
> Project: JBoss Application Server
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Installer
> Affects Versions: JBossAS-4.0.3 SP1, JBossAS-4.0.4.GA
> Reporter: Darran Lofthouse
> Assigned To: Darran Lofthouse
> Fix For: JBossAS-4.0.6.CR1
>
>
> The web-console has been implemented to it is not strictly dependent on the components it makes available through it's interface, if any component it makes available through the interface is not installed then initialisation will fail just for that component and it will not be added to the tree. The remaining components will still be added to the tree and the web-console will continue to work correctly.
> The installer should be updated so the web-console is dependent on less components so it can be installed in more profiles.
> This will also get rid of another problem where the web console is dependent on specifc versions of components e.g. At the moment it is dependent on the JDK 1.4 version of AOP so can not be installed in any profile that uses the JDK 5.0 version of AOP.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ]
Dimitris Andreadis updated JBAS-3198:
-------------------------------------
Fix Version/s: (was: JBossAS-4.0.5.CR1)
> Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).
> -----------------------------------------------------------------------------------
>
> Key: JBAS-3198
> URL: http://jira.jboss.com/jira/browse/JBAS-3198
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ClassLoading
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5
> Reporter: Eric Hambuch
> Assigned To: Scott M Stark
>
> When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders.
> More detailed:
> I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs.
> When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception:
> java.rmi.ServerException: RuntimeException; nested exception is:
> java.lang.IllegalArgumentException: argument type mismatch
> at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
> at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> 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:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146)
> at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213)
> at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268)
> at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139)
> 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:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106)
> at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158)
> at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR).
> With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders?
> I created a minimized example that can be provided if required.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Commented: (JBAS-3143) JACC isUserInRole and isCallerInRole Testcase retrofit
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3143?page=comments#action_12340074 ]
Dimitris Andreadis commented on JBAS-3143:
------------------------------------------
Anil, you need to decide if you're going to work on this for 4.0.5.CR1
> JACC isUserInRole and isCallerInRole Testcase retrofit
> ------------------------------------------------------
>
> Key: JBAS-3143
> URL: http://jira.jboss.com/jira/browse/JBAS-3143
> Project: JBoss Application Server
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: JBossAS-4.0.4.CR2
> Reporter: Anil Saldhana
> Assigned To: Anil Saldhana
> Fix For: JBossAS-5.0.0.Beta, JBossAS-4.0.5.CR1
>
>
> As described in the forum thread, when jacc is enabled, the behavior that is seen for programmatic security checks made for the Web and the EJB layer is dependent on whether the DD (web.xml and ejb-jar.xml) define the roles (as part of security-role and/or security-role-ref elements) completely or partially.
> The testcases (mainly the UserInRoleUnitTestCase and the CallerInRoleUnitTestCase) should be retrofitted to handle both the cases - one when the DD is partially descibed and the other when it is fully described.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3127) org.jboss.varia.scheduler.ScheduleManager.ScheduleInstance.stop() called twice
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3127?page=all ]
Dimitris Andreadis updated JBAS-3127:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> org.jboss.varia.scheduler.ScheduleManager.ScheduleInstance.stop() called twice
> ------------------------------------------------------------------------------
>
> Key: JBAS-3127
> URL: http://jira.jboss.com/jira/browse/JBAS-3127
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Other
> Affects Versions: JBossAS-4.0.3 SP1
> Reporter: Dimitris Andreadis
> Fix For: JBossAS-4.0.6.CR1
>
>
> A bogus exception is thrown when shutting down the server in the all (clusterred) configuration:
> 21:03:16,609 INFO [Server] Runtime shutdown hook called, forceHalt: true
> 21:03:16,609 INFO [Server] JBoss SHUTDOWN: Undeploying all packages
> 21:03:16,619 ERROR [ScheduleManager] Could not stop a Schedule
> javax.management.ListenerNotFoundException: Listener not found org.jboss.varia.s
> cheduler.ScheduleManager$MBeanListener@9d2f26 for object name jboss:service=Timer
> at org.jboss.mx.notification.MBeanServerListenerRegistry.remove(MBeanServerListenerRegistry.java:139)
> at org.jboss.mx.server.MBeanServerImpl.removeNotificationListener(MBeanServerImpl.java:820)
> at org.jboss.varia.scheduler.ScheduleManager$ScheduleInstance.stop(ScheduleManager.java:835)
> at org.jboss.varia.scheduler.ScheduleManager.removeSchedule(ScheduleManager.java:325)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> The problem can be demonstrated by uncommenting the single schedule provider example, then letting the schedule execute its 10 repetitions, then stop the server.
> By looking in the code ScheduleInstance.stop() is called twice:
> a) when a schedule has expired
> b) when the schedule provider deregisters.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3086) MANIFEST Class-Path entires for optional libraries within an EAR have limited scope over the modules within the EAR itself
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3086?page=all ]
Dimitris Andreadis updated JBAS-3086:
-------------------------------------
Fix Version/s: (was: JBossAS-4.0.5.CR1)
> MANIFEST Class-Path entires for optional libraries within an EAR have limited scope over the modules within the EAR itself
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JBAS-3086
> URL: http://jira.jboss.com/jira/browse/JBAS-3086
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployment services
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Windows XP Service Pack 2, JDK 1.5.0_06, JBoss is installed in C:\dev\jboss-4.0.3SP1, latest cygwin environment to start and stop JBoss from a shell
> Reporter: Alexander Sack
>
> I have JBoss 4.0.3SP1 with EAR isolation turned on via the ear.deployer service xml config file. I have the following EAR format:
> my.ear:
> META-INF/application.xml
> my.jar
> lib/ibatis-common-2.jar
> lib/ibatis-sqlmap-2.jar
> lib/ibatis-dao-2.jar
> In the application.xml, the my.jar is the only defined module. It is an EJB3 package:
> my.jar:
> META-INF/MANIFEST.MF
> com/blah/blah/ibatis/config/sql-map-config.xml
> com/blah/blah/ibatis/map/Mapfile.xml
> So my.jar needs the iBatis library to function properly (there is a class in there that wraps a DAO). Therefore, using the current J2EE 1.4 approach, I use the MANIFEST Class-Path attribute to reference my optional library within my.jar::
> MANIFEST.MF:
> Class-Path: lib/ibatis-common-2.jar lib/ibatis-sqlmap-2.jar lib/ibatis-dao-2.jar
> Deployment works in that now my.jar does indeed have access to the ibatis libraries packaged with the my.ear archive. However, now any side XML files needed by iBatis are no longer visible by the libraries themselves. For example, I have a class within my.jar like this:
> public class MyClass {
> SqlMapClient _sqlMapClient;
> static {
> try {
> String configFile = "com/blah/blah/blah/ibatis/config/sql-map-config.xml";
> Resources resource = Resources.getReousrce(configFile);
> SqlMapClient _sqlMapClient = buildSqlMap(resource);
> } catch (Exception e) {
> etc.
> }
> }
> }
> iBatis fails with an IOException claiming it can not find the sql-map-config file packaged withih my.jar module in my.ear. If I package all of my config files in their own separate jar archive (ibatis-config.jar) and put that on the Class-Path that also doesn't work. This could be pilot error on my part but I believe this should work.
> Bottom line for me is that libraries as well as my modules should always have some level of scope across the EAR they are packaged in. I have not started to debug JBoss but I would guess that the MANIFEST entries are not part of the EAR classloader repository but part of the system classloader one. My understanding of classloading is that with EAR isolation, JBoss should first delegate to the parent classloader of the EAR and if the resource is not found, search the EAR itself (unless java2Paranet delegation is turned off which case the UCL is not checked first for cached resources but instead looks directly at the EAR itself).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3087) SecurityManager - exception when redeploying a WAR file
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3087?page=all ]
Dimitris Andreadis updated JBAS-3087:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
> SecurityManager - exception when redeploying a WAR file
> -------------------------------------------------------
>
> Key: JBAS-3087
> URL: http://jira.jboss.com/jira/browse/JBAS-3087
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Microsoft Windoxs XP Professional Service Pack 2
> Java JDK 1.5.0_05
> Reporter: Paul Sideleau
> Assigned To: Anil Saldhana
> Fix For: JBossAS-4.0.6.CR1
>
> Time Spent: 15 minutes
> Remaining Estimate: 0 minutes
>
> When redeploying a WAR file with a SecurityManager running, I get the following exception (debug logging included):
> 2006-04-10 15:32:09,874 DEBUG [org.jboss.web.WebModule] Starting jboss.web.deployment:war=myTestWar.war,id=-2101272784
> 2006-04-10 15:32:09,874 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] webContext: null
> 2006-04-10 15:32:09,874 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] warURL: file:/C:/Documents and Settings/paul_sideleau/My Documents/jboss-4.0.3SP1/server/dev/tmp/deploy/tmp2472myTestWa-exp.war/
> 2006-04-10 15:32:09,874 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] webAppParser: org.jboss.web.AbstractWebDeployer$DescriptorParser@1dbe098
> 2006-04-10 15:32:09,874 DEBUG [org.jboss.web.WebPermissionMapping] Qualified url patterns: {/admin/*=PatternInfo[pattern=/admin/*,type=1,isOverriden=false,qualifiers=[]], /=PatternInfo[pattern=/,type=3,isOverriden=false,qualifiers=[PatternInfo[pattern=/admin/*,type=1,isOverriden=false,qualifiers=[]], PatternInfo[pattern=/MyServlet,type=4,isOverriden=false,qualifiers=[]]]], /MyServlet=PatternInfo[pattern=/MyServlet,type=4,isOverriden=false,qualifiers=[]]}
> 2006-04-10 15:32:09,937 INFO [org.jboss.web.tomcat.tc5.TomcatDeployer] deploy, ctxPath=/mycontext, warUrl=.../tmp/deploy/tmp2472myTestWar-exp.war/
> 2006-04-10 15:32:09,937 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] AbstractWebContainer.parseWebAppDescriptors, Begin
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] Creating ENC using ClassLoader: java.net.FactoryURLClassLoader@17f673b
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] ..org.jboss.mx.loading.UnifiedClassLoader3@9a4ba3{ url=file:/C:/Documents and Settings/paul_sideleau/My Documents/jboss-4.0.3SP1/server/dev/tmp/deploy/tmp2472myTestWar-exp.war/ ,addedOrder=43}
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] ..org.jboss.system.server.NoAnnotationURLClassLoader@1c0ec97
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] ..sun.misc.Launcher$AppClassLoader@7ced01
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] ..sun.misc.Launcher$ExtClassLoader@1ac04e8
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] Linked java:comp/UserTransaction to JNDI name: UserTransaction
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] addEnvEntries
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkResourceEnvRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkResourceRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkMessageDestinationRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkEjbRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkEjbLocalRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkServiceRefs
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] linkSecurityDomain
> 2006-04-10 15:32:09,953 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] Linking security/securityMgr to JNDI name: java:/jaas/SSI-Software
> 2006-04-10 15:32:09,968 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] AbstractWebContainer.parseWebAppDescriptors, End
> 2006-04-10 15:32:09,968 DEBUG [org.jboss.web.tomcat.tc5.TomcatDeployer] Already exists, destroying jboss.web:j2eeType=WebModule,name=//localhost/mycontextJ2EEApplication=none,J2EEServer=none
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/mycontext]] Stopping filters
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/mycontext]] Stopping filter 'CommonHeadersFilter'
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/mycontext] Stopping filter 'RequestEncoder'
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] loadClass(javax.servlet.ServletRequest, false)
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] Delegating to parent classloader1 java.net.FactoryURLClassLoader@7b9969
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] Searching local repositories
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] findClass(javax.servlet.ServletRequest)
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] securityManager.checkPackageDefinition
> 2006-04-10 15:32:09,968 DEBUG [org.apache.catalina.loader.WebappClassLoader] findClassInternal(javax.servlet.ServletRequest)
> 2006-04-10 15:24:08,583 WARN [org.apache.catalina.loader.WebappClassLoader] Failed to open JAR
> java.util.zip.ZipException: The system cannot find the file specified
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:203)
> at java.util.jar.JarFile.<init>(JarFile.java:132)
> at java.util.jar.JarFile.<init>(JarFile.java:97)
> at org.apache.catalina.loader.WebappClassLoader.openJARs(WebappClassLoader.java:1544)
> at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1763)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1570)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:850)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1299)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2365)
> at java.lang.Class.getMethod0(Class.java:2611)
> at java.lang.Class.getMethod(Class.java:1579)
> at org.apache.catalina.security.SecurityUtil.createMethodAndCacheIt(SecurityUtil.java:343)
> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:211)
> at org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:177)
> at org.apache.catalina.core.ApplicationFilterConfig.release(ApplicationFilterConfig.java:251)
> at org.apache.catalina.core.StandardContext.filterStop(StandardContext.java:3575)
> at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4249)
> at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
> at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
> 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:585)
> at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:157)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:88)
> at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
> at org.jboss.web.WebModule.startModule(WebModule.java:68)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:230)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:428)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy31.start(Unknown Source)
> at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:400)
> 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:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy32.start(Unknown Source)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
> I'm not sure if this is a bug or not. The application does get deployed correctly after the exception is thrown. However, if I run JBOSS without a security manager, the exception does not occur.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Updated: (JBAS-3093) Undeploying WAR from vitual host does not work correctly.
by Dimitris Andreadis (JIRA)
[ http://jira.jboss.com/jira/browse/JBAS-3093?page=all ]
Dimitris Andreadis updated JBAS-3093:
-------------------------------------
Fix Version/s: JBossAS-4.0.6.CR1
(was: JBossAS-4.0.5.CR1)
No input at this point, so defer
> Undeploying WAR from vitual host does not work correctly.
> ---------------------------------------------------------
>
> Key: JBAS-3093
> URL: http://jira.jboss.com/jira/browse/JBAS-3093
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployment services
> Affects Versions: JBossAS-4.0.3 SP1
> Environment: Microsoft Windows XP Service Pack 2
> JDK 1.5.0_05
> Running with Java SecurityManager turned on.
> Reporter: Paul Sideleau
> Assigned To: Remy Maucherat
> Fix For: JBossAS-4.0.6.CR1
>
>
> I have a class that implements a javax.servlet.ServletContextListener. The contextDestroyed method is correctly called and executes without errors when I delete my WAR file from the deploy directly. However, if I use virtual hosts and add a virtual-host element to my jboss-web.xml file, the contextDestroyed method is not called when I delete my WAR file. The contextDestroyed method is only called when I redeploy the WAR. This also sometimes causes the following exception:
> 3:00:40,816 WARN [WebappClassLoader] Failed to open JAR
> java.util.zip.ZipException: The system cannot find the path specified
> at java.util.zip.ZipFile.open(Native Method)
> at java.util.zip.ZipFile.<init>(ZipFile.java:203)
> at java.util.jar.JarFile.<init>(JarFile.java:132)
> at java.util.jar.JarFile.<init>(JarFile.java:97)
> at org.apache.catalina.loader.WebappClassLoader.openJARs(WebappClassLoader.java:1544)
> at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1763)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1570)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:850)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1299)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.jboss.bugtest.servlet.TestServletContextListener.contextDestroyed(TestServletContextListener.java:27)
> at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3710)
> at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283)
> at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
> at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
> 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:585)
> at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:157)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:88)
> at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
> at org.jboss.web.WebModule.startModule(WebModule.java:68)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:230)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:428)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy31.start(Unknown Source)
> at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:400)
> 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:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy32.start(Unknown Source)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
> 13:00:41,191 DEBUG [WebappClassLoader] -->RuntimeException Rethrown
> java.lang.NullPointerException
> at org.apache.catalina.loader.WebappClassLoader.findResourceInternal(WebappClassLoader.java:1766)
> at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1570)
> at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:850)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1299)
> at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1181)
> at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
> at com.jboss.bugtest.servlet.TestServletContextListener.contextDestroyed(TestServletContextListener.java:27)
> at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3710)
> at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4283)
> at org.apache.catalina.core.ContainerBase.destroy(ContainerBase.java:1131)
> at org.apache.catalina.core.StandardContext.destroy(StandardContext.java:4358)
> 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:585)
> at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:503)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:150)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeployInternal(TomcatDeployer.java:157)
> at org.jboss.web.tomcat.tc5.TomcatDeployer.performDeploy(TomcatDeployer.java:88)
> at org.jboss.web.AbstractWebDeployer.start(AbstractWebDeployer.java:357)
> at org.jboss.web.WebModule.startModule(WebModule.java:68)
> at org.jboss.web.WebModule.startService(WebModule.java:46)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:274)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:230)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:943)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:428)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy31.start(Unknown Source)
> at org.jboss.web.AbstractWebContainer.start(AbstractWebContainer.java:400)
> 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:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy32.start(Unknown Source)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:989)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:790)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:753)
> at sun.reflect.GeneratedMethodAccessor48.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:319)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:507)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:192)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:203)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:182)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months
[JBoss JIRA] Commented: (HIBERNATE-41) Usage of load() in PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock
by Yegor Yenikyeyev (JIRA)
[ http://jira.jboss.com/jira/browse/HIBERNATE-41?page=comments#action_12340066 ]
Yegor Yenikyeyev commented on HIBERNATE-41:
-------------------------------------------
Well i really won't dictate this point of view. My proposal decribed above is based upon three thoughts:
(1) There is no need to put newly loaded data into L2 as long as they are available in L1/session. I assume this normally works for "within the transaction" and for PROPAGATION_REQUIRES_NEW in combination with READ_UNCOMMITED. This makes me thing that putting into L2 *during a transaction* is not 100% necessary. Do you see any other major reasons why it need to be stored into L2 before a commit is invoked?
(2) Second and the most important as for me. When we put into L2 it keeps write lock for that key until unlock interceptor called (which won't happen until the transaction is done). With pessimistic locks and READ_UNCOMMITED it's painful b/c i can't obtain the same instance of Round object in PROPAGATION_REQUIRES_NEW method wich i call from withing the transaction. As soon as i call this method and it loads Round with FOR_UPGRADE mode it tries to put newly loaded instance to L2 again. But the write lock is still there! With optimistic locks you could probably ignore exception caused by existing write lock and continue without updating L2 instance but it's impossible with pessimistic locks.
Do you see any other ways of how can i load the same object instance in both transactions when tx1 calls tx2?
(3) Finally, we really want a better performance for our system from L2 (and i suppose everyone does 8-). Why don't we improve concurrency of the ORM layer by decreasing total time of a write lock? Don't you think that using tx commit interceptor(s) for putting object(s) into L2 cache could improve concurrency?
Also i would like to ask you this: Do you think that the deadlock i'm getting is something you guys wanted to add to Hibernate "by design"? I'm just trying to figure out if this is a *real* problem b/c for now i do not see why anybody can say that the program flow we have is illegal or makes no sense or contains a mistake. If it's really my code problem then i would like to check what is the expected flow for that task. Please advise.
Thanks!
> Usage of load() in PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock
> ------------------------------------------------------------------------------------------------
>
> Key: HIBERNATE-41
> URL: http://jira.jboss.com/jira/browse/HIBERNATE-41
> Project: Hibernate
> Issue Type: Bug
> Environment: SUSE 10.1, kernel 2.6.15 SPM, JDK 1.5.0_06, PostgreSQL 8.0.1
> Reporter: Yegor Yenikyeyev
> Assigned To: Steve Ebersole
> Priority: Blocker
> Attachments: nloptc.zip
>
>
> It seems like we discovered an unpredictable Hibernate and/or TreeCache behavior after upgrade JBossCache from 1.2.4SP2 to JBossCache 1.3.0SP2. For now I can witness that the same problem appears with 1.4.0CR2. I do not think that it's Hibernate-only or TreeCache-only issue but I do think it's a kind of integration issue or misunderstanding of how TreeCache transaction isolation is implemented. According Manik Surtani JBossCache v1.2.4 had an issue with READ_COMMITED implementation (JBCACHE-218 ) and sinnce it fixed any usage of PROPAGATION_REQUIRES_NEW within PROPAGATION_REQUIRED method causes a deadlock if both method load same instance of an entiry.
> Our application works in clustered environment and we use JBossCache as L2 cache solution for Hibernate 3.1.3 (I checked this with 3.2.0CR2 as well). Our settings for JBossCache are
> REPL_SYNC, READ_COMMITED and our target business object methods (f1 and f2) have PROPAGATION_REQUIRED and PROPAGATION_REQUIRES_NEW. Our JDBC driver is 3.0 compliant.
> Our objects hierarchy is like: Occasion contains link to Round and Round contains link to Tournament. Round is NOT configured as "lazy" field in Occasion mapping b/c we always need to have it initialized.
>
> Here is in short what we try to do in our application:
>
> (1) Transaction1: Call f1 (PROPAGATION_REQUIRED) method of a business object and it causes Occasion1 to be loaded via a cachable query. After that Hibernate initializes Occasion1.round field and loads Round1.
> (2) Transaction1: Hibernate puts loaded Occasion1 and Round1 in L2 cache.
> (3) Transaction1: TreeCache creates com/companyname/Occasion/com.companyname.Occasion#1 region and obtains WriteLock (WL1)
> (4) Transaction1: TreeCache creates com/companyname/Round/com.companyname.Round#1 region and obtains WriteLock (WL2)
> (5) Transaction1: Do some business logic stuff
> (6) Transaction1: We expect current transaction to be long and we want to change status of Occasoin1 in DB very quickly. At this point we need an exclusive lock for appropriate row in DB table to change the status and commit it. In order to do this we call f2 (PROPAGATION_REQUIRES_NEW) which suppose to be a REALLY short transaction which release lock on the DB row as fast as possible.
>
> (7) Transaction2: Transaction1 SUSPENDED at this point. We call HibernateTemplate (we use Spring as well) to load Occasion1 for update with LockMode.UPGRADE flag and get exclusive lock.
> (8) Transaction2: Hibernate does NOT check for an instance of Occasion1 in L2 cache ( I suppose it's b/c we obviously do want to lock it for update )
> (9) Transaction2: Hibernate does check for an instance of Round1 in L2 cache and it calls get() on TreeCache to obtain com/companyname/Round/com.companyname.Round#1
> (10) Transaction2: At this point 1.3.0SP2 tries to obtain ReadLock for com/companyname/Round/com.companyname.Round#1 and it can't b/c there is a WL for that node in suspended Transaction1 !!! It can't obtain ReadLock for Round#1 anyhow!
> (11) Transaction2: Stuck waiting for WL2 to be released in TreeCache but it can't be released as soon as Transaction1 suspended and waits for Transaction2 to finish.
>
> Obviously this situation is ridiculous - a legal sequence of operations causes a deadlock on TreeCache. We do not expect com/companyname/Round/com.companyname.Round#1 to be visible in Transaction2 b/c we use READ_COMMITED but WL2 must not affect Transaction2 in this way. As soon as TreeCache prevents other transactions from reading com/companyname/Round/com.companyname.Round#1 it must not tell other transactions that the node exists to keep READ_COMMITED behavior consistent. For now it simply preventing everybody from using PROPAGATION_REQUIRES_NEW.
> The described scenario works with 1.2.4SP2 without a problem and I have serious concern that READ_COMMITED strategy is really implemented in v1.2.4 but at least the behavior is more consistent comparing to v1.3.0. As far as i understand this is result of JBCACHE-218 bugfix.
>
> We tried to change PROPAGATION_REQUIRES_NEW to PROPAGATION_NESTED and take advantage of nested transactions. We assume that com/companyname/Round/com.companyname.Round#1 would be available in a nested Transaction2 from Transaction1. But PROPAGATION_NESTED isn't supported by current JBossTransaction implementation (see line 209 in TxManager.java from 4.0.4.GA).
> We could change isolation to READ_UNCOMMITED but it's simply impossible in many other places of our application.
> We could make a trick and load Occasion1 with Round1 in a separate Transaction0 before starting Transaction1 but we HAVE to use LRU policy. That is why there is no chance for us to make sure that eviction won't happen between Transaction0 and Transaction1. If it happened then we are in the same situation as described above.
> Finally we could stop using Transaction2 but our application is intend to handle large amount of traffic and as soon as Transaction1 takes up to 3sec (comparing to 50ms for Transaction2) we might get up to 700-1000 transactions on queue waiting for table row lock to be released and we just can't allow this.
>
> From what I see in Hibernate TreeCache sources and I have no idea how to avoid the situation described above. One of my developers told me that probably it's possible to put stuff into L2 cache on transaction commit which would decrease WL time and resolve the issue with the deadlock. Honestly I'm seriously concerned how it applies to existing Hibernate. I think small issues like performance issue of loading the same object during 1 transaction more then once can be resolved by using L1 cache or JDBC driver abilities. But I guess there are a plenty of work to make this working for cachable queries.
> Another option I see is to do a trick and put values for Round1 and Occasion1 into a new region for Transaction2 if we know that Transaction1 suspended and owns WLs for various nodes. I really do not like this way b/c in fact it's not a pure pessimistic locking. But the issue described before is worse price for "pure" READ_COMMITED strategy. In fact it showstopper assuming there is no way to use PROPAGATION_NESTED.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 10 months