[JBoss JIRA] Created: (JBAS-8159) Secure jmx-remoting.sar
by Xavier MOGHRABI (JIRA)
Secure jmx-remoting.sar
-----------------------
Key: JBAS-8159
URL: https://jira.jboss.org/browse/JBAS-8159
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-5.1.0.GA
Environment: JBossAS 5.1.0 GA
Reporter: Xavier MOGHRABI
Assignee: Dimitris Andreadis
JBossAS 5.1.0 GA provides jmx-remoting.sar compliant to JSR 160. Unfortunately the service is not secured and doesn't provide any way to secure it.
However the JMX API provides several mechanisms allowing authentication and authorization. Authentication can easily done against a login-module.
A forwarder can be implemented to extend the authorization against a role based mechanism.
--
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-7952) {home}/client/jboss-javaee.jar missing parts of the Java EE spec
by Rob Stryker (JIRA)
{home}/client/jboss-javaee.jar missing parts of the Java EE spec
----------------------------------------------------------------
Key: JBAS-7952
URL: https://jira.jboss.org/jira/browse/JBAS-7952
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Other
Affects Versions: JBossAS-6.0.0.M2, JBossAS-5.1.0.GA
Reporter: Rob Stryker
Assignee: Dimitris Andreadis
Duplicated from JBIDE-6198:
The name of the jar in {server_home}/client/jboss-javaee.jar suggests it's the full Java EE API, however upon inspection it appears to be a subset:
javax.annotation
javax.ejb
javax.enterprise.deploy
javax.jms
javax.persistence
javax.resource
javax.security.jacc
javax.servlet
javax.transaction
javax.xml
Among others, javax.faces and javax.mail are missing. Is there any chance this jar can be spec-complete?
--
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-8261) Finalizer and Timer-Log4jService threads deadlock
by Bart Berger (JIRA)
Finalizer and Timer-Log4jService threads deadlock
-------------------------------------------------
Key: JBAS-8261
URL: https://jira.jboss.org/browse/JBAS-8261
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: JBossAS-5.1.0.GA
Environment: OS: Linux (2.6.16.46-0.12-bigsmp)
JVM: Java HotSpot(TM) Server VM (16.3-b01, mixed mode) (JRE 1.6.0_20)
Reporter: Bart Berger
Assignee: David Lloyd
Encountered the following deadlock:
"Finalizer" daemon prio=8 tid=3 BLOCKED
at org.jboss.logmanager.LoggerNode.getParentLogger(LoggerNode.java:142)
Local Variable: org.jboss.logmanager.LoggerNode#362
at org.jboss.logmanager.LoggerInstance.getParent(LoggerInstance.java:167)
at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:96)
Local Variable: java.util.logging.Level#2
Local Variable: org.jboss.logmanager.LogContext#1
at org.jboss.logmanager.LoggerInstance.finalize(LoggerInstance.java:204)
at java.lang.ref.Finalizer.$$YJP$$invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Finalizer.java)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
Local Variable: org.jboss.logmanager.LoggerInstance#161
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
Local Variable: java.lang.ref.Finalizer#65597
"Timer-Log4jService" daemon prio=5 tid=25 WAITING
at sun.misc.Unsafe.$$YJP$$park(Native Method)
at sun.misc.Unsafe.park(Unsafe.java)
Local Variable: sun.misc.Unsafe#1
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#629
Local Variable: java.util.concurrent.locks.AbstractQueuedSynchronizer$Node#630
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
Local Variable: java.util.concurrent.locks.ReentrantLock$NonfairSync#89
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
Local Variable: java.util.concurrent.locks.ReentrantLock#42
at org.jboss.logmanager.LoggerInstance.setLevel(LoggerInstance.java:89)
at org.jboss.logmanager.LoggerInstance.<init>(LoggerInstance.java:53)
Local Variable: org.jboss.logmanager.LoggerInstance#1049
Local Variable: java.lang.String#936666
at org.jboss.logmanager.LoggerNode.getOrCreateLogger(LoggerNode.java:127)
at org.jboss.logmanager.LogContext.getLogger(LogContext.java:71)
at org.jboss.logmanager.LogManager.getLogger(LogManager.java:273)
at java.util.logging.LogManager.demandLogger(LogManager.java:390)
at java.util.logging.Logger.getLogger(Logger.java:274)
Local Variable: org.jboss.logmanager.LogManager#1
at org.jboss.logbridge.LogBridgeHandler.updateLoggers(LogBridgeHandler.java:123)
Local Variable: java.util.Collections$SynchronizedMap#43
Local Variable: java.util.Vector$1#3
Local Variable: org.apache.log4j.spi.RootLogger#1
Local Variable: org.apache.log4j.Hierarchy#1
Local Variable: org.apache.log4j.Logger#375
Local Variable: java.lang.String#582052
Local Variable: org.jboss.logbridge.LevelMapper#1
Local Variable: org.jboss.logbridge.LogBridgeHandler#1
at org.jboss.logbridge.LogNotificationListener.handleNotification(LogNotificationListener.java:67)
at sun.reflect.GeneratedMethodAccessor203.invoke(<unknown string>)
Local Variable: sun.reflect.GeneratedMethodAccessor203#1
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Local Variable: sun.reflect.DelegatingMethodAccessorImpl#458
at java.lang.reflect.Method.invoke(Method.java:597)
Local Variable: org.jboss.logbridge.LogNotificationListener#1
at org.jboss.mx.notification.NotificationListenerProxy.invoke(NotificationListenerProxy.java:153)
Local Variable: java.lang.String#2851584
Local Variable: java.lang.Object[]#760535
Local Variable: org.jboss.mx.notification.NotificationListenerProxy#2
Local Variable: java.lang.reflect.Method#16042
at $Proxy73.handleNotification(<unknown string>)
at org.jboss.mx.util.JBossNotificationBroadcasterSupport.handleNotification(JBossNotificationBroadcasterSupport.java:127)
Local Variable: $Proxy73#1
at org.jboss.mx.util.JBossNotificationBroadcasterSupport.sendNotification(JBossNotificationBroadcasterSupport.java:108)
Local Variable: org.jboss.mx.notification.DefaultListenerRegistration#3
Local Variable: org.jboss.mx.notification.ListenerRegistry$ListenerRegistrationIterator#1
at org.jboss.logging.Log4jService.emitReconfigureNotification(Log4jService.java:560)
Local Variable: org.jboss.logging.Log4jService#1
Local Variable: javax.management.Notification#1
at org.jboss.logging.Log4jService$URLWatchTimerTask.reconfigure(Log4jService.java:716)
at org.jboss.logging.Log4jService$URLWatchTimerTask.run(Log4jService.java:636)
Local Variable: org.jboss.net.protocol.resource.ResourceURLConnection#1
at java.util.TimerThread.mainLoop(Timer.java:512)
Local Variable: java.lang.Object#18446
Local Variable: org.jboss.logging.Log4jService$URLWatchTimerTask#1
Local Variable: java.util.TaskQueue#5
at java.util.TimerThread.run(Timer.java:462)
The timer thread ran logging configuration while the finalizer was processing LoggerInstance objects.
The Finalizer thread calls context.levelTreeLock.lock() in LoggerInstance.setLevel(), then enters a synchronized code block in LoggerNode.getParentLogger(). The configuration thread enters a synchronized code block in LoggerNode.getOrCreateLogger(), then creates a new LoggerInstance which calls context.levelTreeLock.lock() in LoggerInstance.setLevel().
--
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-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