Hi Dans,
It is hard to make the EndpointPublisher consume the all different
front end's endpoint metadata.
I think the Spring way is a better solution.
First Spring Beans configuration file is fexible that we can use it to
wire all front ends' endpoint, and the RI syntax has it limition that it
can't support js frontend and we can't setup the handlers for different
endpoints with different bus.
Second Spring configure file make the CXF-Servlet decoupled with the
endpoint publishing stuff, and we can work around the issue of embedding
the publisher classname into the xml.
And I just did a quick research about the RI's servlet support. I found
they provided the spring support in 2.1 final release[1].
Current CXF supports to init a endpoint from spring context. All I need
to do is to update the sample's to using the Spring.xml and add Js front
end servlet systest.
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 ?
[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* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> 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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
