You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Willem Jiang <ni...@iona.com> on 2007/02/05 02:27:29 UTC
Some change about the CXF Servlet
Hi,
I am working on the CXF Servlet refactoring to make the servlet
transport independent of the JAX-WS frontend.
I just moved the CXF Servlet from the Jaxws front end to http transport.
It will effect to CXF servlet demos and CPI tests.
Please update these two file
1. web.xml
Changing the <servlet-class> element value from
"org.apache.cxf.*jaxws*.servlet.CXFServlet" to
"org.apache.cxf.*transport*.servlet.CXFServlet"
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.
Cheers,
Willem.
Re: Question about imported element baseUri in XMLSchema
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sure thing, here it is:
http://fisheye.codehaus.org/browse/xfire/trunk/xfire/xfire-generator/src/main/org/codehaus/xfire/gen/jaxb/JAXBSchemaSupport.java?r=2061#l82
I will check into fixing XmlSchema and see if we can get that fixed as well.
- Dan
On 2/6/07, Jim Ma <ji...@iona.com> wrote:
>
> Thanks Dan ,
>
> I think XMlSchema is needed to enhance . Reserializing the schemas is not
> the good and ideal way
> to get schema elements .
>
> The solution [3] is simple and effective. Can you point me the XFire
> source code that works around
> this problem ?
>
> Thanks
>
> Jim
>
>
> > -----Original Message-----
> > From: Dan Diephouse [mailto:dan@envoisolutions.com]
> > Sent: Monday, February 05, 2007 11:29 PM
> > To: cxf-dev@incubator.apache.org
> > Subject: Re: Question about imported element baseUri in XMLSchema
> >
> >
> > There isn't a very good way to get at *all* the schema documents as we
> > discussed in this issue:
> >
> > https://issues.apache.org/jira/browse/CXF-363?page=com.atlassian.j
> ira.plugin.system.issuetabpanels:all-tabpanel
> >
> > Calling getDocumentElement() actually reserializes the schemas.
> > There are a
> > couple possible solutions to this, and I would like to get feedback from
> > others on them.
> >
> > 1. Enhance XmlSchema to store the original Elements which were the
> backing
> > document. I'm not sure how much work or how feasible this is.
> > 2. Switch to use XSOM and resolve all the schema Elements correctly
> > http://xsom.dev.java.net
> > 3. Don't do anything. The realization here would be that we don't
> actually
> > need to resolve the schemas ourselves. In XFire we just gave JAXB
> > the schema
> > Elements that were in the WSDL and it took care of finding the imports
> and
> > resolving them correctly. The original schema Elements can be found in
> > SchemaInfo.getElement() (as oppsed to
> > SchemaInfo.getSchema().getDocumentElement()].
> >
> >
> > Regards,
> > - Dan
> >
> > On 2/4/07, Jim Ma <ji...@iona.com> wrote:
> > >
> > > Hi ,
> > >
> > > I use the following code to read the schemaA which import the
> > schemaB and
> > > print the base uri
> > >
> > > for each schema element :
> > >
> > >
> > > schemaCol.setBaseUri(schemaBaseUri);
> > > schemaCol.setSchemaResolver (new XmlSchemaURIResolver());
> > > XmlSchema xmlSchema = schemaCol.read(schemaA);
> > >
> > > When I check the imported schema element base uri , I always get null.
> > >
> > > Document[] docs = xmlSchema.getAllSchemas();
> > > for (int i = 0; i < docs.length; i++) {
> > > Element ele = docs[i].getDocumentElement();
> > > System.out.println("--- getBaseUri---- " + ele.getBaseURI());
> > > }
> > >
> > > I always get null value .Is there anything I need to set for schemaCol
> ?
> > >
> > > Thanks
> > >
> > > Jim
> > >
> > >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
RE: Question about imported element baseUri in XMLSchema
Posted by Jim Ma <ji...@iona.com>.
Thanks Dan ,
I think XMlSchema is needed to enhance . Reserializing the schemas is not
the good and ideal way
to get schema elements .
The solution [3] is simple and effective. Can you point me the XFire
source code that works around
this problem ?
Thanks
Jim
> -----Original Message-----
> From: Dan Diephouse [mailto:dan@envoisolutions.com]
> Sent: Monday, February 05, 2007 11:29 PM
> To: cxf-dev@incubator.apache.org
> Subject: Re: Question about imported element baseUri in XMLSchema
>
>
> There isn't a very good way to get at *all* the schema documents as we
> discussed in this issue:
>
> https://issues.apache.org/jira/browse/CXF-363?page=com.atlassian.j
ira.plugin.system.issuetabpanels:all-tabpanel
>
> Calling getDocumentElement() actually reserializes the schemas.
> There are a
> couple possible solutions to this, and I would like to get feedback from
> others on them.
>
> 1. Enhance XmlSchema to store the original Elements which were the backing
> document. I'm not sure how much work or how feasible this is.
> 2. Switch to use XSOM and resolve all the schema Elements correctly
> http://xsom.dev.java.net
> 3. Don't do anything. The realization here would be that we don't actually
> need to resolve the schemas ourselves. In XFire we just gave JAXB
> the schema
> Elements that were in the WSDL and it took care of finding the imports and
> resolving them correctly. The original schema Elements can be found in
> SchemaInfo.getElement() (as oppsed to
> SchemaInfo.getSchema().getDocumentElement()].
>
>
> Regards,
> - Dan
>
> On 2/4/07, Jim Ma <ji...@iona.com> wrote:
> >
> > Hi ,
> >
> > I use the following code to read the schemaA which import the
> schemaB and
> > print the base uri
> >
> > for each schema element :
> >
> >
> > schemaCol.setBaseUri(schemaBaseUri);
> > schemaCol.setSchemaResolver (new XmlSchemaURIResolver());
> > XmlSchema xmlSchema = schemaCol.read(schemaA);
> >
> > When I check the imported schema element base uri , I always get null.
> >
> > Document[] docs = xmlSchema.getAllSchemas();
> > for (int i = 0; i < docs.length; i++) {
> > Element ele = docs[i].getDocumentElement();
> > System.out.println("--- getBaseUri---- " + ele.getBaseURI());
> > }
> >
> > I always get null value .Is there anything I need to set for schemaCol ?
> >
> > Thanks
> >
> > Jim
> >
> >
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
>
Re: Question about imported element baseUri in XMLSchema
Posted by Dan Diephouse <da...@envoisolutions.com>.
There isn't a very good way to get at *all* the schema documents as we
discussed in this issue:
https://issues.apache.org/jira/browse/CXF-363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Calling getDocumentElement() actually reserializes the schemas. There are a
couple possible solutions to this, and I would like to get feedback from
others on them.
1. Enhance XmlSchema to store the original Elements which were the backing
document. I'm not sure how much work or how feasible this is.
2. Switch to use XSOM and resolve all the schema Elements correctly
http://xsom.dev.java.net
3. Don't do anything. The realization here would be that we don't actually
need to resolve the schemas ourselves. In XFire we just gave JAXB the schema
Elements that were in the WSDL and it took care of finding the imports and
resolving them correctly. The original schema Elements can be found in
SchemaInfo.getElement() (as oppsed to
SchemaInfo.getSchema().getDocumentElement()].
Regards,
- Dan
On 2/4/07, Jim Ma <ji...@iona.com> wrote:
>
> Hi ,
>
> I use the following code to read the schemaA which import the schemaB and
> print the base uri
>
> for each schema element :
>
>
> schemaCol.setBaseUri(schemaBaseUri);
> schemaCol.setSchemaResolver (new XmlSchemaURIResolver());
> XmlSchema xmlSchema = schemaCol.read(schemaA);
>
> When I check the imported schema element base uri , I always get null.
>
> Document[] docs = xmlSchema.getAllSchemas();
> for (int i = 0; i < docs.length; i++) {
> Element ele = docs[i].getDocumentElement();
> System.out.println("--- getBaseUri---- " + ele.getBaseURI());
> }
>
> I always get null value .Is there anything I need to set for schemaCol ?
>
> Thanks
>
> Jim
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Some change about the CXF Servlet
Posted by Willem Jiang <ni...@iona.com>.
Hi Dan,
Daniel Kulp wrote:
>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
>
>
>
I talked with Dan Diephouse, he is working on the <jaxws endpoint ...>
implementation.
I will remove my jaxws publisher and use the xsl transformer for RI's
syntax, when his work is done.
Willem.
Re: Some change about the CXF Servlet
Posted by Daniel Kulp <da...@iona.com>.
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
> > <ma...@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 <ma...@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
Re: Some change about the CXF Servlet
Posted by Willem Jiang <ni...@iona.com>.
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* <daniel.kulp@iona.com
> <ma...@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 <ma...@iona.com>
>
>
>
>
> --
> Dan Diephouse
> Envoi Solutions
> http://envoisolutions.com | http://netzooid.com/blog
Re: Some change about the CXF Servlet
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <da...@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
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: Some change about the CXF Servlet
Posted by Daniel Kulp <da...@iona.com>.
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
Re: Some change about the CXF Servlet
Posted by Willem Jiang <ni...@iona.com>.
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.
>>>
>>>
>
>
>
Re: Some change about the CXF Servlet
Posted by Daniel Kulp <da...@iona.com>.
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
Re: Some change about the CXF Servlet
Posted by Willem Jiang <ni...@iona.com>.
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.
But we also need to write the servlet class name in Web.xml. Can we make
it parent to the user ?
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.
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.
>
>
>
Re: Some change about the CXF Servlet
Posted by Willem Jiang <ni...@iona.com>.
Hi Dan,
I was trying to unstand
<beans ...>
<jaxws:endpoint implementor="foo.bar.MyEndpoint"/>
</beans>
Can you give me more detail example about the '...' you just missed in
the Beans configureation?
I just want to know how can some other attribute in the endpoint element
like name, url-pattern, wsdl, service, port be set to endpoint?
I saw some codes in org.apache.cxf.jaxws.spring package. The
EndpointBean will publish the endpoint in the afterPropertiesSet().
Thanks,
Willem.
Dan Diephouse wrote:
> We could leverage Spring here if we wnated to. I'm in the midst of
> writing a
> Spring 2.0 handlers so we can handle things like:
>
> <beans ...>
> <jaxws:endpoint implementor="foo.bar.MyEndpoint"/>
> </beans>
>
> If we didn't want to be dependent on the Spring syntax, we could write a
> simple transformation that takes something like this format and
> converts it
> into Spring format:
>
> <endpoints>
> <endpoint implementor="foo.bar.MyEndpoint"/>
> </endpoint>
>
> Or whatever our current syntax is :-)
>
> - Dan
>
> On 2/4/07, Daniel Kulp <da...@iona.com> 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
>>
>
>
>
Re: Some change about the CXF Servlet
Posted by Oisin Hurley <oh...@iona.com>.
> If we didn't want to be dependent on the Spring syntax, we could
> write a
> simple transformation that takes something like this format and
> converts it
> into Spring format:
>
> <endpoints>
> <endpoint implementor="foo.bar.MyEndpoint"/>
> </endpoint>
>
> Or whatever our current syntax is :-)
A bit of flexibility there would be a Good Thing. I always feel sorry
for the
guys who have to massage the config files!
--oh
Re: Some change about the CXF Servlet
Posted by Dan Diephouse <da...@envoisolutions.com>.
We could leverage Spring here if we wnated to. I'm in the midst of writing a
Spring 2.0 handlers so we can handle things like:
<beans ...>
<jaxws:endpoint implementor="foo.bar.MyEndpoint"/>
</beans>
If we didn't want to be dependent on the Spring syntax, we could write a
simple transformation that takes something like this format and converts it
into Spring format:
<endpoints>
<endpoint implementor="foo.bar.MyEndpoint"/>
</endpoint>
Or whatever our current syntax is :-)
- Dan
On 2/4/07, Daniel Kulp <da...@iona.com> 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
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Question about imported element baseUri in XMLSchema
Posted by Jim Ma <ji...@iona.com>.
Hi ,
I use the following code to read the schemaA which import the schemaB and
print the base uri
for each schema element :
schemaCol.setBaseUri(schemaBaseUri);
schemaCol.setSchemaResolver (new XmlSchemaURIResolver());
XmlSchema xmlSchema = schemaCol.read(schemaA);
When I check the imported schema element base uri , I always get null.
Document[] docs = xmlSchema.getAllSchemas();
for (int i = 0; i < docs.length; i++) {
Element ele = docs[i].getDocumentElement();
System.out.println("--- getBaseUri---- " + ele.getBaseURI());
}
I always get null value .Is there anything I need to set for schemaCol ?
Thanks
Jim
Re: Some change about the CXF Servlet
Posted by Daniel Kulp <da...@iona.com>.
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