[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by alessio.soldano＠jboss.com
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?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263779#4263779
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263779
15 years, 2 months
- 1
- 0
JBWS-2814 and JBWS-2791
by Alessio Soldano
Hi Jim,
what's the relationship between the issues on topic? Please properly
update jira (link them if required, close one of them if they're
duplicated, etc.)
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
15 years, 2 months
- 2
- 1
[JBoss Web Services Development] - Re: jms transport support in jbossws-cxf
by richard.opalka＠jboss.com
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(a)vpn1-5-235.ams2.redhat.com) has joined #jbossws
Oct 30 07:15:41 * tyasuma (~tyasuma(a)vpn-226-77.phx2.redhat.com) has left #jbossws
Oct 30 07:17:23 * tyasuma_ (~tyasuma(a)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(a)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(a)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(a)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(a)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(a)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/last...
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
15 years, 2 months
- 1
- 0
Re: [jbossws-dev] Compression handler
by Alessio Soldano
Hi Trustin,
Trustin Lee wrote:
> Hi Alessio,
>
> I've just finished the decompression support for Netty HTTP.
Cool :-)
> I wonder if you need server-side compression, too. I think it needs to be implemented somewhat differently than decompression because it requires some contextual information such as 'Accept-Encoding'. Please let me know if you have any specific requirements.
>
Well, yes, please. Starting from JBossWS 3.2.1.GA which I'm releasing
today, we're currently using Netty on server side too for publishing ws
endpoints using the Endpoint API (as well as for the WS-RM backport
server). So we'd really appreciate this too.
Thanks a lot
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
15 years, 2 months
- 1
- 0