13 Replies Latest reply on Nov 5, 2009 3:38 AM by Alessio Soldano

    jms transport support in jbossws-cxf

    Jim Ma Apprentice

      So far the native uses MDB to enable the jms transport. Do we also need to provide such test case or example in cxf stack ? CXF already implemented a jmsTransport to directly send and receive soap message from JMS :

      <wsdl:service name="JMSGreeterService">
       <wsdl:port binding="tns:JMSGreeterPortBinding" name="GreeterPort">
       <jms:address
       destinationStyle="topic"
       jndiConnectionFactoryName="ConnectionFactory"
       jndiDestinationName="dynamicTopics/test.cxf.jmstransport.topic"
       >
      
       <jms:JMSNamingProperty name="java.naming.factory.initial" value="org.xxx.InitialContextFactory"/>
       <jms:JMSNamingProperty name="java.naming.provider.url" value="tcp://localhost:9999"/>
       </jms:address>
       </wsdl:port>
       </wsdl:service>


      We only provide this kind of jms transport support in CXF stack ?

        • 1. Re: jms transport support in jbossws-cxf
          Alessio Soldano Master

          I'd say start producing a minimal testcase showing how to use with JBossWS-CXF what CXF already provide as is, then we think about possible enhancements / improvements in terms of integration.

          • 2. Re: jms transport support in jbossws-cxf
            Jim Ma Apprentice

            So far the jms transport testcase I committed in does not register the jms endpoint in EndpointRegistry. If we list the services , there is one one endpoint listed in page and the jms transport endpoint is missing . Dug the code and found we use these steps to register endpoint :

            1. create Service and Endpoints in WSDeploymentDeployer.

            2. set the address in EndpointAddressDeploymentAspect and modify the name in EndpointNameDeploymentAspect (for native stack) . If the transport is MDB jms , the jms: will be appended to name .

            3. register these endpoints in EndpointRegistryDeploymentAspect.

            When the jms transport is enabled , we can see the endpoint address is http or https. Can we modify it to real correct jms address value ?

            I thought of some possible solutions and to start this discussion here :

            a. configure the jms address as the servlet parameter and set this jms address in WSDeploymentDeployer.

            b. parse the wsdl and get the address and endpoint name map , then attach it to deployment . Use this map to match the endpoint's address In EndpointAddressDeploymentAspect. It only works for the service contains a wsdl. How to do with java first service ?

            Is there any other solution here ? Which way is the better to go ?
            I am waiting for your thoughts and comments ...




            • 3. Re: jms transport support in jbossws-cxf
              Richard Opalka Master

               

              "jim.ma" wrote:
              So far the jms transport testcase I committed in does not register the jms endpoint in EndpointRegistry.

              This is wrong of course. Every endpoint have to be registered in endpoints registry.
              "jim.ma" wrote:

              When the jms transport is enabled , we can see the endpoint address is http or https. Can we modify it to real correct jms address value ?

              You mean soap:address in published WSDL?


              • 4. Re: jms transport support in jbossws-cxf
                Richard Opalka Master

                 

                "jim.ma" wrote:

                Is there any other solution here ? Which way is the better to go ?
                I am waiting for your thoughts and comments ...

                The correct solution is:
                * ensure EndpointAddressDA builds correct JMS URI
                * ensure JMS endpoint is registered with endpoints registry



                • 5. Re: jms transport support in jbossws-cxf
                  Jim Ma Apprentice

                  CXF jms endpoint can be started without MDB , so the jms address info is only in wsdl or jbossws-cxf.xml. We can write another DeploymentAspect to extract this information . But it seems redundant work to parse the wsdl port address and jbossws-cxf.xml destination configuration. So the another way could be : Place an deployer after TomcatDeployer.
                  In cxf, all the started endpoints will be registered in bus. We can get address info from it . But we only can get it after cxf endpoints started. So this correct jms address deployer should be ordered after TomcatDeployer(the war actually started).

                  What do you think about this ?

                  BTW, I also tried the native jms transport sample . I see there is only jms endpoint registered . The http endpoint is not been list in the services list page . Is it intended ?

                  Thanks



                  • 6. Re: jms transport support in jbossws-cxf
                    Richard Opalka Master

                     

                    "jim.ma" wrote:
                    So this correct jms address deployer should be ordered after TomcatDeployer(the war actually started).

                    What do you think about this ?

                    We shouldn't rely on Tomcat deployer :(
                    The fact you'll place your new deployer after tomcat deployer
                    doesn't mean war is deployed and ready to service after
                    tomcat deployer finishes its job. For example if there's a war with many
                    dependencies on other archives, this war won't be started until dependencies are satisfied.

                    IOW your prediction ordered after TomcatDeployer(the war actually started) is wrong.

                    BTW we had many troubles in the past with such expectations
                    and it took us months to fix that. Now all the JBossWS deployers
                    are executed before tomcat deployer by purpose.

                    "jim.ma" wrote:

                    BTW, I also tried the native jms transport sample . I see there is only jms endpoint registered . The http endpoint is not been list in the services list page . Is it intended ?

                    I don't know the details of that native sample, but if endpoint in JMS sample is accessible via http, it should be registered with endpoints registry and it's a bug if it isn't.

                    • 7. Re: jms transport support in jbossws-cxf
                      Richard Opalka Master

                       

                      "richard.opalka@jboss.com" wrote:

                      is accessible via http

                      I mean you're able to invoke endpoint operations via HTTP(S)

                      • 8. Re: jms transport support in jbossws-cxf
                        Richard Opalka Master

                        IRC design log for tracking:

                        Oct 30 07:04:37 opalka - JimMa: GM
                        Oct 30 07:04:56 opalka - JimMa: Give me few minutes and then we'll discuss JMS issue here on IRC
                        Oct 30 07:06:31 JimMa - opalka, Good morning . Okay . Ping me when you are ready .
                        Oct 30 07:07:32 opalka - JimMa: sure
                        Oct 30 08:02:30 opalka - JimMa: OK, I have time now
                        Oct 30 08:02:38 opalka - JimMa: How about you?
                        Oct 30 08:02:45 JimMa - opalka, Okay .
                        Oct 30 08:02:51 JimMa - opalka, we can start now .
                        Oct 30 08:03:00 opalka - JimMa: Do you want me to have a look to some sources?
                        Oct 30 08:03:13 opalka - JimMa: The truth is I didn't review your commits
                        Oct 30 08:03:23 opalka - JimMa: Shoud I
                        Oct 30 08:03:42 JimMa - opalka, you just need to look a jms sample I checked in .
                        Oct 30 08:04:19 opalka - JimMa: ok, doing it now ...
                        Oct 30 08:04:34 opalka - JimMa: updating svn ...
                        Oct 30 08:04:57 opalka - JimMa: Reviewing test ...
                        Oct 30 08:07:15 JimMa - opalka, There is a little stupid in my web.xml . You can see there is two servlets defined. That caused cxf read the same spring configuration jbossws-cxf.xml twice .
                        Oct 30 08:08:35 JimMa - opalka, I think we may need to define a parameter to feed the jbossws-cxf.xml for each servlet/endpoint .
                        Oct 30 08:09:42 opalka - JimMa: OK, I reviewed the test
                        Oct 30 08:09:48 JimMa - opalka, great.
                        Oct 30 08:10:26 opalka - JimMa: I see just one servlet defined in web.xml?
                        Oct 30 08:10:59 JimMa - opalka, ah . I saw my local code that has not checked in.
                        Oct 30 08:11:09 opalka - JimMa: aha, ok
                        Oct 30 08:11:27 JimMa - opalka, I want to jms endpoints registered in registry . So I add it locally .
                        Oct 30 08:11:38 opalka - JimMa: BTW, is it necessary to define OrganizationJmsEndpoint?
                        Oct 30 08:11:56 opalka - JimMa: I just see it extends OrganizationHttpEndpoint but doesn't override the implemented method.
                        Oct 30 08:11:59 JimMa - opalka, code or jbossws-cxf.xml ?
                        Oct 30 08:12:13 opalka - JimMa: Both
                        Oct 30 08:12:25 opalka - JimMa: IMHO you don't need OrganizationJmsEndpoint class to be defined
                        Oct 30 08:12:33 JimMa - opalka, Ah. It has different annotation . ServiceName and portName in @Webserivce.
                        Oct 30 08:12:34 opalka - JimMa: and you can specify the same class in both places in jbossws-cxf.xml
                        Oct 30 08:12:43 opalka - JimMa: having a look ...
                        Oct 30 08:13:00 opalka - JimMa: Right, then you're correct ;)
                        Oct 30 08:13:12 JimMa - opalka, CXF will use that to match the jms port address.
                        Oct 30 08:13:42 opalka - JimMa: Now your problem is you're Jms or Http endpoint isn't registered with registry
                        Oct 30 08:13:45 opalka - JimMa: Right?
                        Oct 30 08:13:48 * magesh_afk is now known as magesh_lunch
                        Oct 30 08:13:52 JimMa - opalka, right.
                        Oct 30 08:14:05 JimMa - opalka, If I define the servlet for Jms Endpoint , it can be registered .
                        Oct 30 08:14:13 JimMa - opalka, But the address is not correct .
                        Oct 30 08:15:05 JimMa - opalka, Another the side effect for this example is the same jbossws-cxf.xml will be loaded twice in cxf if I defined the servlet for this jms endpoint .
                        Oct 30 08:16:05 JimMa - opalka, We may find a better palace to register this jms endpoint and correct its address.
                        Oct 30 08:16:33 opalka - JimMa: Thinking ...
                        Oct 30 08:19:49 opalka - JimMa: Drawing usecase on the whiteboard ...
                        Oct 30 08:20:49 opalka - JimMa: Stopped drawing
                        Oct 30 08:20:57 opalka - JimMa: Where is the JMS transport integration code for CXF?
                        Oct 30 08:21:08 JimMa - opalka, one sec ...
                        Oct 30 08:21:40 JimMa - opalka, jaxws:endpoint id='JMSQueryService'
                        Oct 30 08:21:40 JimMa - implementor='org.jboss.test.ws.jaxws.samples.jmstransport.OrganizationJmsEndpoint'
                        Oct 30 08:21:40 JimMa - transportId="http://cxf.apache.org/transports/jms" -
                        Oct 30 08:21:40 JimMa - /jaxws:endpoint -
                        Oct 30 08:21:48 JimMa - opalka, these lines in jbossws-cxf.xml
                        Oct 30 08:22:10 JimMa - opalka, There is transportId defined .
                        Oct 30 08:22:53 opalka - JimMa: Opening Eclipse IDE ...
                        Oct 30 08:22:57 JimMa - opalka, CXF will know it's jms transport from it and find the jms destination info from wsdl .
                        Oct 30 08:25:56 opalka - JimMa: IOW, JMS transport integration code is in CXF code base and you didn't need to hack anything in our CXF integration code, right?
                        Oct 30 08:26:14 JimMa - opalka, right .
                        Oct 30 08:27:04 opalka - JimMa: How is it with Native stack, you can see only http endpoint in endpoint registry, right?
                        Oct 30 08:27:04 JimMa - opalka, We can only let it done through cxf configuration xml .
                        Oct 30 08:27:35 JimMa - opalka, There is only jms endpoint in Endpoint registry .
                        Oct 30 08:27:50 opalka - JimMa: There's no http defined in native sample?
                        Oct 30 08:27:59 opalka - JimMa: I mean http endpoint?
                        Oct 30 08:28:19 JimMa - opalka, But it really started a http endpoint .
                        Oct 30 08:28:40 JimMa - opalka, look at the testcase, there is code to test that http endpoint .
                        Oct 30 08:31:37 opalka - JimMa: looking ...
                        Oct 30 08:36:41 opalka - JimMa: The reason why we have only JMS endpoint registered with endpoint registry is here in this code:
                        Oct 30 08:36:42 opalka - ---
                        Oct 30 08:36:43 opalka - private EJBMetaData newEjbMetaData(final WebServiceDeclaration jbossEjbMD)
                        Oct 30 08:36:43 opalka - {
                        Oct 30 08:36:43 opalka - final MessageDriven mdbAnnotation = jbossEjbMD.getAnnotation(MessageDriven.class);
                        Oct 30 08:36:43 opalka - if (mdbAnnotation == null)
                        Oct 30 08:36:43 opalka - {
                        Oct 30 08:36:43 opalka - this.log.debug("Creating JBoss agnostic EJB3 meta data for session bean: "
                        Oct 30 08:36:43 opalka - + jbossEjbMD.getComponentClassName());
                        Oct 30 08:36:43 opalka - return new SLSBMetaData();
                        Oct 30 08:36:43 opalka - }
                        Oct 30 08:36:43 opalka - else
                        Oct 30 08:36:43 opalka - {
                        Oct 30 08:36:43 opalka - this.log.debug("Creating JBoss agnostic EJB3 meta data for message driven bean: "
                        Oct 30 08:36:43 opalka - + jbossEjbMD.getComponentClassName());
                        Oct 30 08:36:43 opalka - final MDBMetaData mdbMD = new MDBMetaData();
                        Oct 30 08:36:43 opalka - final String destinationName = this.getActivationProperty("destination", mdbAnnotation.activationConfig());
                        Oct 30 08:36:43 opalka - mdbMD.setDestinationJndiName(destinationName);
                        Oct 30 08:36:43 opalka - return mdbMD;
                        Oct 30 08:36:43 opalka - }
                        Oct 30 08:36:43 opalka - }
                        Oct 30 08:36:44 opalka - ---
                        Oct 30 08:36:57 opalka - This is the code from MetaDataBuilderEJB3
                        Oct 30 08:37:30 opalka - JimMa: As you can see if there's MessageDriven annotation, we consider it MDB only, otherwise it's standard EJB (servlet later)
                        Oct 30 08:37:43 JimMa - opalka, OK.
                        Oct 30 08:37:59 opalka - JimMa: This code is wrong, because if endpoint is accessible both ways
                        Oct 30 08:38:15 opalka - JimMa: http and/or jms, then both endpoints have to be registered with endpoints registry
                        Oct 30 08:38:55 JimMa - opalka, yes. The MDB actually route the jms message to http endpoint.
                        Oct 30 08:39:21 opalka - JimMa: Sorry, don't understand what you mean here ^ ?
                        Oct 30 08:40:21 JimMa - opalka, I mean these code in AbstractJMSTransportSupport :
                        Oct 30 08:40:23 JimMa - opalka, protected void processSOAPMessage(String fromName, InputStream inputStream, OutputStream outStream) throws SOAPException, IOException, RemoteException
                        Oct 30 08:40:24 JimMa - {
                        Oct 30 08:40:24 JimMa - SPIProvider spiProvider = SPIProviderResolver.getInstance().getProvider();
                        Oct 30 08:40:24 JimMa - EndpointRegistry epRegistry = spiProvider.getSPI(EndpointRegistryFactory.class).getEndpointRegistry();
                        Oct 30 08:40:25 JimMa - Endpoint endpoint = getEndpointForDestination(epRegistry, fromName);
                        Oct 30 08:40:27 JimMa - if (endpoint == null)
                        Oct 30 08:40:29 JimMa - throw new IllegalStateException("Cannot find endpoint for: " + fromName);
                        Oct 30 08:40:31 JimMa - EndpointAssociation.setEndpoint(endpoint);
                        Oct 30 08:40:59 JimMa - opalka, If I understand it correctly .
                        Oct 30 08:41:24 opalka - JimMa: You little bit confused me ;)
                        Oct 30 08:41:31 JimMa - opalka, :-)
                        Oct 30 08:41:32 opalka - JimMa: I'll explain above code to you ;)
                        Oct 30 08:41:42 opalka - JimMa: We have transport layer and invocation layer
                        Oct 30 08:41:55 JimMa - opalka, yes.
                        Oct 30 08:42:03 opalka - JimMa: The code you can see above is invocation layer specific and have nothing to do with http transport
                        Oct 30 08:42:29 JimMa - opalka, Ah. So the RequestHandler does not have any transport in it .
                        Oct 30 08:42:35 JimMa - opalka, Am I right ?
                        Oct 30 08:42:37 opalka - JimMa: If you call Endpoint.getRequestHandler().handleXYZ() it's invocation specific code only ;)
                        Oct 30 08:42:45 opalka - JimMa: exactly
                        Oct 30 08:42:48 JimMa - opalka, got it .
                        Oct 30 08:42:52 * dbevenius2 (~danbev@vpn1-5-235.ams2.redhat.com) has left #jbossws
                        Oct 30 08:43:08 opalka - JimMa: Great. I was just explaining you why you confused me ;)
                        Oct 30 08:43:48 opalka - JimMa: IOW in our terminology AbstractJMSTransportSupport calls JBossWS invocation layer to handle the request
                        Oct 30 08:44:07 opalka - JimMa: OK, back to our problem
                        Oct 30 08:44:18 JimMa - opalka, I understood that wrong . I mistaken the endpoint is the started well with a http transport.
                        Oct 30 08:44:33 JimMa - opalka, I have another question about it .
                        Oct 30 08:45:37 JimMa - opalka, here can we use a pojo class (endpoint) to demonstrate the jms transport ?
                        Oct 30 08:46:23 opalka - JimMa: I don't understand your question :(
                        Oct 30 08:46:28 JimMa - opalka, I mean in native stack .
                        Oct 30 08:46:29 opalka - JimMa: Can you say it in different way?
                        Oct 30 08:46:36 JimMa - opalka, right .
                        Oct 30 08:47:31 JimMa - opalka, Then endpoint is a server side pojo class and not the started http transport endpoint .
                        Oct 30 08:48:12 * lpetrovi (~triceo@sledge.englab.brq.redhat.com) has joined #jbossws
                        Oct 30 08:48:22 * lpetrovi has quit (Remote host closed the connection)
                        Oct 30 08:48:34 * lpetrovi (~triceo@sledge.englab.brq.redhat.com) has joined #jbossws
                        Oct 30 08:48:39 opalka - JimMa: exactly
                        Oct 30 08:49:02 opalka - JimMa: All our endpoints (POJOs or EJBs) are started when JBossWS deployers finish their job
                        Oct 30 08:49:10 opalka - JimMa: And any transport layer can access them
                        Oct 30 08:50:04 JimMa - opalka, Ah . Great . Let's back to our problem .
                        Oct 30 08:50:30 opalka - JimMa: DefaultEndpoint (native stack, metro stack), CXFServletExt (cxf stack), AbstractJMSTransportSupport (native stack)
                        Oct 30 08:52:05 opalka - JimMa: Little correction (I did a mistake above and don't wanna make you confused)
                        Oct 30 08:52:06 opalka - ---
                        Oct 30 08:52:18 opalka - JimMa: We have three servlet transports in every stack
                        Oct 30 08:52:32 JimMa - opalka, OK.
                        Oct 30 08:52:33 * dbevenius2 (~danbev@vpn1-5-235.ams2.redhat.com) has joined #jbossws
                        Oct 30 08:52:35 opalka - * EndpointServlet (native servlet transport)
                        Oct 30 08:52:42 opalka - * EndpointServlet (metro servlet transport)
                        Oct 30 08:52:55 opalka - * CXFServletExt (cxf servlet transport)
                        Oct 30 08:53:05 opalka - JimMa: We have one JMS transport in native only
                        Oct 30 08:53:24 JimMa - opalka, understood.
                        Oct 30 08:53:26 opalka - * AbstractJMSTransportSupport (every EJB3 MDB have to extend this class to add support for JMS in native)
                        Oct 30 08:53:37 opalka - JimMa: All four transports use registry lookup to find the endpoint
                        Oct 30 08:53:53 opalka - JimMa: Then they call invocation layer via endpoint.getRequesthandler().handle...
                        Oct 30 08:54:04 opalka - JimMa: That's all about recapitulation
                        Oct 30 08:54:05 opalka - ---
                        Oct 30 08:54:08 JimMa - opalka, get it .
                        Oct 30 08:54:33 opalka - JimMa: As I said all endpoints (EJB or POJO) are ready for service once deployers finish their job
                        Oct 30 08:54:52 opalka - JimMa: Why I'm saying the Native JMS sample has a bug is the reason
                        Oct 30 08:55:04 opalka - JimMa: JMS sample endpoint is accessible both ways, via JMS and servlet transport
                        Oct 30 08:55:16 JimMa - opalka, right.
                        Oct 30 08:55:52 opalka - JimMa: IOW, we need to create bug "Servlet transport is not registered with endpoints registry when bean is MDB in native stack"
                        Oct 30 08:56:02 opalka - JimMa: This is all about native
                        Oct 30 08:56:05 opalka - JimMa: Back to CXF
                        Oct 30 08:56:41 opalka - JimMa: Problem with CXF you have is CXF completely handles JMS invocations
                        Oct 30 08:56:59 JimMa - opalka, right . It does not need MDB .
                        Oct 30 08:57:03 opalka - JimMa: It probably have it's own endpoints registry, but JMS endpoint isn't populated to JBossWS endpoint registry, right?
                        Oct 30 08:57:33 JimMa - opalka, right .
                        Oct 30 08:58:10 JimMa - opalka, As I said in my post , we can query cxf bus to get the started endpoints both jms , servlet transport .
                        Oct 30 08:58:38 opalka - JimMa: IMHO this is not necessary
                        Oct 30 08:58:53 opalka - JimMa: Your only problem is JMS endpoint isn't populated to our registry (to inform user), right?
                        Oct 30 08:59:02 JimMa - opalka, yes.
                        Oct 30 08:59:28 opalka - JimMa: From my understanding
                        Oct 30 08:59:55 opalka - JimMa: to enable JMS transport user need to provide jbossws-cxf.xml with specific transport ID + provide the WSDL with appropriate biding
                        Oct 30 08:59:56 JimMa - opalka, And another thing is getting the jms address for the jms endpoint .
                        Oct 30 09:00:37 opalka - JimMa: Is CXF able to generate WSDL on demand (I mean do we need to provide that wsdl)?
                        Oct 30 09:00:45 JimMa - opalka, There is another user case in CXF is not binding the wsdl . Provides all the jms information in jbossws-cxf.xml .
                        Oct 30 09:01:12 opalka - JimMa: You just answered my question ;)
                        Oct 30 09:01:18 JimMa - opalka, :-)
                        Oct 30 09:01:34 * magesh_lunch is now known as magesh
                        Oct 30 09:01:35 opalka - JimMa: IOW user don't need to provide WSDL to have JMS transport enabled (CXF will generate it), right?
                        Oct 30 09:01:44 JimMa - opalka, right .
                        Oct 30 09:02:03 opalka - JimMa: Hmm, that's bad. Thinking ...
                        Oct 30 09:02:45 opalka - JimMa: Going to draw on whiteboard, give me a sec ...
                        Oct 30 09:02:54 JimMa - opalka, sure .
                        Oct 30 09:04:55 opalka - JimMa: I'm back from white board
                        Oct 30 09:05:11 opalka - JimMa: First I'll explain the problem
                        Oct 30 09:05:28 opalka - JimMa: Then I'll give you an suggestion how to fix it, right?
                        Oct 30 09:05:37 JimMa - opalka, yeah .
                        Oct 30 09:05:45 opalka - ---
                        Oct 30 09:06:02 opalka - JimMa: OK, the problem is WSDL don't need to be provided by user
                        Oct 30 09:06:12 opalka - JimMa: IOW CXF can generate it at run time
                        Oct 30 09:07:03 opalka - JimMa: Rule1) We can't rely on the fact we have access to WSDL when JBossWS deployers are executed
                        Oct 30 09:07:24 opalka - JimMa: even if you would put your hacky deployer to be executed after tomcat deployer
                        Oct 30 09:07:50 opalka - JimMa: it might happen you'll don't have access to WSDL
                        Oct 30 09:07:53 opalka - JimMa: because
                        Oct 30 09:08:25 opalka - JimMa: you can't rely on fact JAXWS CXF archive has load-on-startup different than 0
                        Oct 30 09:08:46 opalka - JimMa: Do you agree with me? Do you understand everything I till now wrote? If not feel free to ask and I'll clarify ;)
                        Oct 30 09:08:49 opalka - ---
                        Oct 30 09:09:23 JimMa - opalka, Agreed. I also thought if we should make the load-on-startup=1 to default .
                        Oct 30 09:09:43 opalka - JimMa: No, I wouldn't do load-on-startup=1 by default
                        Oct 30 09:10:05 JimMa - opalka,please explain that for me.
                        Oct 30 09:10:11 opalka - JimMa: Because it might affect our users server performance (if they have e.g. 1000 web apps but many of them are not used)
                        Oct 30 09:10:50 JimMa - opalka, you persuaded me .
                        Oct 30 09:11:39 opalka - JimMa: Good. I'm against load-on-startup=1 because of performance ;)
                        Oct 30 09:12:16 opalka - JimMa: Is there something else you want to ask before I'll proceed?
                        Oct 30 09:12:30 JimMa - opalka, I am now totally agreed with what you said rest of that . pleas continue ...
                        Oct 30 09:12:36 opalka - JimMa: ok
                        Oct 30 09:13:13 opalka - JimMa: The only reliable place IMHO when we have access to WSDL is
                        Oct 30 09:13:23 opalka - JimMa: CXFServletExt.init() method
                        Oct 30 09:13:39 JimMa - opalka, yeap .
                        Oct 30 09:13:58 opalka - JimMa: wait a sec., thinking ...
                        Oct 30 09:14:40 opalka - JimMa: Give me one minute, I need to see how JBossWS cxf console looks like (IOW I'm staring JBossAS server ATM) ...
                        Oct 30 09:14:57 JimMa - opalka, OK.
                        Oct 30 09:18:19 opalka - JimMa: There's one thing that's not clear to me :(
                        Oct 30 09:18:37 JimMa - opalka, what's that ?
                        Oct 30 09:18:47 opalka - JimMa: How do CXF users provide necessary info to CXF if they don't provide WSDL?
                        Oct 30 09:18:50 opalka - JimMa: I mean this:
                        Oct 30 09:18:51 opalka - ---
                        Oct 30 09:19:09 opalka - wsdl:port binding="tns:JMSSoapBinding" name="JmsEndpointPort" -
                        Oct 30 09:19:09 opalka - jms:address
                        Oct 30 09:19:09 opalka - destinationStyle="queue"
                        Oct 30 09:19:09 opalka - jndiConnectionFactoryName="ConnectionFactory"
                        Oct 30 09:19:09 opalka - jndiDestinationName="queue/RequestQueue"
                        Oct 30 09:19:09 opalka - jndiReplyDestinationName="queue/ResponseQueue" -
                        Oct 30 09:19:09 opalka - -
                        Oct 30 09:19:09 opalka - /jms:address -
                        Oct 30 09:19:09 opalka - /wsdl:port -
                        Oct 30 09:19:11 opalka - ---
                        Oct 30 09:19:12 opalka - ?
                        Oct 30 09:19:23 opalka - Via annotations?
                        Oct 30 09:19:45 JimMa - opalka, CXF treated all the information from wsdl , annotation or jbossws-cxf.xml as Configuration.
                        Oct 30 09:20:12 opalka - JimMa: IOW it's possible to provide info such as jndiConnectionFactory, jndiDestinationName, ... in jbossws-cxf.xml?
                        Oct 30 09:21:00 JimMa - opalka, It can . It can be configured to DestionationFactory and CondiutFactory .
                        Oct 30 09:21:12 opalka - JimMa: GREAT!
                        Oct 30 09:21:34 opalka - JimMa: The question what usecases we're going to support
                        Oct 30 09:22:02 opalka - JimMa: I'd support jbossws-cxf.xml provides all the JMS info that is necessary
                        Oct 30 09:22:30 opalka - JimMa: Only this usecase, do you agree with me?
                        Oct 30 09:23:11 opalka - JimMa: You don't need to, I'm just asking your opinion ;)
                        Oct 30 09:23:37 JimMa - opalka, The jbossws-cxf.xml use case is mainly for java first scenario .
                        Oct 30 09:23:48 opalka - JimMa: yep
                        Oct 30 09:24:07 opalka - JimMa: So you'd like to support contract first too?
                        Oct 30 09:24:10 JimMa - opalka, In current stack , which one we mainly support ? wsdl first or java first ?
                        Oct 30 09:24:27 opalka - JimMa: Java first (mainly) :(
                        Oct 30 09:24:55 JimMa - opalka, Then we can support jbossws-cxf.xml first. What do you think ?
                        Oct 30 09:25:00 JimMa - opalka, Then we fix the wsdl one .
                        Oct 30 09:25:01 opalka - JimMa: I'm sking about supported scenarios because the count of supported scenarios will tell me how many hacks you'll need to do
                        Oct 30 09:25:20 opalka - JimMa: Thinking ...
                        Oct 30 09:25:56 opalka - JimMa: I'd support both ;)
                        Oct 30 09:26:22 opalka - JimMa: These are two usecases we need a test case for:
                        Oct 30 09:26:25 JimMa - opalka, :-)
                        Oct 30 09:26:30 opalka - JimMa: WSDL first (we already have it)
                        Oct 30 09:26:54 opalka - JimMa: Java first (with jbossws-cxf.xml containing all the necessary info to build the JMS URI) (you need to provide it)
                        Oct 30 09:27:06 JimMa - opalka, yes.
                        Oct 30 09:27:18 JimMa - opalka, I will write one for java first .
                        Oct 30 09:27:31 opalka - JimMa: Greta, that will be task1 for you ;)
                        Oct 30 09:27:38 JimMa - opalka, OK.
                        Oct 30 09:27:39 opalka - JimMa: Greta = Greta
                        Oct 30 09:27:42 opalka - JimMa: Greta = Great
                        Oct 30 09:27:58 opalka - JimMa: Double typo :(
                        Oct 30 09:28:12 JimMa - opalka, hehe .
                        Oct 30 09:28:45 opalka - JimMa: OK, before I'll write my suggestion, I need to ensure last thing
                        Oct 30 09:29:11 JimMa - opalka, listening ...
                        Oct 30 09:29:22 opalka - JimMa: User always need to provide
                        Oct 30 09:29:23 opalka - ---
                        Oct 30 09:29:23 opalka - jaxws:endpoint id='JMSQueryService'
                        Oct 30 09:29:23 opalka - implementor='org.jboss.test.ws.jaxws.samples.jmstransport.OrganizationJmsEndpoint'
                        Oct 30 09:29:23 opalka - transportId="http://cxf.apache.org/transports/jms" -
                        Oct 30 09:29:23 opalka - /jaxws:endpoint -
                        Oct 30 09:29:25 opalka - ---
                        Oct 30 09:29:32 opalka - in both scenarios, java first, wsdl first, right?
                        Oct 30 09:30:02 opalka - I'm asking especially on transportId?
                        Oct 30 09:30:09 JimMa - opalka, Let me think ... one sec ...
                        Oct 30 09:30:15 opalka - JimMa: sure
                        Oct 30 09:32:08 JimMa - opalka, If it is started and running in container , it is yes. But the transportid can be get from jmsTransportFactory .
                        Oct 30 09:32:52 JimMa - opalka, There is another format of it is configuring the serverFactory , serviceFactory and transportFactory to compose a JMSEndpoint .
                        Oct 30 09:33:30 JimMa - opalka, So the jaxws:endpoint - or the attributeId is not the only format to start a jms endpoint .
                        Oct 30 09:33:50 opalka - JimMa: Then question is how many formats do you want to support?
                        Oct 30 09:33:52 JimMa - opalka, But we can say in document , we only support this format .
                        Oct 30 09:34:02 opalka - JimMa: IMHO the one is satisfactory, do you agree with me?
                        Oct 30 09:34:08 JimMa - opalka, yeah .
                        Oct 30 09:34:13 opalka - JimMa: OK, great
                        Oct 30 09:34:27 opalka - JimMa: Then I'm living to you which format you'll decide for ;)
                        Oct 30 09:34:55 opalka - JimMa: Here're my suggestions/tasks for you ;)
                        Oct 30 09:34:56 opalka - ---
                        Oct 30 09:35:27 JimMa - opalka, listening...
                        Oct 30 09:35:57 opalka - * tests
                        Oct 30 09:36:07 opalka - - provide jmstransport/javafirst/ usecase (use this package)
                        Oct 30 09:36:26 JimMa - opalka, OK.
                        Oct 30 09:36:30 opalka - - provide jmstransport/wsdlfirst/ usecase (refactor existing test to this package)
                        Oct 30 09:36:44 opalka - This is all about tests
                        Oct 30 09:36:58 opalka - To fix the Registry issue I suggest you the following solution:
                        Oct 30 09:37:44 opalka - * create new CXF DA (deployment aspect) that will parse provided jbossws-cxf.xml (it have to be available for both use cases)
                        Oct 30 09:38:05 opalka - as we agreed in previous conversation ;)
                        Oct 30 09:38:41 opalka - * I'd call this DA CXFTransportRegistryPopulationDA or something like that (so the name of this DA is self explanatory)
                        Oct 30 09:39:04 opalka - Sorry, I meant JMSTransport2RegistryDA ;)
                        Oct 30 09:39:30 opalka - This DA will parse the provided jbossws-cxf.xml file and will find for JMS info to build the URI
                        Oct 30 09:39:32 JimMa - opalka, where can we place that ?
                        Oct 30 09:39:40 opalka - That DA?
                        Oct 30 09:39:50 JimMa - opalka, JMSTransport2RegistryDA.
                        Oct 30 09:40:06 opalka - wait a sec. looking to configuration file ...
                        Oct 30 09:41:33 JimMa - opalka, before EndpointAddressDeploymentAspect ?
                        Oct 30 09:41:59 opalka - JimMa: analyzing EndpointAddressDA code ...
                        Oct 30 09:43:45 opalka - JimMa: I'd put it after this DA
                        Oct 30 09:44:00 opalka - JimMa: And would modify only JMS endpoint address ;)
                        Oct 30 09:44:15 JimMa - opalka, OK.
                        Oct 30 09:44:27 JimMa - opalka, :-)
                        Oct 30 09:44:28 opalka - JimMa: I changed my mind, I'd call this new DA JMSEndpointAddressDA ;)
                        Oct 30 09:44:42 JimMa - opalka, OK.
                        Oct 30 09:45:01 JimMa - opalka, How do we handle the jms address in WSDL ?
                        Oct 30 09:45:27 JimMa - opalka, one more question : do we need to change the objectName for the jms endpoint ?
                        Oct 30 09:45:43 JimMa - opalka, I see the native stack does. We need to consolidate ?
                        Oct 30 09:45:46 opalka - JimMa: You little bit confused me again ;)
                        Oct 30 09:46:07 opalka - JimMa: Native stack JMS transport issue is another topic
                        Oct 30 09:46:15 opalka - JimMa: What is your question about?
                        Oct 30 09:46:28 JimMa - opalka, Let me find the code . a sec .
                        Oct 30 09:46:39 opalka - JimMa: waiting ...
                        Oct 30 09:47:46 JimMa - opalka, look at EndpointNameDeploymentAspect
                        Oct 30 09:48:17 JimMa - opalka, it will change the ObjectName of jms endpoint.
                        Oct 30 09:48:33 JimMa - opalka, EJBMetaData bmd = uapp.getBeanByEjbName(ep.getShortName());
                        Oct 30 09:48:34 JimMa - if (bmd instanceof MDBMetaData)
                        Oct 30 09:48:34 JimMa - {
                        Oct 30 09:48:34 JimMa - String destName = ((MDBMetaData)bmd).getDestinationJndiName();
                        Oct 30 09:48:34 JimMa - name.append(",jms=" + destName);
                        Oct 30 09:48:34 JimMa - }
                        Oct 30 09:49:29 * asoldano (~alessio@vpn-226-145.phx2.redhat.com) has joined #jbossws
                        Oct 30 09:49:34 asoldano - good morning
                        Oct 30 09:49:41 opalka - asoldano: GM
                        Oct 30 09:49:51 opalka - JimMa: yes, this needs to be somehow unified
                        Oct 30 09:50:24 opalka - JimMa: I suggest you to do it in JMSEndpointAddressDA first (then we'll look for optimizations)
                        Oct 30 09:50:42 JimMa - opalka, Okay
                        Oct 30 09:50:54 opalka - JimMa: Another questions before I'll proceed?
                        Oct 30 09:50:59 JimMa - opalka, I will fill a jira for that
                        Oct 30 09:51:06 opalka - JimMa: Sure!
                        Oct 30 09:51:26 opalka - JimMa: Can I continue?
                        Oct 30 09:51:26 JimMa - opalka, We just talked about we need to support both : wsdl first and java first .
                        Oct 30 09:51:34 JimMa - opalka, a minutes.
                        Oct 30 09:51:58 JimMa - opalka, The JMSRegistryDA can just handle java first use case. right ?
                        Oct 30 09:52:14 opalka - JimMa: This is exactly I wanna discuss now ;)
                        Oct 30 09:52:18 JimMa - opalka, Are you about to talk about WSDL first case ?
                        Oct 30 09:52:34 JimMa - opalka, cool. Please continue ...
                        Oct 30 09:52:49 opalka - JimMa: We're going to cover both usecases ;)
                        Oct 30 09:53:02 opalka - JimMa: You have two paths in your JMSEndpointAddressDA
                        Oct 30 09:53:16 JimMa - opalka, I just thought we've finished discussing . :-)
                        Oct 30 09:53:26 opalka - * all the info necessary for building JMS URI is available in jbossws-cxf.xml
                        Oct 30 09:53:27 asoldano - JimMa, can you please take a look later at the regression we have on hudson in CXF stack? http://jbossws.jboss.org:8180/hudson/job/CXF-CORE-AS-5.0.0-SUN-JDK-6/lastBuild/testReport/
                        Oct 30 09:53:54 JimMa - asoldano, I already checked in the fix for that .
                        Oct 30 09:54:05 asoldano - ok, thanks JimMa
                        Oct 30 09:54:20 JimMa - asoldano, sorry for breaking the build again .
                        Oct 30 09:54:32 asoldano - JimMa, no problem :)
                        Oct 30 09:55:02 opalka - * all the info necessary info for building JMS URI isn't provided in jbossws-cxf.xml
                        Oct 30 09:55:30 opalka - JimMa: For first usecase you'll build the URI and will update endpoint.setAddress()
                        Oct 30 09:55:47 JimMa - asoldano, This weekend , I will clear up my disk. There is no much free space . Then I can run all the tests before commit for the next time .
                        Oct 30 09:55:56 JimMa - opalka, yes.
                        Oct 30 09:56:07 opalka - JimMa: For second usecase you don't provide anything (will be null)
                        Oct 30 09:56:40 opalka - JimMa: This needs another fix in CXF jbossws console (if endpointAddress is null, then display something like UNKNOWN ENDPOINT ADDRESS)
                        Oct 30 09:56:41 asoldano - JimMa, ok. Rerunning one of the jobs on hudson in any case
                        Oct 30 09:57:19 JimMa - opalka, OK.
                        Oct 30 09:57:38 opalka - JimMa: Then we'll need a hack to CXFServletExt.init() or other it's method
                        Oct 30 09:58:06 JimMa - opalka, so we can start to fix the java first usecase first.
                        Oct 30 09:58:50 opalka - JimMa: This hack will lookup the WSDL, will lookup for JMS bindings and will update endpoint address
                        Oct 30 09:59:16 opalka - JimMa: In both use cases JMS transport will be visible in endpoint registry
                        Oct 30 09:59:34 JimMa - opalka, This reminds me of this thing : can the Registry be passed in CXFServletExt ?
                        Oct 30 09:59:39 opalka - JimMa: For WSDL first usecase the JMS uri will be unknown until CXF servlet is started
                        Oct 30 10:00:00 JimMa - opalka, agreed for that .
                        Oct 30 10:00:02 opalka - JimMa: It's there, see protected EndpointRegistry epRegistry;
                        Oct 30 10:00:37 opalka - JimMa: Your JMSEndpointAddressDA will also create new endpoint and register it with registry
                        Oct 30 10:01:03 JimMa - opalka, my silly . Saw that .
                        Oct 30 10:01:27 opalka - JimMa: List of endpoints available for particular web context you'll read from jbossws-cxf.xml
                        Oct 30 10:01:51 JimMa - opalka, OK.
                        Oct 30 10:02:01 opalka - JimMa: Is everything clear to you? Feel free to ask questions ;)
                        Oct 30 10:02:27 JimMa - opalka, The last question.
                        Oct 30 10:03:03 opalka - JimMa: Ah, I almost forget, give JMSEndpointAddressDA the following attribute (property name="relativeOrder" - 20/property - )
                        Oct 30 10:03:22 opalka - JimMa: And of course this DA will be in CXF code base ;)
                        Oct 30 10:03:29 opalka - JimMa: listening ...
                        Oct 30 10:04:08 JimMa - opalka, If I provide the java first jms transport sample and write the servlet in web.xml, this endpoint will be registered .
                        Oct 30 10:04:39 JimMa - opalka, Can I stop it to register and do it in JMSEndpointAddressDA ?
                        Oct 30 10:05:30 opalka - JimMa: No. servlet should be done as it is now
                        Oct 30 10:05:40 opalka - JimMa: You'll take care for JMS endpoint only in that DA
                        Oct 30 10:05:58 JimMa - opalka, OK. Then everything is clear to me .
                        Oct 30 10:06:03 opalka - JimMa: Great
                        Oct 30 10:06:25 opalka - JimMa: I suggest you to save this conversation somewhere so you can have access to it ;)

                        • 9. Re: jms transport support in jbossws-cxf
                          Alessio Soldano Master

                          Jim, Richard suggestion (add a DA to set the JMSEndpointAddress) is good. Thanks Richard.
                          I'd just suggest few additional things that might be useful too:
                          - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case.
                          - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user.
                          - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us?

                          • 10. Re: jms transport support in jbossws-cxf
                            Jim Ma Apprentice

                            Thanks for your input , Alessio.

                            "alessio.soldano@jboss.com" wrote:

                            - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case.

                            Do you mean we can specify the jms address in servlet initial parameter and set it in the JMSDestination when initialize servlet ?
                            <servlet>
                             <servlet-name>MyServletName</servlet-name>
                             <servlet-class>com.mycompany.MyServlet</servlet-class>
                             <init-param>
                             <param-name>jmsJndiRequestQueue</param-name>
                             <param-value>queue/RequestQueue</param-value>
                             </init-param>
                             </servlet>


                            "alessio.soldano@jboss.com" wrote:

                            - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user.


                            Annotation is another way to specify jms transport and address. IMHO, It's flexible to define the jms configuration in web.xml. You do not need to compile the code when you change the queue name .

                            "alessio.soldano@jboss.com" wrote:

                            - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us?

                            IMO, it is another format to attach the jms configuraiton to the client and endpoint. If user provides the jbossws-cxf.xml like this format , we do not support to parse ,extract the jms address information and register the endpoint. We will just support one format like the jbossws-cxf.xml in current jms transport sample.

                            • 11. Re: jms transport support in jbossws-cxf
                              Alessio Soldano Master

                               

                              "jim.ma" wrote:

                              "alessio.soldano@jboss.com" wrote:

                              - consider taking a look at the CXF JMSTransportFactory, perhaps there's an easy hook for getting/setting the address. We currently overwrite the SoapTransportFactory in the bus in CXFServletExt.loadBus(..) in order to implement our own soap address rewriting rules for http endpoints. Perhaps a similar approach might be useful here (extending the jms transport factory, etc.) for the jms case.

                              Do you mean we can specify the jms address in servlet initial parameter and set it in the JMSDestination when initialize servlet ?

                              No, I don't think allowing the jms address to be provided in servlet initial parameters is useful, considering the same can already be achieved using the other descriptor (jbossws-cxf.xml).
                              What I'm thinking about is that you can probably define a new JMSTransportFactory that extends the original one and also uses the information regarding the jms stuff to update the endpoint address in the registry. That information is basically the JMSConfiguration that is currently computed in the jms transport factory.

                              Besides this, I was actually thinking about something else. Another interesting think to do would be to consider the jms endpoints too in the endpoint metrics that we provide (the count of messages, etc.). This is something we can deal with later, but keep an eye for possible integration points, idea, etc.

                              "jim.ma" wrote:

                              "alessio.soldano@jboss.com" wrote:

                              - we might think about something (an annotation?) to mark a jms endpoint when doing java-first, assuming there's not an equivalent way in CXF yet. That could be looked for in the DA to properly write the jbossws-cxf that is generated on the fly when not provided by the user.


                              Annotation is another way to specify jms transport and address. IMHO, It's flexible to define the jms configuration in web.xml. You do not need to compile the code when you change the queue name .

                              Yes, I see what you mean, let's stick with the descriptor for now (the jbossws-cxf.xml)

                              "jim.ma" wrote:

                              "alessio.soldano@jboss.com" wrote:

                              - is the CXF JMSFeature (http://cxf.apache.org/docs/using-the-jmsconfigfeature.html) configuration of any use to us?

                              IMO, it is another format to attach the jms configuraiton to the client and endpoint. If user provides the jbossws-cxf.xml like this format , we do not support to parse ,extract the jms address information and register the endpoint. We will just support one format like the jbossws-cxf.xml in current jms transport sample.

                              OK

                              • 12. Re: jms transport support in jbossws-cxf
                                Jim Ma Apprentice

                                 

                                "alessio.soldano@jboss.com" wrote:

                                What I'm thinking about is that you can probably define a new JMSTransportFactory that extends the original one and also uses the information regarding the jms stuff to update the endpoint address in the registry. That information is basically the JMSConfiguration that is currently computed in the jms transport factory.

                                Now the jms endpoint address comes from the jbossws-cxf.xml now, and CXF will process it internally and set in the JMSCongfiguration. The problem is we want to update/correct the jms endpoint address before servlet initialize (load bus). Because we can not rely on user specifies the load-on-startup to true value . So we decide to parse the jbossws-cxf.xml and extract the jms address in JMSEndpointAddressDA before the stage of servlet really deployed. So IMHO, I do do not think extending the JMSTransportFactory can help this . Correct me if I am wrong, Alessio.

                                "alessio.soldano@jboss.com" wrote:

                                Besides this, I was actually thinking about something else. Another interesting think to do would be to consider the jms endpoints too in the endpoint metrics that we provide (the count of messages, etc.). This is something we can deal with later, but keep an eye for possible integration points, idea, etc.

                                AFAIK, CXF offers some JMX bean to count the soap request message and
                                manage the endpoint and transport destinations : http://cwiki.apache.org/CXF20DOC/jmx-management.html . I also did some work to register these beans in our jboss jmx server : https://jira.jboss.org/jira/browse/JBWS-2805. We can look at how to consolidate it with our management work.

                                • 13. Re: jms transport support in jbossws-cxf
                                  Alessio Soldano Master

                                   

                                  "jim.ma" wrote:
                                  "alessio.soldano@jboss.com" wrote:

                                  What I'm thinking about is that you can probably define a new JMSTransportFactory that extends the original one and also uses the information regarding the jms stuff to update the endpoint address in the registry. That information is basically the JMSConfiguration that is currently computed in the jms transport factory.

                                  Now the jms endpoint address comes from the jbossws-cxf.xml now, and CXF will process it internally and set in the JMSCongfiguration. The problem is we want to update/correct the jms endpoint address before servlet initialize (load bus). Because we can not rely on user specifies the load-on-startup to true value . So we decide to parse the jbossws-cxf.xml and extract the jms address in JMSEndpointAddressDA before the stage of servlet really deployed. So IMHO, I do do not think extending the JMSTransportFactory can help this . Correct me if I am wrong, Alessio.

                                  You're right in the usecase where the jbossws-cxf.xml is provided and has the jms address. I'm thinking about the other use case, perhaps my suggestion could be useful for a late setup of the address in that case. But let's start with the first case, then we'll see what we can do.

                                  "jim.ma" wrote:

                                  "alessio.soldano@jboss.com" wrote:

                                  Besides this, I was actually thinking about something else. Another interesting think to do would be to consider the jms endpoints too in the endpoint metrics that we provide (the count of messages, etc.). This is something we can deal with later, but keep an eye for possible integration points, idea, etc.

                                  AFAIK, CXF offers some JMX bean to count the soap request message and
                                  manage the endpoint and transport destinations : http://cwiki.apache.org/CXF20DOC/jmx-management.html . I also did some work to register these beans in our jboss jmx server : https://jira.jboss.org/jira/browse/JBWS-2805. We can look at how to consolidate it with our management work.

                                  Sure, this is what we talked about on IRC yesterday, I agree.