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