June 2007 - jbossws-dev - Jboss List Archives

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

Hi Guys. So Thomas, I had a look at the new additions around the JAXBHandler interface and I think this will work for JBossESB. I was afraid that it might require the ESB user to get down and dirty with the JBossWS bean configs, but I see that the handler can be set on the Endpoint - for some reason I missed that in your earlier post - sorry :-) I'll be back if I run into any issues. Thanks for sorting this out for us guys :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058300#4058300 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058300

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

"tfennelly" wrote : "thomas.diesler(a)jboss.com" wrote : Tom, the change to the SPI supersedes Heiko's proposal AFAICS. Injecting your own JAXBHandler on the Endpoint should allow you to create, cache, etc the JAXBContext any way you want | | Ah OK, thanks Thomas. I'll have a look at that so. I assume it's in the 2.0.x codebase. Will this then require users of this ESB feature to have to go making low level mods to the container bean configurations? We we re hoping to avoid imposing that kind of requirement! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058017#4058017 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058017

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

"thomas.diesler(a)jboss.com" wrote : Tom, the change to the SPI supersedes Heiko's proposal AFAICS. Injecting your own JAXBHandler on the Endpoint should allow you to create, cache, etc the JAXBContext any way you want Ah OK, thanks Thomas. I'll have a look at that so. I assume it's in the 2.0.x codebase. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058016#4058016 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058016

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by thomas.diesler＠jboss.com

Tom, the change to the SPI supersedes Heiko's proposal AFAICS. Injecting your own JAXBHandler on the Endpoint should allow you to create, cache, etc the JAXBContext any way you want View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058013#4058013 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058013

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

"thomas.diesler(a)jboss.com" wrote : Tom, I assume this only applies to JAXWS endpoints. The JAXWS client API is not affected. That's right Thomas. "heiko.braun(a)jboss.com" wrote : If Thomas suggestion is correct, which means the customizations are only required for JAX-WS endpoints then we might actually go with a solutions that attaches to the InvocationContext. I.e. a Map like Interface | | | InvocationContext.addAttachment(JAXBContexCustomisation.class, <Instance>); | | | | that can carry JAXBRI default properties. See http://jsourcery.com/api/java.net/jaxb/2.1.2/com/sun/xml/bind/api/JAXBRIC... for a complete list. | | This way at least the JBossWS RequestHandlerImpl is open to any JAXB customisation. Other RequestHandler would then just disregard these attachments. | | Tom, would this be sufficient? Can you supply this information on a per-invocation base? Or might this better be attached to the Endpoint - on a per-deployment base? I don't really grasp the use cases yet. This would be perfect Heiko and is actually what I was trying to do, but I just couldn't figure out how to get the Properties instance back from within JAXBContextCache. As I said in my original post on this thread... anonymous wrote : I have this working at the moment simply by setting and getting the properties on a ThreadLocal. I was hoping there'd be a nicer way e.g. by attaching it to the InvocationContext perhaps, but I can't seem locate it in the JAXBContextCache e.g. through the current CommonMessageContext on the executing thread. If I could get this properties list back from within the JAXBContextCache (or JAXBContextFactory now), this would be the ideal solution as I see it at the moment. I just couldn't see how to get it back at the time I made the original post - I'm not familiar with the JBossWS code. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058010#4058010 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4058010

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by thomas.diesler＠jboss.com

I externalized construction of the JAXBContext in a JAXBHandler which is a property on the Endpoint. | public interface JAXBHandler | { | /** Get a JAXBContext instance. | */ | JAXBContext getJAXBContext(Class[] javaTypes) throws JAXBException; | } | | public interface Endpoint | { | ... | | /** Get the JAXBHandler for this endpoint */ | JAXBHandler getJAXBHandler(); | | /** Set the JAXBHandler for this endpoint */ | void setJAXBHandler(JAXBHandler handler); | | ... | } | The JAXBHandler is injected like any other handler | <bean name="WSEndpointHandlerDeployer" class="org.jboss.wsf.spi.deployment.EndpointHandlerDeployer"> | <property name="requestHandler">org.jboss.wsf.stack.jbws.RequestHandlerImpl</property> | <property name="lifecycleHandler">org.jboss.wsf.stack.jbws.LifecycleHandlerImpl</property> | <property name="jaxbHandler">org.jboss.wsf.spi.binding.jaxb.JAXBContextCache</property> | <property name="invocationHandler"> | <map keyClass="java.lang.String" valueClass="java.lang.String"> | <entry><key>JAXRPC_JSE</key><value>org.jboss.wsf.stack.jbws.ServiceLifecycleInvocationHandler</value></entry> | <entry><key>JAXRPC_EJB21</key><value>org.jboss.wsf.container.jboss42.InvocationHandlerEJB21</value></entry> | <entry><key>JAXRPC_MDB21</key><value>org.jboss.wsf.container.jboss42.InvocationHandlerMDB21</value></entry> | <entry><key>JAXWS_JSE</key><value>org.jboss.wsf.stack.jbws.ServiceLifecycleInvocationHandler</value></entry> | <entry><key>JAXWS_EJB3</key><value>org.jboss.wsf.container.jboss42.InvocationHandlerEJB3</value></entry> | </map> | </property> | </bean> | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057999#4057999 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057999

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by heiko.braun＠jboss.com

I did already break up the JAXBContextCache and the JAXBContextFactory. Regardless on how we proceed, this was a good idea anyway. If Thomas suggestion is correct, which means the customizations are only required for JAX-WS endpoints then we might actually go with a solutions that attaches to the InvocationContext. I.e. a Map like Interface | InvocationContext.addAttachment(JAXBContexCustomisation.class, <Instance>); | that can carry JAXBRI default properties. See http://jsourcery.com/api/java.net/jaxb/2.1.2/com/sun/xml/bind/api/JAXBRIC... for a complete list. This way at least the JBossWS RequestHandlerImpl is open to any JAXB customisation. Other RequestHandler would then just disregard these attachments. Tom, would this be sufficient? Can you supply this information on a per-invocation base? Or might this better be attached to the Endpoint - on a per-deployment base? I don't really grasp the use cases yet. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057907#4057907 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057907

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by thomas.diesler＠jboss.com

Tom, I assume this only applies to JAXWS endpoints. The JAXWS client API is not affected. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057892#4057892 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057892

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by mark.little＠jboss.com

"tfennelly" wrote : +1 | | We need something agreed for 2.0.0 and I'd guess it's too late for a neutral SPI based solution at this stage, yes/no? | >From a purely ESB perspective, WS neutrality is not important in 4.2. JBossWS is all we'll be supporting. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057844#4057844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057844

16 years, 11 months

1
0
0 / 0

[Design of JBoss Web Services] - Re: Setting the properties on the JAXBContext

by tfennelly

+1 We need something agreed for 2.0.0 and I'd guess it's too late for a neutral SPI based solution at this stage, yes/no? At the end of the day I'd imagine something like this will be required for this type of usecase, no matter what the underlying stack + marshal/unmarshal technology combo is, yeah? I know XStream has it's own non-standards based set of annotations (aliases), as well as an external XML config model that it uses for defining what is essentially the same binding metadata - namespaces, types etc. If the JBossWS SPI is going to accommodate defining these external configs ala what we've done for JAXB and what XStream has in its alias configs, will it pick one standard and map to the underlying impl or what? If it goes with one standard, would something based on JAXB and it's annotations be the natural choice? Anyway, maybe that's all for another day - we need something for 2.0.0 asap :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057774#4057774 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057774

16 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbossws-dev June 2007