10 Replies Latest reply on May 4, 2008 5:23 PM by Avihai Marchiano

    Is there an equivalent of @RemoteBindings in jboss.xml

    Sergiu Bivol Newbie

      ...or other deployment descriptors?

      I guess what we really want to do is expose the business interface of the stateless beans over both SSL and non-ssl, and would like to configure the jndi name and url outside the java classes.

      We are using jboss 4.0.4GA and considering upgrading to 4.0.5GA (ejb3 profile of course).

      Would appreciate references to any tests/examples.

      Thanks & Regards
      Sergiu

        • 1. Re: Is there an equivalent of @RemoteBindings in jboss.xml
          Andrew Rubinger Master

          You can use a deployment descriptor (or partial deployment descriptor with some metadata in annotations, some in XML).

          Example/tutorial: http://docs.jboss.org/ejb3/app-server/tutorial/jboss_deployment_descriptor/jboss_dd.html

          S,
          ALR

          • 2. Re: Is there an equivalent of @RemoteBindings in jboss.xml
            Sergiu Bivol Newbie

            Thanks! I'll check it out.

            The reason I'm asking is we may have customers that might want to use a different ssl port. While using deployment descriptor for binding the ssl jndi name to the url is a step forward (it will allow us to just repackage and redeploy the app, instead of recompiling the code), it would be nice if we would not need to even repackage the app for every customer that cannot use the port we come up by default. Is there a way to achieve this?

            For example, the ssl-service.xml could be placed outside the ejb jar (or ear), into a jboss folder, or its content might be moved to jboss-service.xml, either under ejb3.deployer/META-INF or someplace else. That would allow our customer to change the connector port externally to our app. Then, in the ejb-jar/jboss.xml, if we could somehow default the binding url and port to the serverBindAddress and serverBindPort specified in the connector's config...

            Would this be unreasonable or wrong?

            Regards
            Sergiu

            • 3. Re: Is there an equivalent of @RemoteBindings in jboss.xml
              Andrew Rubinger Master

               

              Then, in the ejb-jar/jboss.xml, if we could somehow default the binding url and port to the serverBindAddress and serverBindPort specified in the connector's config...


              The EJBs' references to the InvokerLocator should already be defaulted to what's specified in the connector, right?

              I run a series of JBoss instances simultaneously on one machine, using the Service Bindings Plugin to override default ports for each service. Haven't needed to use any @RemoteBinding annotations or XML overrides at the bean / EJB-JAR level to keep the EJBs aware of the environment they're deployed in.

              RC9 will be needed for this; there were 2 issues I'd come across in previous versions, both discussed in this thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=89537.

              Hope this is clear / addressing your questions.

              S,
              ALR

              • 4. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                Sergiu Bivol Newbie

                I'm not familiar with the Binding Manager, so I'd like to make sure I got it right. So you're saying that, if I:
                a) deploy the ssl-service.xml within the ejb jar just like in the ejb3 ssl tutorial for example
                b) not use any @RemoteBinding annotation or its equivalent jboss.xml constructs
                c) enable the ServiceBindingManager in jboss/conf/jboss-service.xml, point its StoreURL to a sample-ssl-bindings.xml containing the following:

                <service-bindings>
                 <service-config name=""jboss.remoting:type=Connector,transport=socket3843,handler=ejb3"
                 delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
                 <delegate-config>
                 <attribute name="InvokerLocator">socket://${jboss.bind.address}:3843</attribute>
                 </delegate-config>
                 <binding port="3843"/>
                 </service-config>
                <service-bindings>

                one could change the value of above in order to make the remote interface of the ejbs availble on a different port.

                Did I get this right? If so, I have one more question.

                Currently, if a client wishes to use the service over ssl it uses the ssl jndi name (i.e. HelloWorldService/remotessl) specified via @RemoteBinding annotation on the ejb or deployment descriptor; non-ssl clients use HelloWorldService/remote jndi name to look up the service. If I now DO NOT use this annotation, how would a client state that it needs to use a service over ssl or non-ssl?

                Many thanks for prompt and to the point info!

                Regards
                Sergiu

                • 5. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                  Andrew Rubinger Master

                  I think my previous posts weren't as to-the-point as they could have been; sorry for that. And I've never invoked EJB3 over SSL, so everything in this post is just stuff I've come across while doing other related dev.

                  "sbivol" wrote:
                  I'm not familiar with the Binding Manager, so I'd like to make sure I got it right. So you're saying that, if I:
                  a) deploy the ssl-service.xml within the ejb jar just like in the ejb3 ssl tutorial for example


                  Nope...that file should go under your "deploy" directory...

                  "sbivol" wrote:
                  b) not use any @RemoteBinding annotation or its equivalent jboss.xml constructs


                  Well, you'll need @RemoteBinding (or XML equiv) to override the "clientBindUrl" property, specifying a protocol of "sslsocket" in place of the default "socket". Something like:

                  @RemoteBindings({
                   @RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="StatefulSSL"),
                   @RemoteBinding(jndiBinding="StatefulNormal")
                   })


                  ..which is from the Transport documentation http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/transport.html. The above example binds the EJB both on SSL and non-SSL sockets, placing the proxy stubs in JNDI.

                  "sbivol" wrote:
                  If I now DO NOT use this annotation, how would a client state that it needs to use a service over ssl or non-ssl?


                  The client may differentiate which transport to use by looking up the appropriate JNDI address.

                  I couldn't yet find documentation for the corresponding XML for jboss.xml - overriding these properties for @RemoteBinding was new in RC9 (http://jira.jboss.com/jira/browse/EJBTHREE-571) and I'm not sure if the docs are out there yet.

                  S,
                  ALR

                  • 6. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                    Sergiu Bivol Newbie

                    We're using the @RemoteBindings currently, and they work, at least in RC6. In RC9, I found an example showing how to override them in the jboss.xml deployment descriptor. I'm going to try that soon.

                    My question I guess is whether using RemoteBindings to bind the ssl jndi name to the url and port of the SSL connector (defined in the ssl-service.xml) would get in the way of the ServiceBindingManager overriding the port for that same SSL connector. Do you think that would be the case?

                    Regards
                    Sergiu

                    • 7. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                      Andrew Rubinger Master

                       

                      "sbivol" wrote:
                      My question I guess is whether using RemoteBindings to bind the ssl jndi name to the url and port of the SSL connector (defined in the ssl-service.xml) would get in the way of the ServiceBindingManager overriding the port for that same SSL connector. Do you think that would be the case?


                      I don't *think* so. As I understand it, The Binding Manager will handle the actual binding; the @RemoteBinding "clientBindUrl" attribute will tell the client where to invoke.

                      Interested to know how this works out for you.

                      S,
                      ALR

                      • 8. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                        Sergiu Bivol Newbie

                        Ok, I just tried it on 4.0.5.GA. I have the following:

                        - a stateless bean with following remote bindings annotations:
                        @RemoteBindings({
                        @RemoteBinding(clientBindUrl="sslsocket://0.0.0.0:3843", jndiBinding="TestService/remotessl"),
                        @RemoteBinding(jndiBinding="TestService/remote")
                        })

                        - the ssl-service.xml and a keystore packaged within the ejb jar (exactly as shown in the SSL tuturial); the ejb-jar is packaged in an ear

                        - a service client that uses TestService/remotessl jndi name; it works; the clien console tells me it uses port 3843. If using TestService/remote; the client console tells me that that port 3873 (default Remote EJB3 Invoker port)

                        I then enable the Binding Service Manager in jboss-service.xml and point it to sample-bindings.xml file in the jboss/server/default/conf folder where the only thing I override is the port for the ssl invoker defined in the ssl-service.xml as follows:

                        <service-bindings>
                        
                         <server name="ports-default">
                        
                         <service-config name="jboss.remoting:type=Connector,transport=socket3843,handler=ejb3"
                         delegateClass="org.jboss.services.binding.AttributeMappingDelegate">
                         <delegate-config>
                         <attribute name="InvokerLocator">sslsocket://${jboss.bind.address}:3833</attribute>
                         </delegate-config>
                         <binding port="3833"/>
                         </service-config>
                        
                         </server>
                        
                        </service-bindings>
                        


                        If I run the ssl client now, I get a org.jboss.remoting.CannotConnectException, but the console tells me the client still tries to connect to 3843, as opposed to the override port 3833.

                        I suspect the service is now available over SSL at the new port, but client does not understand that it has to connect to that new port.

                        Would deploying the ssl-service.xml in the default/conf folder work?

                        Regards
                        Sergiu

                        • 9. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                          Andrew Rubinger Master

                           

                          If I run the ssl client now, I get a org.jboss.remoting.CannotConnectException, but the console tells me the client still tries to connect to 3843, as opposed to the override port 3833.


                          I'd expect that, as you've specified the clientBindUrl to be 3843 in the @RemoteBinding annotation. Try changing that value?

                          ...or you could also override that value in jboss.xml as of RC9; I haven't found documentation as to *how* yet, though.

                          S,
                          ALR

                          • 10. Re: Is there an equivalent of @RemoteBindings in jboss.xml
                            Avihai Marchiano Novice

                            Does any one has an answer for this?

                            I want to configure clientBindUrl not on the bean.

                            Thank you