[EJB/JBoss] - Re: SSL EJB 3.0 invocation
by paul_da_programmer
Answering my own post...does that count as talking to yourself ?!?
Ok, I've made a bit of progress with this.
This post was of immense help:
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=74475
By incorporating the suggested changes into deploy\ejb.deployer\META-INF\jboss-service.xml, SSL with EJB 3.0 now works.
The only adjustment I needed to make was commenting out this
<!--jboss.remoting:service=NetworkRegistry-->
Additionally, I removed most of what is no longer needed from the chap8 example application. The jar that contains the EJB 3.0 app only contains
META-INF/jboss.xml (more on this in a moment)
and the Interface and implementation listed in the previous post.
I start the jboss ssl server (the server hosting the SSL EJB 3.0 SLSB) with
| set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.keyStore=C:/Paul/Projects/SSL-EJB/server/chap8.keystore -Djavax.net.ssl.keyStorePassword=rmi+ssl
|
I start the jboss ssl client (the server hosting the SSL EJB 3.0 SLSB) with
| set JAVA_OPTS=%JAVA_OPTS% -Djavax.net.ssl.trustStore=C:/Paul/Projects/SSL-EJB/server/client.truststore -Djavax.net.ssl.trustStorePassword=rmi+ssl
|
At this point everything's done as in functional.
However, the issue that remained was externalizing the port configuration from the source code. It would be bad for a prod system to have the following in their EJB's
| @RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="EchoBean4")
|
The way I externalized it is probably a kludge, but it works.
(1) First off, I removed the @RemoteBindings annotation from the SLSB and externalized it into the jboss.xml.
Here's the post that helped: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=111559
and here's my jboss.xml
| <?xml version="1.0"?>
| <jboss
| xmlns="http://java.sun.com/xml/ns/javaee"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
| http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
| version="3.0">
| <enterprise-beans>
| <session>
| <ejb-name>EchoBean4</ejb-name>
| <remote-binding>
| <jndi-name>EchoBean4</jndi-name>
| <client-bind-url>3843</client-bind-url>
| </remote-binding>
| </session>
| </enterprise-beans>
| </jboss>
|
(2) Then, since we're using the ServiceBindings plugin to configure our ports, I needed to modify the bindings specification for the standard EJB connector as a result of changes to deploy\ejb.deployer\META-INF\jboss-service.xml
Here's the change to my bindings file:
| <!-- EJB3 Remoting Connector ejb3.deployer/META-INF/jboss-service.xml -->
|
| <service-config name="jboss.remoting:type=Connector,transport=socket3873,handler=ejb3"
| delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
| <delegate-config>
| <attribute name="InvokerLocator">socket://${jboss.bind.address}:5973</attribute>
| </delegate-config>
| <binding port="5974"/>
| </service-config>
|
This will allow runtime configuration of the standard EJB (non-ssl) port.
However, the SSL port was still specified in jboss.xml as well as the deploy\ejb.deployer\META-INF\jboss-service.xml
Due to my lack of experience with 'customizing' the service binding plugin AND the fact that the port had to be 'hardcoded' in the jboss.xml, I decided on another approach
(3) We already use the SystemPropertiesService to set customization of our applications. Its explanation is out of the scope of this post, but to use it, add the following at the top of conf/jboss-service.xml
| <mbean code="org.jboss.varia.property.SystemPropertiesService"
| name="jboss:type=Service,name=SystemProperties">
| <!--
| | Load properties from each of the given comma seperated URLs
| -->
| <attribute name="URLList">
| ./conf/tap.properties
| </attribute>
| </mbean>
|
I created a conf/tap.properties file with the following:
| ejb.ssl.port=5843
| ejb.ssl.url=sslsocket://0.0.0.0:5843
|
And then I modified jboss.xml to use these system properties
| <?xml version="1.0"?>
| <jboss
| xmlns="http://java.sun.com/xml/ns/javaee"
| xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
| xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
| http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
| version="3.0">
| <enterprise-beans>
| <session>
| <ejb-name>EchoBean4</ejb-name>
| <remote-binding>
| <jndi-name>EchoBean4</jndi-name>
| <client-bind-url>${ejb.ssl.url}</client-bind-url>
| </remote-binding>
| </session>
| </enterprise-beans>
| </jboss>
|
and I modified the deploy\ejb.deployer\META-INF\jboss-service.xml to use the url property:
| <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
| name="jboss.security:service=JaasSecurityDomain,domain=SSLAdvanced">
| <!-- This must correlate with the java:/jaas/SSL above -->
| <constructor>
| <arg type="java.lang.String" value="SSLAdvanced"/>
| </constructor>
| <!-- The location of the keystore
| resource: loads from the classloaders conf/ is the first classloader -->
| <attribute name="KeyStoreURL">C:/Paul/Projects/SSL-EJB/server/chap8.keystore</attribute>
| <attribute name="KeyStorePass">rmi+ssl</attribute>
| </mbean>
|
| <!-- The Connector is the core component of the remoting server service. -->
| <!-- It binds the remoting invoker (transport protocol, callback configuration, -->
| <!-- data marshalling, etc.) with the invocation handlers. -->
| <mbean code="org.jboss.remoting.transport.Connector"
| xmbean-dd="org/jboss/remoting/transport/Connector.xml"
| name="jboss.remoting:type=Connector,transport=socket3843,handler=ejb3">
| display-name="Socket transport Connector">
|
| <attribute name="Configuration">
| <config>
| <invoker transport="sslsocket">
| <attribute name="dataType" isParam="true">invocation</attribute>
| <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
| <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
| <!-- The following is for setting the server socket factory. If want ssl support -->
| <!-- use a server socket factory that supports ssl. The only requirement is that -->
| <!-- the server socket factory value must be an ObjectName, meaning the -->
| <!-- server socket factory implementation must be a MBean and also -->
| <!-- MUST implement the org.jboss.remoting.security.ServerSocketFactoryMBean interface. -->
| <attribute name="serverSocketFactory">jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced</attribute>
| <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
| <attribute name="serverBindPort">${ejb.ssl.port}</attribute>
| </invoker>
| <handlers>
| <handler subsystem="AOP">org.jboss.aspects.remoting.AOPRemotingInvocationHandler</handler>
| </handlers>
| </config>
| </attribute>
| <depends>jboss.remoting:service=ServerSocketFactory,type=SecurityDomainAdvanced</depends>
| <!--<depends>jboss.remoting:service=NetworkRegistry</depends>-->
| <depends>jboss.aop:service=AspectDeployer</depends>
| </mbean>
|
As I said, a little kludgy, but it works. So in summary:
1. I got EJB 3.0 SLSB working using SSL
2. I removed the keystore etc... from the deployed application.
3. I completely externalized configuration of the port used to host the SSL socked from the deployed application itself. This is a major requirement.
If anyone could assist with configuring the deploy\ejb.deployer\META-INF\jboss-service.xml using the service bindings manager AND somehow remove the necessity of specifying the port in the application's jboss.xml - that would be an improvement.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082145#4082145
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082145
18 years, 7 months
[JBossCache] - NullPointerException in PessimisticLockInterceptor
by jacek187
Hi
Does anybody seen this exception?
java.lang.NullPointerException
at org.jboss.cache.interceptors.PessimisticLockInterceptor.hasBeenRemovedInCurrentTx(PessimisticLockInterceptor.java:342)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.needToReverseRemove(PessimisticLockInterceptor.java:336)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:300)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:175)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:365)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:160)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:157)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5863)
at org.jboss.cache.TreeCache.put(TreeCache.java:3833)
at org.jboss.cache.aop.PojoCache.lockPojo(PojoCache.java:635)
at org.jboss.cache.aop.PojoCache.putObject(PojoCache.java:461)
In my opinion TreeCache is yet NOT READY for production use. Probably it works in simple single-thread applications, but in real situations, with many concurent threads TreeCache dosen't work correctly...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082136#4082136
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082136
18 years, 7 months