[JBoss Messaging] - Jboss JMS - security, version and more
by corblet
Downloaded JMS for jboss and was able to successfully run the queue example on jboss 4.0.1 sp1.
Planning on using jms as means of communication between two jboss servers one facing internet and one internal.
Have few questions on securing jms on jboss:
1) The SSL example has the following note:
"A service configuration bug that exists in all JBoss versions prior to 4.0.4.RC1 prevents this example from working correctly"
Does this mean for versions prior to 4.0.4 JBoss Messaging thru Secure Socket Connection is not possible?
2) If i am correct, apart from SSL i believe i can setup a user/role based access to queues/messaging-resources that will limit the connections to only clients with proper credentials?
3) Any other suggestions on securing the system
Also what are the alternatives to this solution.
TIA,
Raj
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989125#3989125
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989125
19Â years, 5Â months
[Installation, Configuration & Deployment] - JNI Problem: UnsatisfiedLinkError when calling native librar
by Jens Rutschmann
Hi,
I need to call a third-party .so from a message driven bean. The .so that belongs to the java "header" file is just some sort of wrapper for the actual library.
The bean, the .so's and the java header declaring the native methods are all in the same JAR / EAR. I do only need to call the .so from classes within this EAR.
I have changed $JBOSS_HOME/bin/run.sh so that LD_LIBRARY_PATH as well as -Djava.library.path point to the directory JBoss extracts the .so's to.
I also commented out the "System.load" call in the java header.
The JBoss server is running on a 64 bit SUSE Linux. The JVM, JBoss and the native libraries are 64 bit versions.
When deploying I can see in the server output (linux console) that the native libraries are beeing loaded:
00:38:50,358 INFO [EARDeployer] Init J2EE application: file:/usr/lib64/jboss-4.0.4.GA/server/default/deploy/Calculator.ear
| 00:38:50,427 INFO [EJBDeployer] Loading native library: /usr/lib64/jboss-4.0.4.GA/server/default/tmp/native/libren6.so
| 00:38:50,439 INFO [EJBDeployer] Loading native library: /usr/lib64/jboss-4.0.4.GA/server/default/tmp/native/librendjv6.so
| 00:38:50,901 INFO [EjbModule] Deploying Calculator
| 00:38:51,034 INFO [EJBDeployer] Deployed: file:/usr/lib64/jboss-4.0.4.GA/server/default/tmp/deploy/tmp62593Calculator.ear-contents/Calculator.jar
| 00:38:51,080 INFO [EARDeployer] Started J2EE application: file:/usr/lib64/jboss-4.0.4.GA/server/default/deploy/Calculator.ear
As you can see, both the JAR and the libraries are loaded by the same deployer (and therefore by the same classloader ?).
Now, if I send a message to the MDB using the native library, I get the following output in the console / logfile ("WpKurs2" is the name of the called method):
00:40:57,424 ERROR [CalculatorBean] java.lang.UnsatisfiedLinkError: WpKurs2
| at de.mmkf.rendjv6.WpKurs2(Native Method)
| at eu.valueprice.calculator.tasks.FixedBondTask.calculate(FixedBondTask.java:64)
| at eu.valueprice.calculator.ejb.CalculatorBean.onMessage(CalculatorBean.java:223)
| 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.invocation.Invocation.performCall(Invocation.java:359)
| at org.jboss.ejb.MessageDrivenContainer$ContainerInterceptor.invoke(MessageDrivenContainer.java:495)
| at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:158)
| at org.jboss.ejb.plugins.MessageDrivenInstanceInterceptor.invoke(MessageDrivenInstanceInterceptor.java:116)
| at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:63)
| at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:121)
| at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:350)
| at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:181)
| at org.jboss.ejb.plugins.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:109)
| at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:205)
| at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:136)
| at org.jboss.ejb.MessageDrivenContainer.internalInvoke(MessageDrivenContainer.java:402)
| at org.jboss.ejb.Container.invoke(Container.java:954)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker.invoke(JMSContainerInvoker.java:987)
| at org.jboss.ejb.plugins.jms.JMSContainerInvoker$MessageListenerImpl.onMessage(JMSContainerInvoker.java:1287)
| at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:266)
| at org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:902)
| at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:170)
| at org.jboss.mq.SpySession.run(SpySession.java:323)
| at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:194)
| at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:743)
| at java.lang.Thread.run(Thread.java:595)
How can I load the libraries so that the calls work ?
Thanks in advance !
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989122#3989122
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989122
19Â years, 5Â months
[JBoss Seam] - Re: ICEfaces
by TedGoddard
The tree classloader issue is not resolved with ICEfaces 1.5.1, but it may be more of a configuration problem than an integration problem between Seam and ICEfaces.
Fundamentally the problem appears to arise because the EJBs and the web application are loaded by different classloaders. If an EJB returns and ICEfaces-specific type, it may have the same class name, but will be a different class than ICEfaces expects (as running in the web application).
So, is it generally a bad idea to return anything but primitive types from EJBs? Is there a simple way to configure the .ear so that the ClassLoaders are common? Should icefaces be split into icefaces-api.jar and icefaces-impl.jar? (In other words, we're looking for suggestions on how to best resolve this.)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3989118#3989118
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3989118
19Â years, 5Â months