[Management, JMX/JBoss] - JBoss 4.0.x RMIAdaptor and jdk1.3 issue
by tmuller
Hi,
I have one serious issue. I need to make a portlet application which will
connect to JBoss 4.0.x MBeans and perform/invoke some MBean's operations etc.
Problem is that the portlet application runs on IBM Websphere (with jdk1.3!) and MBeans runs on JBoss AS 4.0.x (with jdk1.5). I tried following code statement:
| Properties properties = new Properties();
| properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
| properties.setProperty(Context.PROVIDER_URL, someIP:1099");
| properties.setProperty(Context.URL_PKG_PREFIXES, org.jboss.naming");
| Context context = new InitialContext(properties);
|
| MBeanServerConnection server = null;
| Object obj = context.lookup("jmx/invoker/RMIAdaptor");
| server = (MBeanServerConnection)obj;
| ObjectName on = new ObjectName("jboss.system:type=Server");
| Object ver = F_server.getAttribute(on, "Version");
|
This code statement runs well on jdk1.5 or 1.4. But NOT on jdk1.3. Because of jbossall-client.jar (which contains RMIAdaptor) for JBoss AS 4.0.x could be compiled only for jdk1.4/1.5. And when I try to use jbossall-clients.jar from older JBoss versions (e.g. 3.2.8) which is compiled for jdk1.3 I will get following exception:
| javax.naming.CommunicationException. Root exception is java.io.InvalidClassException: org.jboss.util.id.GUID; Local class not compatible: stream classdesc serialVersionUID=3289509836244263718 local class serialVersionUID=6926421946503004889
|
It's because of RMIAdaptor was changed from JBoss 3.x to JBoss 4.x
Please help me, how could I solve this issue?
1) is it possible to compile jbossall-client.jar of JBoss 4.0.x for jdk1.3?
2) or is there other solution how to connect JBoss 4.0.x MBeans from client which runs on jdk1.3?
3) or is there some workaround which could I use?
Thanks for any suggestions!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988693#3988693
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988693
19Â years, 5Â months
[JCA/JBoss] - DB2 XA connection problem - Non XA works
by jshrinivas
Hello,
I am trying to use IBM DB2 XA datasource with JBoss 4.0.5-SP1 and have modified db2-xa-ds.xml. I get following error during JBoss startup:
Reason: org.jboss.deployment.DeploymentException: Error while fixing table name; - nested throwable: (org.jboss.util.NestedSQLException: Could not create connection; - nested throwable: (com.ibm.db2.jcc.b.SqlException: Failure in loading T2 native library db2jcct2); - nested throwable: (org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (com.ibm.db2.jcc.b.SqlException: Failure in loading T2 native library db2jcct2)))
If I use non XA datasource it works fine; so I think it is not a problem with drivers not being in the CLASSPATH. Also JBoss and DB2 machines are on Linux platform.
Is there anything that I need to install (native libs probably) to get XA driver working ?
Thanks,
-Shrinivas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988692#3988692
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988692
19Â years, 5Â months
[Security & JAAS/JBoss] - Concurrency bug in JaasSecurityManager
by Cyberax
I've found a VERY curious concurrency bug in JaasSecurityManager. I'm using custom login modules and custom principal and a custom SecurityInterceptor for JNDI lookups, this interceptor checks .
My DefaultCacheTimeout value was set to 0 (I wanted to turn off authentication cache).
My application (remote Swing client) worked fine as long as there was only one thread doing JNDI lookups. But sometimes a second application threw exception during JNDI authorization, it turned out that authenticated Subject had an empty role set. But this is impossible, because my Subjects always have at least one role.
After few hours of debugging I've found the problem: my custom login module removes its Subject roles during the logout() method. I've found that this module is called by JaasSecurityManager$DomainInfo.destroy. And that's a bug.
Suppose we have two threads:
| Thread 1: Thread 2 (some time after Thread1):
| 1. 'User1' authentication 1. 'User1' logs in.
| 2. 'User1' is added to auth cache 2. Auth cache entry has expired.
| 3. Doing some lengthy operation 3. Calling .logout() on stale entry
| 4. Checking roles of User1 - WILL FAIL, another thread has called logout()!
|
This problem may be not evident with the stock JBoss login modules, because their logout() methods do not remove subject's roles.
Proposed fixes:
1. Use deep cloning. That way threads 1 and 2 doesn't share any data, thus no problem.
2. Use acquire/release semantics in conjunction with SecurityAssociation.
3. Remove logout() from DomainInfo.destroy.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988690#3988690
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988690
19Â years, 5Â months
[Security & JAAS/JBoss] - Re: Negotiate with Kerberos
by hpkolasani
And, I noticed the following in the logs when I enabled TRACE on JBossSecurityMgrRealm.
2006-11-26 13:33:49,515 TRACE [org.jboss.security.plugins.JaasSecurityManager.SPNEGO] Login failure
javax.security.auth.login.LoginException: Error getting roles: jcifs.smb.SmbAuthException: Access is denied.
at org.jboss.security.auth.NegotiateLoginModule.getRoleSets(NegotiateLoginModule.java:148) at org.jboss.security.auth.spi.AbstractServerLoginModule.commit(AbstractServerLoginModule.java:187)
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 javax.security.auth.login.LoginContext.invoke(LoginContext.java:769)
at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186)
at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
at javax.security.auth.login.LoginContext.login(LoginContext.java:580)
at org.jboss.security.plugins.JaasSecurityManager.defaultLogin(JaasSecurityManager.java:483)
at org.jboss.security.plugins.JaasSecurityManager.authenticate(JaasSecurityManager.java:425)
at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:251)
at org.jboss.web.tomcat.security.JBossSecurityMgrRealm.authenticate(JBossSecurityMgrRealm.java:230)
at org.jboss.web.tomcat.security.HttpServletRequestResponseValve.authenticate(HttpServletRequestResponseValve.java:113)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:446)
at org.jboss.web.tomcat.security.HttpServletRequestResponseValve.invoke(HttpServletRequestResponseValve.java:72)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3988686#3988686
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3988686
19Â years, 5Â months