Return-Path: 
 <cxf-dev-return-2109-apmail-incubator-cxf-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-cxf-dev-archive@locus.apache.org
Received: (qmail 75177 invoked from network); 6 Feb 2007 17:51:17 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 6 Feb 2007 17:51:17 -0000
Received: (qmail 85008 invoked by uid 500); 6 Feb 2007 17:51:23 -0000
Delivered-To: apmail-incubator-cxf-dev-archive@incubator.apache.org
Received: (qmail 84960 invoked by uid 500); 6 Feb 2007 17:51:23 -0000
Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:cxf-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:cxf-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:cxf-dev@incubator.apache.org>
List-Id: <cxf-dev.incubator.apache.org>
Reply-To: cxf-dev@incubator.apache.org
Delivered-To: mailing list cxf-dev@incubator.apache.org
Received: (qmail 84951 invoked by uid 99); 6 Feb 2007 17:51:23 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 09:51:23 -0800
X-ASF-Spam-Status: No, hits=2.0 required=10.0
	tests=HTML_MESSAGE
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [64.233.184.238] (HELO wr-out-0506.google.com) (64.233.184.238)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 09:51:12 -0800
Received: by wr-out-0506.google.com with SMTP id i7so1645568wra
        for <cxf-dev@incubator.apache.org>;
 Tue, 06 Feb 2007 09:50:51 -0800 (PST)
Received: by 10.90.73.3 with SMTP id v3mr10850586aga.1170784250805;
        Tue, 06 Feb 2007 09:50:50 -0800 (PST)
Received: by 10.90.67.9 with HTTP; Tue, 6 Feb 2007 09:50:50 -0800 (PST)
Message-ID: <7b774c950702060950k4911b0c5o8296625003b72d53@mail.gmail.com>
Date: Tue, 6 Feb 2007 12:50:50 -0500
From: "Dan Diephouse" <dan@envoisolutions.com>
To: cxf-dev@incubator.apache.org
Subject: Re: Some change about the CXF Servlet
Cc: "Willem Jiang" <ning.jiang@iona.com>
In-Reply-To: <200702061046.47732.daniel.kulp@iona.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_8152_6284596.1170784250751"
References: <45C68801.8020500@iona.com>
	 <200702051135.49105.daniel.kulp@iona.com> <45C81748.6020506@iona.com>
	 <200702061046.47732.daniel.kulp@iona.com>
X-Virus-Checked: Checked by ClamAV on apache.org

------=_Part_8152_6284596.1170784250751
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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> 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

------=_Part_8152_6284596.1170784250751--