cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: Some change about the CXF Servlet
Date Thu, 08 Feb 2007 19:43:50 GMT
On Wednesday 07 February 2007 04:00, Willem Jiang wrote:
> Here I just want to ask an other question.
> Do we still need to support the RI's sun-jaxws.xml syntax in CXF ?
> If So , how can we wrap the jaxws publisher in CXF Servlet ?

I would say no.   If we need to, we could easily provide an xsl script or 
similar to create a cxf version from the sun version.    That should be easy 
to do.

Dan


>
>
> [1]
> http://weblogs.java.net/blog/kohsuke/archive/2007/01/spring_support.html
>
> Thanks,
>
> Willem.
>
> Dan Diephouse wrote:
> > Agreed, I'm -1 on this as well. I think we should either a) support
> > the RI syntax (which seems rather limited) or b) Use the Spring 2.0
> > extensions for creation of endpoints. The latter will be much more
> > powerful and I don't think any more confusing. XFire users seemed to
> > handle having their root element be <beans> alright at least :-)
> >
> > - Dan
> >
> > On 2/6/07, *Daniel Kulp* <daniel.kulp@iona.com
> > <mailto:daniel.kulp@iona.com>> wrote:
> >
> >
> >     Willem,
> >
> >     The commit you did is still unacceptable as it doesn't address the
> >     issue of
> >     embedding the publisher classname into the xml.   It also doesn't
> >     address the
> >     issue of frontends that have completely different sets of metadata
> >     than the
> >     jaxws frontend.   For example:
> >
> >     public interface EndpointPublisher {
> >         void buildEndpoint(Bus bus, String implName, String serviceName,
> >               URL wsdl, String portName)  throws BusException;
> >         void publish(String address) throws BusException;
> >     }
> >
> >     What about javascript that doesn't really have a implName or where
> >     it needs
> >     other information beyond that?
> >
> >     Dan and I gave a couple of suggestions for a better/cleaner
> >     design.   Could
> >     you please look at them and figure out which would work best and
> >     go with
> >     that?   Or come up with your own and propose it here.    This
> >     current design
> >     is not workable.
> >
> >     I'm not going to -1 the commit yet as I'd like you to have the
> >     opportunity to
> >     examine alternatives and get it fixed.
> >
> >     Thanks!
> >     Dan
> >
> >     On Tuesday 06 February 2007 00:51, Willem Jiang wrote:
> >     > Hi Dan,
> >     > Please forget what I had said about finding the publisher by
> >
> >     looking the
> >
> >     > namespace.  I have no idea to make the cxf-servlet.xml more
> >     > flexible now :).
> >     >
> >     > If the cxf-servlet need to keep compatible with the JAX-WS
> >
> >     RI,  I think
> >
> >     > we can set the default publisher to be
> >     > org.apache.cxf.jaxws.EndpointPublisherImpl . If CXF-Servlet
> >
> >     can't find
> >
> >     > the publisher attribute from the endpoint element, we set the
> >
> >     publisher
> >
> >     > name to be org.apache.cxf.jaxws.EndpointPublisherImpl.
> >     >
> >     > I will update  this to  my current refactoring work. I hope I
> >
> >     can make a
> >
> >     > commitment today.
> >     > So the only effection of my CXF-Servlet  commitment  is to
> >
> >     change the
> >
> >     > servlet-class name from "org.apache.cxf.jaxws.servlet.CXFServlet"
> >     > to "org.apache.cxf.transport.servlet.CXFServlet " in the web.xml.
> >     >
> >     > Cheers,
> >     >
> >     > Willem.
> >     >
> >     > Daniel Kulp wrote:
> >     > >On Sunday 04 February 2007 23:39, Willem Jiang wrote:
> >     > >>Hi Dan,
> >     > >>
> >     > >>Yes,  If we expose too much detail to the user , it will be
> >
> >     painful for
> >
> >     > >>us when we are doing the refactoring stuff.
> >     > >>
> >     > >>Current CXF Servlet refactoring just make the Servlet decouple
> >
> >     with the
> >
> >     > >>jaxws front end. In this way the servlet need to get to know
> >
> >     which
> >
> >     > >>publisher implementing could be used in the servlet.
> >     > >>We can take the publisher as the transport factory and load
> >
> >     different
> >
> >     > >>publisher by the namespace which is defined in the
> >
> >     cxf-servlet.xml.
> >
> >     > >Honestly, I have no idea what you just said here.
> >     > >
> >     > >>But we also need to write the servlet class name in Web.xml.
> >
> >     Can we make
> >
> >     > >>it parent to the user ?
> >     > >
> >     > >This is mostly because we try to make the war completely
> >     > > app-server independent.   There are ways to register a context
> >     > > listener (or something, don't remember exactly what.  Tuscany
> >     > > does it.)
> >
> >     with tomcat
> >
> >     > > that would allow the war to not have the web.xml at all.   All
> >
> >     that would
> >
> >     > > be needed is the cxf-servlet.xml file.
> >     > >
> >     > >That said, the web.xml is a straight copy from the one in
> >
> >     etc.   The user
> >
> >     > >doesn't have to touch it to get their app working.   They don't
> >
> >     need to
> >
> >     > > even know there is a classname in there.
> >     > >
> >     > >>Here is another thought that CXF Servlet also support create
> >
> >     the service
> >
> >     > >>by Spring configuration xml.  I think we also need to make it
> >     > >>sophisticated to support different front-end.
> >     > >
> >     > >I'd definitely be OK with this as long as we go the Spring 2.0
> >
> >     route that
> >
> >     > > Dan has been doing so it's relatively clean looking and not so
> >
> >     "springy".
> >
> >     > >Just FYI: the current format for the cxf-servlet.xml file was
> >
> >     used as it's
> >
> >     > >completely compatible with the JAX-WS RI.   If you take the
> >
> >     sun-jaxws.xml
> >
> >     > >from a JAX-WS RI app and rename it to cxf-servlet.xml and
> >
> >     change the
> >
> >     > > web.xml to ours, the apps are supposed to work.  (within the
> >
> >     limits of
> >
> >     > > the parts of jax-ws that we currently have working).     If we
> >
> >     add the
> >
> >     > > "publisher" or anything to it to distinguish the frontend,
> >
> >     we're going to
> >
> >     > > break that anyway. We might as well go a clean route and use
> >
> >     the schema
> >
> >     > > and the Spring 2.0 stuff.
> >     > >
> >     > >Dan
> >     > >
> >     > >>Cheers,
> >     > >>
> >     > >>Willem.
> >     > >>
> >     > >>Daniel Kulp wrote:
> >     > >>>On Sunday 04 February 2007 20:27, Willem Jiang wrote:
> >     > >>>>2. cxf-servlet.xml
> >     > >>>>Adding a publisher attribute in the endpoint element.
> >     > >>>>It should be
> >
> >     publisher="org.apache.cxf.jaxws.EndpointPublisherImpl"
> >
> >     > >>>>You can find the example from the systest or the kit's
samples
> >     > >>>>hello_world . Please feel free to  get  touch with me 
if
> >
> >     you  have any
> >
> >     > >>>>issue about the CXF  Servlet.
> >     > >>>
> >     > >>>I really don't like this part of this.   You end up forcing
> >
> >     people to
> >
> >     > >>>embed internal class names into the XML file and thus know
> >
> >     internal
> >
> >     > >>>details about the implementations.  It also prevents us from
> >
> >     refactoring
> >
> >     > >>>things, renaming classes, etc... without breaking the users
> >     > >>> apps.
> >     > >>>
> >     > >>>This needs to change to some sort of registry system where
> >
> >     the frontends
> >
> >     > >>>can register a handler to the servlet/bus and the XML just
> >
> >     has some sort
> >
> >     > >>>of key for the XML.   I'd prefer a namespace qualified thing
> >
> >     where the
> >
> >     > >>>frontend could provide an entire schema for their section of
> >
> >     the XML.
> >
> >     > >>>If the frontend needs some additional elements in the XML
> >
> >     file, they can
> >
> >     > >>>do it.
> >
> >     --
> >     J. Daniel Kulp
> >     Principal Engineer
> >     IONA
> >     P: 781-902-8727    C: 508-380-7194
> >     daniel.kulp@iona.com <mailto:daniel.kulp@iona.com>
> >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog

-- 
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727    C: 508-380-7194
daniel.kulp@iona.com

Mime
View raw message