[JBoss JIRA] Created: (JBAS-5238) orm.xml is only read once for multiple ejb.jars
by Mathias Arens (JIRA)
orm.xml is only read once for multiple ejb.jars
-----------------------------------------------
Key: JBAS-5238
URL: http://jira.jboss.com/jira/browse/JBAS-5238
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB3
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.0.GA
Environment: JDK 6
Reporter: Mathias Arens
Assigned To: Carlo de Wolf
I have a sample ear project consisting of two ejb jars each including a persistence.xml and an orm.xml.
test.ear
+--test-report.jar
+--META-INF
+--persistence.xml
+--orm.xml
+--test-settings.jar
+--META-INF
+--persistence.xml
+--orm.xml
Basically both ejb jars do not depend on each other. In both ejb jars is at least one JPA entity defined which has no references to an entity of the other ejb.jar. In each orm.xml entity annotations are overwritten.
If I try to deploy the EAR I receive the following exception. Hibernate complains that an entity of the first ejb.jar(ReportLevel - persistence-unit-a) is not defined in the persistence unit of the second ejb.jar (persistence-unit-b) which is not defined in the persistence unit of the second ejb.jar:
14:03:50,286 WARN [ServiceController] Problem starting service persistence.units:ear=test-ear-0.3-SNAPSHOT.ear,unitName=persistence-unit-b
org.hibernate.AnnotationException: @OneToOne or @ManyToOne on de.test.Report.levelName references an unknown entity: de.test.ReportLevel
at org.hibernate.cfg.FkSecondPass.doSecondPass(FkSecondPass.java:56)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:428)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:286)
at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115)
at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1233)
at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:154)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:869)
at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:407)
at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126)
at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:246)
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.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:103)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy57.start(Unknown Source)
at org.jboss.ejb3.JmxKernelAbstraction.install(JmxKernelAbstraction.java:120)
at org.jboss.ejb3.Ejb3Deployment.startPersistenceUnits(Ejb3Deployment.java:627)
at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:351)
at org.jboss.ejb3.Ejb3Module.startService(Ejb3Module.java:91)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy33.start(Unknown Source)
at org.jboss.ejb3.EJB3Deployer.start(EJB3Deployer.java:512)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:97)
at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(InterceptorServiceMBeanSupport.java:238)
at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:87)
at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188)
at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy34.start(Unknown Source)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1015)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:619)
14:03:50,536 INFO [EJB3Deployer] Deployed: file:/C:/applications/jboss-4.2.2.GA/server/default/tmp/deploy/tmp60216test-ear-0.3-SNAPSHOT.ear-contents/test-settings-0.3-SNAPSHOT.jar
14:03:50,536 INFO [EARDeployer] Started J2EE application: file:/C:/applications/jboss-4.2.2.GA/server/default/deploy/test-ear-0.3-SNAPSHOT.ear
14:03:50,536 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
--- MBeans waiting for other MBeans ---
ObjectName: persistence.units:ear=test-ear-0.3-SNAPSHOT.ear,unitName=persistence-unit-b
State: FAILED
Reason: org.hibernate.AnnotationException: @OneToOne or @ManyToOne on de.test.Report.levelName references an unknown entity: de.test.ReportLevel
I Depend On:
jboss.jca:service=DataSourceBinding,name=DefaultDS
--- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
ObjectName: persistence.units:ear=test-ear-0.3-SNAPSHOT.ear,unitName=persistence-unit-b
State: FAILED
Reason: org.hibernate.AnnotationException: @OneToOne or @ManyToOne on de.test.Report.levelName references an unknown entity: de.test.ReportLevel
I Depend On:
jboss.jca:service=DataSourceBinding,name=DefaultDS
14:03:51,005 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8081
14:03:51,021 INFO [AjpProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
14:03:51,036 INFO [Server] JBoss (MX MicroKernel) [4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)] Started in 14s:343ms
The exception occurs because when JBoss starts the second ejb.jar it uses the orm.xml of the first ejb.jar. The hibernate entity manager combines the entity classes of the persistence unit and the entity mappings from the orm.xml into one pool before starting the validation. But JBoss led Hibernate read the orm.xml only from the first ejb.jar and uses it for the second, too which is completely wrong.
I'll attach my sample ear project. Just deploy it on your JBoss and it should fail with the same error.
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-4531) AsynchEventHandler should ignore queueEvent calls when stopped
by Brian Stansberry (JIRA)
AsynchEventHandler should ignore queueEvent calls when stopped
--------------------------------------------------------------
Key: JBAS-4531
URL: http://jira.jboss.com/jira/browse/JBAS-4531
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Priority: Minor
Fix For: JBossAS-5.0.0.CR1
AsynchEventHandler.queueEvent should not add events to its queue when it is stopped. If an event is added after stop() is called, it can sit there for a long period and then be handled if start() is called again. This could happen during a stop/start cycling of the HAPartition.
This happens now with a MuxChannel that gets a viewAccepted as part of disconnecting -- ClusterPartition ends up putting an event in the stopped queue. That particular issue may go away if JGroups decides to not issue the view, but we should be sure to handle such a case properly.
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-3502) Use ProcessExpiresFrequency to speed tests involving session timeout
by Brian Stansberry (JIRA)
Use ProcessExpiresFrequency to speed tests involving session timeout
--------------------------------------------------------------------
Key: JBAS-3502
URL: http://jira.jboss.com/jira/browse/JBAS-3502
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering, Test Suite, Web (Tomcat) service
Reporter: Brian Stansberry
Priority: Minor
Tomcat Manager impls expose a property ProcessExpiresFrequency, which controls how often the manager responds to the TC background process thread. By default it is set to 6, which means the manager does a session cleanup every 6 cycles. By default the thread runs every 10 secs, so that means session are expired once per minute.
Need to add ProcessExpiresFrequency=1 to a context.xml deployed with session test webapps so we can reduce the time it takes for tests involving session expiration to complete.
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-4052) NPE in RepositoryClassLoader when loading BouncyCastle
by Jon Stevens (JIRA)
NPE in RepositoryClassLoader when loading BouncyCastle
------------------------------------------------------
Key: JBAS-4052
URL: http://jira.jboss.com/jira/browse/JBAS-4052
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading
Affects Versions: JBossAS-4.0.5.GA
Reporter: Jon Stevens
Assigned To: Scott M Stark
Occasionally, I will get the exception below when trying to load the bouncy castle library. One would think it is a problem in BC, except for the fact that the NPE is clearly coming from JBoss's RepositoryClassLoader.
The hard part about this bug is that it happens some of the time and not other times. It's been impossible to reliably reproduce. Restarting the appserver/jvm causes the problem to go away and everything works just fine, but eventually it will happen again.
BC is being started in a @Service Bean. The start() method looks like this:
public void start() throws Exception
{
Security.addProvider(new BouncyCastleProvider());
}
Has anyone else seen this problem?
Caused by: java.security.NoSuchAlgorithmException: No such algorithm: AES/CBC/PKCS5Padding
at javax.crypto.Cipher.getInstance(DashoA13*..)
at javax.crypto.Cipher.getInstance(DashoA13*..)
at com.kink.heart.biz.system.EncryptorBean.encrypt(EncryptorBean.java:349)
... 73 more
Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: AES, provider: BC, class: org.bouncycastle.jce.provider.JCEBlockCipher$AES)
at java.security.Provider$Service.newInstance(Provider.java:1201)
... 76 more
Caused by: java.lang.NullPointerException
at org.jboss.mx.loading.RepositoryClassLoader.findClass(RepositoryClassLoader.java:620)
at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:464)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.security.Provider$Service.getImplClass(Provider.java:1218)
at java.security.Provider$Service.newInstance(Provider.java:1176)
... 76 more
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-4451) SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one.
by Pascal Heraud (JIRA)
SNMP Adaptor of JBOSS does not handle the read community properly, it responds with "public" community instead of custom one.
-----------------------------------------------------------------------------------------------------------------------------
Key: JBAS-4451
URL: http://jira.jboss.com/jira/browse/JBAS-4451
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Management services
Affects Versions: JBossAS-4.0.5.GA
Environment: Tested on REDHAT enterprise, JDK 1.5.0
Reporter: Pascal Heraud
Assigned To: Dimitris Andreadis
I'm using JBOSS SnmpAdaptor to monitor jboss and my web application.
Ive modified the read community of the snmp adaptor into the META-INF/jboss-service.xml configuration file :
<attribute name="ReadCommunity">myCommunity</attribute>
The software we're using for monitoring is using the PERL implementation NET-SNMP and is issuing errors because JBOSS does not reply using the good ReadCommunity (it responds using "public").
We tried with snmpwalk and you can find the logs.
Pascal.
Here is the details of the snmpwalk to the server, the -d options outputs the buffzer
=======================================================
>snmpwalk -d -v1 -c myCommunity localhost:1161 1.2.3.4.1.2
Sending 43 bytes to UDP: [127.0.0.1]:1161
0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni
0016: 74 79 A1 17 02 02 38 B6 02 01 00 02 01 00 30 0B tyí...8Â......0.
0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*......
Received 42 bytes from UDP: [127.0.0.1]:1161
0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó..
0016: 02 38 B6 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8Â......0.0...*
0032: 03 04 01 03 42 04 1F A5 00 00 ....B..Ñ..
Sending 43 bytes to UDP: [127.0.0.1]:1161
0000: 30 29 02 01 00 04 0B 6D 79 43 6F 6D 6D 75 6E 69 0).....myCommuni
0016: 74 79 A0 17 02 02 38 B7 02 01 00 02 01 00 30 0B tyá...8À......0.
0032: 30 09 06 05 2A 03 04 01 02 05 00 0 ..*......
Received 42 bytes from UDP: [127.0.0.1]:1161
0000: 30 28 02 01 00 04 06 70 75 62 6C 69 63 A2 1B 02 0(.....publicó..
0016: 02 38 B7 02 01 00 02 01 00 30 0F 30 0D 06 05 2A .8À......0.0...*
0032: 03 04 01 02 42 04 05 55 4A D8 ....B..UJÏ
iso.2.3.4.1.2 = Gauge32: 89475800
--
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
14 years, 4 months
[JBoss JIRA] Created: (JBAS-4227) [SnmpAgentService] MIB2SystemGroup violates RFC-1213
by Kenny MacLeod (JIRA)
[SnmpAgentService] MIB2SystemGroup violates RFC-1213
----------------------------------------------------
Key: JBAS-4227
URL: http://jira.jboss.com/jira/browse/JBAS-4227
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: JBossAS-4.0.4.GA
Reporter: Kenny MacLeod
Assigned To: Dimitris Andreadis
The SnmpAgentService exposes a standard MIB2 System Group. However, the OIDs that are produced violate RFC-1213, which dictates that the sysUpTime value should have a type of TimeTicks. Instead, SnmpAgentService generates a type of int32.
Take the following output from snmpwalk:
SNMPv2-MIB::sysDescr = STRING: Central Computer
SNMPv2-MIB::sysObjectID = OID: SNMPv2-SMI::enterprises.18016.1.1.2
SNMPv2-MIB::sysUpTime = Wrong Type (should be Timeticks): Gauge32: 769331
SNMPv2-MIB::sysContact = STRING: Agent Smith
SNMPv2-MIB::sysName = STRING: kizoom(a)10.10.0.208
SNMPv2-MIB::sysLocation = STRING: In The Matrix
SNMPv2-MIB::sysServices = INTEGER: 64
End of MIB
For systems which monitor SNMP agents (e.g. OpenNMS), this causes them to reject the agent because of the bad type.
The bug lies in org.jboss.jmx.adaptor.snmp.agent.RequestHandlerImpl, which determines the type of the OID value by examining the type of the JMX attribute being monitored. It has no way to generate a TimeTicks value, it can only handle Long, String, Integer and SnmpOID types.
The JBoss wiki states that RFC-1213 is supported, but this is incorrect when the type for sysUpTime is wrong (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossSNMPAdapterGetValues). Also the attributes.xml file in xnmp-adaptor.sar quotes RFC-1213.
--
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
14 years, 4 months