You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jarek Gawor <jg...@gmail.com> on 2007/02/28 19:39:48 UTC
CXF-440
Hi,
I just submitted https://issues.apache.org/jira/browse/CXF-440. I
would appreciate if somebody could review it, comment on it, etc. or
possibly commit if it looks alright. One thing I'm unsure of is what
is the best way to pass a custom catalog around (as I need in Geronimo
an explicit way to do so).
Thanks,
Jarek
Re: CXF-440
Posted by Jarek Gawor <jg...@gmail.com>.
Daniel,
Great. All the things you mentioned sound good to me. At the end, I
don't care how the patch gets refactored as long as the functionality
is there :)
Thanks,
Jarek
On 2/28/07, Daniel Kulp <da...@iona.com> wrote:
>
> Jarek,
>
> On Wednesday 28 February 2007 13:39, Jarek Gawor wrote:
> > I just submitted https://issues.apache.org/jira/browse/CXF-440. I
> > would appreciate if somebody could review it, comment on it, etc. or
> > possibly commit if it looks alright. One thing I'm unsure of is what
> > is the best way to pass a custom catalog around (as I need in Geronimo
> > an explicit way to do so).
>
> Thanks a TON for looking into the catelog stuff. It's been kind of on my
> todo list. You picking up the start of it is GREAT!
>
> It's definitely not "complete" yet, but I'm going to commit your patch
> almost as is as it's a good starting point. We'll need to address a few
> issues:
>
> 1) I changed it to using the 1.2 version of xml-resolver. The pom for 1.1
> is very minimal which results in an ugly notice file. The tests run fine
> with 1.2.
>
> 2) I'm uncomfortable with the loading of jax-ws-catalog.xml files in core.
> That filename is a jax-ws spec thing and thus belongs in the jaxws
> frontend. Most likely, be default, we'd search for "cxf-catalog.xml" and
> the default "xcatalog" files, but the frontends could register additional
> names to search for.
>
> 3) I think we want to define a CatalogManager interface in cxf-api that
> manages the catalogs, or at least the global level settings such as the
> names of the files to search for. It could also cache the Catalogs based
> on the ClassLoader or similar to help processing later.
>
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194
> daniel.kulp@iona.com
> http://www.dankulp.com/blog
>
RE: CXF-437: @Resources are not injected into Handlers
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, just had an online chat with DanK, he mentioned that the use case one is the problem he noticed while fixing some stuff for Jarek, I will fix this first.
Cheers,
Jervis
> -----Original Message-----
> From: Liu, Jervis [mailto:jliu@iona.com]
> Sent: 2007?3?1? 17:10
> To: cxf-dev@incubator.apache.org
> Subject: CXF-437: @Resources are not injected into Handlers
>
>
> Hi, I am currently looking into CXF-437
> http://issues.apache.org/jira/browse/CXF-437. What I am
> trying to figure out is what kind of @Resource are valid
> resources that can be injected into handlers. Through a quick
> search into JSR-109, as far as I can find, following resouces
> are injectable into handlers:
>
> 1. When CXF is deployed into a servlet container, the
> component's context and environment entries are injected into
> handlers. JSR-109, section 6.2.3:
>
> With JAX-WS, the handler allows for resources to be injected,
> typically by using the @Resource annotation. So
> a Handler.handle<action>() method may access the component's
> context and environment entries by using any
> resources that were injected. It can also use JNDI lookup of
> the "java:comp/env" context and accessing
> the env-entry-names defined in the deployment descriptor by
> performing a JNDI lookup. See chapter 15
> of the Enterprise JavaBeans specification - Enterprise
> JavaBeans Core Contracts and Requirements for details.
> The container may throw a java.lang.IllegalStateException if
> the environment is accessed from
> any other Handler method and the environment is not
> available. The element init-params in the
> deployment descriptors is no longer used for JAX-WS based
> container. If needed, the developer should use the
> environment entry elements (<env-entry>) declared in the
> application component's deployment descriptor for
> this purpose. These can be injected into the handler using
> the @Resource annotation or looked up using JNDI.
>
> An example of this use case: [1]. As a side note, we also
> need to support the JNDI look up of environment entries from
> handlers in order to make CXF JAX-WS spec compliant.
>
> 2. The injection of javax.xml.ws.WebServiceContext. JSR-109,
> section 6.2.4:
>
> A JAX-WS based container must carry out any injections (if
> any) requested by the handler, typically via the
> @Resource annotation (see section 2.2 of JSR-250 Common
> Annotations for Java Platform specification). A
> JAX-WS handler should use the javax.xml.ws.WebServiceContext,
> which is an injectable resource,
> to access message context and security information relative
> to the request being served. A unique Handler
> instance must be provided for each Port component declared in
> the deployment descriptor or annotated by
> javax.jws.WebService or javax.xml.ws.WebServiceProvider annotations.
>
> CXF does support the injection of WebServiceContext in
> endpoint but not in handlers yet. I presume a code snippet
> that has the injection of WebServiceContext would look like below:
>
> public class MyHandler implements SOAPHandler<SOAPMessageContext> {
> ....
> @Resource
> WebServiceContext context
> ...
> }
>
> Am I reading the spec correctly? anything missing? I will
> create two jiras to support case 1 and 2 if it looks ok.
>
> Thanks,
> Jervis
>
> [1]. http://forums.java.net/jive/thread.jspa?messageID=131230&tstart=0
>
CXF-437: @Resources are not injected into Handlers
Posted by "Liu, Jervis" <jl...@iona.com>.
Hi, I am currently looking into CXF-437 http://issues.apache.org/jira/browse/CXF-437. What I am trying to figure out is what kind of @Resource are valid resources that can be injected into handlers. Through a quick search into JSR-109, as far as I can find, following resouces are injectable into handlers:
1. When CXF is deployed into a servlet container, the component's context and environment entries are injected into handlers. JSR-109, section 6.2.3:
With JAX-WS, the handler allows for resources to be injected, typically by using the @Resource annotation. So
a Handler.handle<action>() method may access the component's context and environment entries by using any
resources that were injected. It can also use JNDI lookup of the "java:comp/env" context and accessing
the env-entry-names defined in the deployment descriptor by performing a JNDI lookup. See chapter 15
of the Enterprise JavaBeans specification - Enterprise JavaBeans Core Contracts and Requirements for details.
The container may throw a java.lang.IllegalStateException if the environment is accessed from
any other Handler method and the environment is not available. The element init-params in the
deployment descriptors is no longer used for JAX-WS based container. If needed, the developer should use the
environment entry elements (<env-entry>) declared in the application component's deployment descriptor for
this purpose. These can be injected into the handler using the @Resource annotation or looked up using JNDI.
An example of this use case: [1]. As a side note, we also need to support the JNDI look up of environment entries from handlers in order to make CXF JAX-WS spec compliant.
2. The injection of javax.xml.ws.WebServiceContext. JSR-109, section 6.2.4:
A JAX-WS based container must carry out any injections (if any) requested by the handler, typically via the
@Resource annotation (see section 2.2 of JSR-250 Common Annotations for Java Platform specification). A
JAX-WS handler should use the javax.xml.ws.WebServiceContext, which is an injectable resource,
to access message context and security information relative to the request being served. A unique Handler
instance must be provided for each Port component declared in the deployment descriptor or annotated by
javax.jws.WebService or javax.xml.ws.WebServiceProvider annotations.
CXF does support the injection of WebServiceContext in endpoint but not in handlers yet. I presume a code snippet that has the injection of WebServiceContext would look like below:
public class MyHandler implements SOAPHandler<SOAPMessageContext> {
....
@Resource
WebServiceContext context
...
}
Am I reading the spec correctly? anything missing? I will create two jiras to support case 1 and 2 if it looks ok.
Thanks,
Jervis
[1]. http://forums.java.net/jive/thread.jspa?messageID=131230&tstart=0
Re: CXF-440
Posted by Daniel Kulp <da...@iona.com>.
Jarek,
On Wednesday 28 February 2007 13:39, Jarek Gawor wrote:
> I just submitted https://issues.apache.org/jira/browse/CXF-440. I
> would appreciate if somebody could review it, comment on it, etc. or
> possibly commit if it looks alright. One thing I'm unsure of is what
> is the best way to pass a custom catalog around (as I need in Geronimo
> an explicit way to do so).
Thanks a TON for looking into the catelog stuff. It's been kind of on my
todo list. You picking up the start of it is GREAT!
It's definitely not "complete" yet, but I'm going to commit your patch
almost as is as it's a good starting point. We'll need to address a few
issues:
1) I changed it to using the 1.2 version of xml-resolver. The pom for 1.1
is very minimal which results in an ugly notice file. The tests run fine
with 1.2.
2) I'm uncomfortable with the loading of jax-ws-catalog.xml files in core.
That filename is a jax-ws spec thing and thus belongs in the jaxws
frontend. Most likely, be default, we'd search for "cxf-catalog.xml" and
the default "xcatalog" files, but the frontends could register additional
names to search for.
3) I think we want to define a CatalogManager interface in cxf-api that
manages the catalogs, or at least the global level settings such as the
names of the files to search for. It could also cache the Catalogs based
on the ClassLoader or similar to help processing later.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog