[JBoss JIRA] Created: (JBAS-8267) MDB(Connection Consumer Thread) stop on rare occasions by JMSSecurityException
by Hiroyuki Wada (JIRA)
MDB(Connection Consumer Thread) stop on rare occasions by JMSSecurityException
------------------------------------------------------------------------------
Key: JBAS-8267
URL: https://jira.jboss.org/browse/JBAS-8267
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMS (JBossMQ)
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.0.5.GA, JBossAS-4.0.2 Final
Environment: Java VM: Java HotSpot(TM) Client VM 1.4.2_19-b04,Sun Microsystems Inc.
OS-System: Windows XP SP3
Reporter: Hiroyuki Wada
Assignee: Adrian Brock
When MDB's connection thread (Connection Consumer Thread) receive a message, JMSSecurityException is throwed on rare occasions. And the thread go down, so MDB don't be executed if a message be sent.
Following stacktrace is visible in server.log.
10:39:15,796 WARN [SpyConnectionConsumer] Connection consumer closing due to error in listening thread SpyConnectionConsumer[sub=Subscription[subId=-2147483648connection=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 destination=TOPIC.testTopic messageSelector=null Local Create] messages=0 waitingForMessage=false internalThread=Thread[Connection Consumer for dest Subscription[subId=-2147483648connection=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 destination=TOPIC.testTopic messageSelector=null Local Create] id=1,5,jboss] sessionPool=org.jboss.jms.asf.StdServerSessionPool@1ce9085 connection=Connection@13008985[token=ConnectionToken:ID:1/a347321b2793ca494842452c5278a657 rcvstate=STARTED]]
javax.jms.JMSSecurityException: User session is not valid
at org.jboss.mq.security.SecurityManager.authorize(SecurityManager.java:230)
at org.jboss.mq.security.ServerSecurityInterceptor.authorizeRead(ServerSecurityInterceptor.java:233)
at org.jboss.mq.security.ServerSecurityInterceptor.receive(ServerSecurityInterceptor.java:98)
at org.jboss.mq.server.TracingInterceptor.receive(TracingInterceptor.java:570)
at org.jboss.mq.server.JMSServerInvoker.receive(JMSServerInvoker.java:226)
at org.jboss.mq.il.jvm.JVMServerIL.receive(JVMServerIL.java:244)
at org.jboss.mq.Connection.receive(Connection.java:909)
at org.jboss.mq.SpyConnectionConsumer.run(SpyConnectionConsumer.java:238)
at java.lang.Thread.run(Thread.java:534)
It looks like a synchronization problem.
In 'org.jboss.mq.security.SecurityManager#authorize' method, 'authCache' variable is accessed by HashMap#get method but it's not synchronized.
When other thread put object to the 'authCache' variable, the HashMap#get methos will return null on rare occasions even though the key is contained.
so when the return value is null, JMSSecurityException is throwed.
SubjectInfo info = (SubjectInfo) authCache.get(token.getSessionId());
if (info == null)
throw new JMSSecurityException("User session is not valid");
I wrote a patch for JBossAS Branch_4_0 and Branch_4_2.
It is very simple patch that add synchorized block.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-7926) Quartz RA: Endpoint deactivation immediately stops classloader of (long running) quartz job
by Marcus Linke (JIRA)
Quartz RA: Endpoint deactivation immediately stops classloader of (long running) quartz job
-------------------------------------------------------------------------------------------
Key: JBAS-7926
URL: https://jira.jboss.org/jira/browse/JBAS-7926
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-6.0.0.M2
Reporter: Marcus Linke
While undeploying/stopping the MDB the QuartzResourceAdapter's 'endpointDeactivation' hook calls the quartz scheduler method 'deleteJob(..)'. This method call is nonblocking and therefore the process of stopping the MDB is continued. As part of this the classloader of the quartz job is also stopped which may prevent a long running job to successfully complete.
One possible workaround may be to use a quartz job listener here to emulate the blocking behavior and wait until a running job completes. Eventually there is a need for a timeout value then, but this could be configured by the MDB itself via ActivationConfigProperties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8369) JBoss AS CPU loop - incorrect synchronization on HashMap?
by Stephen Potter (JIRA)
JBoss AS CPU loop - incorrect synchronization on HashMap?
---------------------------------------------------------
Key: JBAS-8369
URL: https://jira.jboss.org/browse/JBAS-8369
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-5.1.0.GA
Environment: SUSE Linux 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Stephen Potter
Assignee: Remy Maucherat
Web application becomes unresponsive. JBoss java CPU at 340%. jstack shows 3 JBoss web threads in HashMap.get suggesting that the cause is incorrectly synchronized use of a HashMap. Extract of stack dump:
"ajp-127.0.0.1-50113-55" daemon prio=10 tid=0x000000004c364800 nid=0x4f1 runnable [0x00007f6f09cd7000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6f8d353200> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
"ajp-127.0.0.1-50113-15" daemon prio=10 tid=0x000000005caa6800 nid=0x15f2 runnable [0x00007f6f4073d000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6fd8a886b0> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
"ajp-127.0.0.1-50113-6" daemon prio=10 tid=0x00000000418f0000 nid=0x25d7 runnable [0x00007f6f41045000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.get(HashMap.java:303)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:71)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.injection.InjectionUtil.collapseXmlMethodInjectors(InjectionUtil.java:92)
at org.jboss.web.tomcat.service.injection.TomcatInjectionUtils.processDynamicBeanAnnotations(TomcatInjectionUtils.java:59)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processAnnotations(TomcatInjectionContainer.java:407)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.processDynamicBeanAnnotations(TomcatInjectionContainer.java:382)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:274)
at org.jboss.web.tomcat.service.TomcatInjectionContainer.newInstance(TomcatInjectionContainer.java:265)
at org.apache.jasper.servlet.JspServletWrapper.getServlet(JspServletWrapper.java:145)
- locked <0x00007f6fd40a01b8> (a org.apache.jasper.servlet.JspServletWrapper)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
. . . . . . . . . . . . .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8741) Linux multicast issue using IPv4 addresses and IPv6 stack
by Richard Achmatowicz (JIRA)
Linux multicast issue using IPv4 addresses and IPv6 stack
----------------------------------------------------------
Key: JBAS-8741
URL: https://issues.jboss.org/browse/JBAS-8741
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Integration
Affects Versions: 6.0.0.M4
Reporter: Richard Achmatowicz
Assignee: Shelly McGowan
Fix For: TBD-6.x
The test cases org.jboss.test.util.test.TwiddleUnitTestCase.{testGet, testInvoke} are failing.
One problem is that the twiddle option -o is not correctly handling IPv6 addresses; for example:
[rachmatowicz@soa3 bin]$ ./twiddle.sh -o fec0:0:a16:ffff::13 get "jboss.system:type=Server" Started
15:17:53,066 ERROR [Twiddle] Exec failed
org.jboss.util.NestedRuntimeException: For input string: "0:a16:ffff::13:1090"; - nested throwable: (java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090")
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:208)
at org.jboss.console.twiddle.command.MBeanServerCommand.getMBeanServer(MBeanServerCommand.java:64)
at org.jboss.console.twiddle.command.GetCommand.execute(GetCommand.java:149)
at org.jboss.console.twiddle.Twiddle.main(Twiddle.java:357)
Caused by: java.lang.NumberFormatException: For input string: "0:a16:ffff::13:1090"
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:458)
at java.lang.Integer.parseInt(Integer.java:499)
at com.sun.jndi.url.rmi.rmiURLContext.getRootURLContext(rmiURLContext.java:86)
at com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:182)
at javax.naming.InitialContext.lookup(InitialContext.java:392)
at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1886)
at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856)
at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257)
at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at org.jboss.console.twiddle.Twiddle.createMBeanServerConnection(Twiddle.java:309)
at org.jboss.console.twiddle.Twiddle.connect(Twiddle.java:318)
at org.jboss.console.twiddle.Twiddle.access$400(Twiddle.java:60)
at org.jboss.console.twiddle.Twiddle$1.getServer(Twiddle.java:204)
... 3 more
This is a typical IPv6 URL creation issue, as the issue can be fixed by surrouning the IPv6 address literal in square brackets:
[rachmatowicz@soa3 bin]$ ./twiddle.sh -o [fec0:0:a16:ffff::13] get "jboss.system:type=Server" Started
Started=true
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8353) PATCH: Support obfuscated System Properties
by Andrew Oliver (JIRA)
PATCH: Support obfuscated System Properties
-------------------------------------------
Key: JBAS-8353
URL: https://jira.jboss.org/browse/JBAS-8353
Project: JBoss Application Server
Issue Type: Patch
Security Level: Public (Everyone can see)
Environment: ALL
Reporter: Andrew Oliver
Assignee: Andrew Oliver
when you put -Djboss.sysprop.obfuscation in your run.conf JBOSS_OPTS, the SecurityIdentityLoginModule decode function is used to decode properties ending in _OBFUSCATED
i.e.
server/default/conf/test.properties
mypassword_OBFUSCATED=5dfc52b51bd35553df8592078de921bc
server/default/deploy/properties-service.xml
<mbean code="org.jboss.varia.property.SystemPropertiesService"
name="jboss:type=Service,name=SystemProperties">
<attribute name="URLList">
./conf/test.properties
</attribute>
</mbean>
then in your System.getProperties you have:
mypassword password
mypassword_OBFUSCATED 5dfc52b51bd35553df8592078de921bc
So you can then use those properties in your config files with ${mypassword}
you can use the same tool in: http://community.jboss.org/wiki/EncryptingDataSourcePasswords to obfuscate passwords in the property file...
This helps you pass dumb security audits that require you to do dumb things that have nothing to do with security but fake security through needless labor is an industry standard that we have to live with.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8624) JBoss 5.1.0 sometimes can't undeploy war application
by Dmitry Geurkov (JIRA)
JBoss 5.1.0 sometimes can't undeploy war application
----------------------------------------------------
Key: JBAS-8624
URL: https://jira.jboss.org/browse/JBAS-8624
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossAS-5.1.0.GA
Environment: Windows 7 Operating System, Oracle Java 1.6.0_21
Reporter: Dmitry Geurkov
Priority: Minor
Sometimes during development web applications stuck and can't be undeployed. manually removing war archive is not possible because system says that file is used by another program.
But no other programs use archive except jboss process. Trying to remove stucked web application from Admin Console only stops the application but not removes it completely. The following exception is thrown in during the click on remove button in Admin Console
14:55:51,376 INFO [DeployHandler] Stop, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:51,376 INFO [DeployHandler] End stop, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:51,381 INFO [DeployHandler] Remove, [vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/]
14:55:53,385 INFO [DeployHandler] Failed to complete command: [remove] for deployment: names=[vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/], copyContent=true
java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:268)
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:229)
at org.jboss.profileservice.management.upload.remoting.DeployHandler.removeDeployment(DeployHandler.java:176)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.remove(AbstractDeployHandler.java:333)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:185)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.remove(StreamingDeploymentTarget.java:229)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.remove(DeploymentProgressImpl.java:321)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:94)
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.deleteResource(StandaloneManagedDeploymentComponent.java:326)
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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
14:55:53,843 ERROR [StandaloneManagedDeploymentComponent] Failed to remove deployment 'vfszip:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war/'.
java.lang.RuntimeException: java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:313)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.remove(StreamingDeploymentTarget.java:229)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.remove(DeploymentProgressImpl.java:321)
at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:94)
at org.rhq.plugins.jbossas5.util.DeploymentUtils.run(DeploymentUtils.java:120)
at org.rhq.plugins.jbossas5.StandaloneManagedDeploymentComponent.deleteResource(StandaloneManagedDeploymentComponent.java:326)
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.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:482)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Failed to delete: DelegatingHandler(a)15550946[path=docflowweb.war context=file:/D:/jboss-5.1.0.GA/server/default/deploy/ real=file:/D:/jboss-5.1.0.GA/server/default/deploy/docflowweb.war]
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:268)
at org.jboss.system.server.profileservice.repository.BasicDeploymentRepository.removeDeployment(BasicDeploymentRepository.java:229)
at org.jboss.profileservice.management.upload.remoting.DeployHandler.removeDeployment(DeployHandler.java:176)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.remove(AbstractDeployHandler.java:333)
at org.jboss.profileservice.management.upload.remoting.AbstractDeployHandler.invoke(AbstractDeployHandler.java:185)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:891)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:1724)
at org.jboss.remoting.Client.invoke(Client.java:629)
at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:305)
... 15 more
14:55:54,153 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
14:55:54,159 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null
I think some thread in JBoss locks the war archive. something related to new vfs system that was introduced in JBoss 5.
No such problems occurred in JBoss 4.2.3 or early versions.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (JBAS-8719) Fix OSGi example/functional test regression against Arquillian subsystem
by Thomas Diesler (JIRA)
Fix OSGi example/functional test regression against Arquillian subsystem
------------------------------------------------------------------------
Key: JBAS-8719
URL: https://jira.jboss.org/browse/JBAS-8719
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: OSGi integration
Reporter: Thomas Diesler
Assignee: Thomas Diesler
The Arquillian subsystem is a general replacement for the arquillian-osgi-bundle that was previously used for OSGi testing only.
Running the jbosgi example/functional tests against that subsystem shows a number of failing tests that are documented by the respective exclude lists in jbosgi.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years