On Wed, Sep 25, 2013 at 1:37 PM, Kasun Gajasinghe <[email protected]> wrote:
> > > > On Wed, Sep 25, 2013 at 1:28 PM, Sagara Gunathunga <[email protected]>wrote: > >> >> >> >> On Wed, Sep 25, 2013 at 12:46 AM, Kasun Gajasinghe <[email protected]>wrote: >> >>> Hi, >>> >>> For the JAX-WS and JAX-RS service discovery to work properly, we need >>> access to the registry (to store unique id of each service), and the >>> AxisConfiguration (to get the Discovery url of the (super)tenant) etc. So, >>> the cxf-ws-discovery library needs jars in repository/components/plugins/ >>> in its classpath. It also need CXF libraries (under lib/runtimes/cxf) since >>> the ws-discovery is performed by registering a CXF lifecycle listener. >>> >>> But we are keeping the libraries under the said two folders independent >>> of each other to provide better classloading environment for webapps. The >>> cxf-ws-discovery jar should probably go under lib/runtimes/cxf. So, what's >>> the best way for it to depend on libraries from plugins/? >>> If we duplicate the jars, the distribution size will grow considerably. >>> >> >> This is a very common requirement for lot of extended CXF features, let's >> not try to make it more complex by introducing something new instead let's >> use existing concepts. >> >> 1. Put cxf-ws-discovery jar and what ever the custom code we write for >> above feature into "lib/runtimes/cxf" >> >> 2. If a CXF app owner want to use WS-Discovery with standard way there is >> nothing new required. >> >> 3. If a CXF app owner want to use WS-Discovery on WSO2 Registry (Smart >> endpoint ) then he should also need to add "Carbon"as a classlaoder runtime >> environment in addition to "CXF". >> >> It seems we can't use this way. Since this is a CXF lifecycle listener, all the CXF services will go through this listener. So, all the CXF-based webapps will have to use Carbon runtime.. Further it seems like the only detail we can get from the org.apache.cxf.endpoint.Server object is the server bean url context defined in cxf-servlet.xml. for ex. /customers. We do not have access to webapp name too as I've seen. We can get the ServerURL from carbon ui but we need the webapp name. For that, we might have to use a Tomcat Context lifecycle listener. [1] [1] http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Lifecycle_Listeners Thanks, KasunG > > +1.. This looks like a clean approach. Will try this out. > > Thanks, > KasunG > > >> Thanks ! >> >>> >>> >>> -- >>> *Kasun Gajasinghe* >>> Software Engineer; >>> WSO2 Inc.; http://wso2.com >>> >>> >>> , >>> *email: **kasung AT spamfree wso2.com >>> >>> >>> ** cell: **+94 (77) 678-0813* >>> *linked-in: *http://lk.linkedin.com/in/gajasinghe >>> >>> >>> * >>> * >>> *blog: **http://kasunbg.org* <http://kasunbg.org> >>> >>> >>> * >>> twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> >>> >>> >>> * >>> * >>> >> >> >> >> -- >> Sagara Gunathunga >> >> Senior Technical Lead; WSO2, Inc.; http://wso2.com >> V.P Apache Web Services; http://ws.apache.org/ >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> >> > > > -- > *Kasun Gajasinghe* > Software Engineer; > WSO2 Inc.; http://wso2.com > > > , > *email: **kasung AT spamfree wso2.com > > > ** cell: **+94 (77) 678-0813* > *linked-in: *http://lk.linkedin.com/in/gajasinghe > > > * > * > *blog: **http://kasunbg.org* <http://kasunbg.org> > > > * > twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> > > > * > * > -- *Kasun Gajasinghe* Software Engineer; WSO2 Inc.; http://wso2.com , *email: **kasung AT spamfree wso2.com ** cell: **+94 (77) 678-0813* *linked-in: *http://lk.linkedin.com/in/gajasinghe * * *blog: **http://kasunbg.org* <http://kasunbg.org> * twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg> * *
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
