ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: Scout and jUDDI
Date Thu, 18 Aug 2005 13:42:01 GMT
Fernando,

Please include everyone's view point. If people who use juddi want to
use scout they should not have to include xmlbeans jars (EXACTLY the
way you don't want to use juddi jars). So best case scenario here is
to have a pluggable way in scout to do either xmlbeans or juddi types.
No one is going to complain that way. Please let me know if this is ok
for you.

-- dims

On 8/18/05, Fernando Nasser <fnasser@redhat.com> wrote:
> Hi Anil,
> 
> Anil Saldhana wrote:
> > Scout 0.5 release will be done the way it is.
> >
> 
> 0.5?
> 
> But your trunk/etc/project.xml already says
> 
> <currentVersion>1.0-SNAPSHOT</currentVersion>
> 
> As a result Apache Geronimo and ObjectWeb JOnAS, as well as Red Hat
> RHAPS and the JPackage.org RPM of Scout have all been labeled
> 1.0-SNAPSHOT (+date).
> 
> Going back to anything less then 1.0 now will break everybody's
> dependency checks.
> 
> Can't you continue to use 1.0-SNAPSHOT until you are ready for 1.0?
> 
> 
> > Once we add the asynchronous feature  required by the
> > JAXR 1.0 spec, we will do the Scout 1.0 release.
> >
> > Before we do the 1.0 release, we can see if there is
> > really any major incentive in removing the juddi data
> > types and bringing in XMLBeans.
> >
> 
> A major incentive: not bringing the juddi jar into the classloader space
> of anyone who wants to use Scout, perhaps even with some other Directory
> service different from jUDDI.
> 
> I was talking to Guillaume on irc and we think that a complete
> separation between Scout and jUDDI would be ideal.
> 
> 
> > At Scout and jUDDI, we have always fostered pluggable
> > deployments.
> >
> 
> But in this specific case, there doesn't seem to be any advantage at all
> in providing pluggable _internal_ types.
> 
> 
> > Using juddi data types is an internal implementation
> > detail of Scout.  So there are no issues with using
> > XMLBeans as an internal implementation detail. But we
> > need to investigate and test.
> >
> 
> Right.  We would be willing to help changing the types if everyone is in
> accordance with that.
> 
> 
> > I will have to look at XMLBeans a bit further.
> >
> 
> Thank you.
> 
> 
> Best regards,
> Fernando
> 
> 
> 
> 
> > --- Fernando Nasser <fnasser@redhat.com> wrote:
> >
> >
> >>Davanum Srinivas wrote:
> >>
> >>>Fernando,
> >>>
> >>>then folks who primarily use juddi and want to use
> >>
> >>scout on the client
> >>
> >>>will have one less library to deal with :)
> >>>
> >>
> >>Are you saying that you agree with using XMLBeans
> >>and dropping the jUDDI
> >>types (on both sides, Scout and jUDDI of course)?
> >>
> >>
> >>
> >>
> >>>-- dims
> >>>
> >>>On 8/17/05, Fernando Nasser <fnasser@redhat.com>
> >>
> >>wrote:
> >>
> >>>>Dims,
> >>>>
> >>>>I may be missing something because I don't know
> >>
> >>all the details, so
> >>
> >>>>please forgive me if it is a silly question.
> >>>>
> >>>>If we have APL more or less standard types from
> >>
> >>Apache XMLBeans, why do
> >>
> >>>>we need to have the option of using jUDDI own
> >>
> >>types?
> >>
> >>>>Why not just drop the non-standard jUDDI types and
> >>
> >>plainly switch
> >>
> >>>>everything to use XMLBeans only ( a "de facto"
> >>
> >>standard)?
> >>
> >>>>Best regards,
> >>>>Fernando
> >>>>
> >>>>
> >>>>
> >>>>Davanum Srinivas wrote:
> >>>>
> >>>>
> >>>>>As long as it's pluggable (use XMLBeans OR
> >>
> >>jUDDI), Am ok.
> >>
> >>>>>thanks,
> >>>>>dims
> >>>>>
> >>>>>On 8/12/05, Guillaume Sauthier
> >>
> >><Guillaume.Sauthier@objectweb.org> wrote:
> >>
> >>>>>
> >>>>>>Hi guys
> >>>>>>
> >>>>>>We want to integrate Scout in JOnAS as a
> >>
> >>replacement for the JAXR
> >>
> >>>>>>Reference Implementation.
> >>>>>>With Scout we can get ride of JAXB-RI too (used
> >>
> >>by JAXR-RI) and use OSS :)
> >>
> >>>>>>Scout has been very easily embed in JOnAS as a
> >>
> >>ResourceAdapter and seems
> >>
> >>>>>>to work very well, thanks to your hard work: )
> >>>>>>
> >>>>>>We can see that Scout depends on jUDDI, and
> >>
> >>jUDDI depends on many
> >>
> >>>>>>jakarta commons libs.
> >>>>>>
> >>>>>>Given the JOnAS ClassLoader architecture, the
> >>
> >>Scout RA (and all
> >>
> >>>>>>depending libs : scout, juddi, common-*, ...)
> >>
> >>will be loaded in a
> >>
> >>>>>>'commons' ClassLoader, this is a top level
> >>
> >>Loader.
> >>
> >>>>>>So, if a user package his/her application/webapp
> >>
> >>with a lib already
> >>
> >>>>>>provided by JOnAS (version can differ) there can
> >>
> >>be a conflict!
> >>
> >>>>>>More, if a user want to change the jUDDI
> >>
> >>(webapp) version, he can't do
> >>
> >>>>>>that (classes in top level loader are always
> >>
> >>loaded first) !
> >>
> >>>>>>As we want to interfere a minimum with the
> >>
> >>classes packaged in our
> >>
> >>>>>>user's application, in order to avoid conflicts,
> >>
> >>we want to remove the
> >>
> >>>>>>dependency on jUDDI.
> >>>>>>
> >>>>>>To do this, we will have to rewrite some kind of
> >>
> >>RegistryProxy, avoid
> >>
> >>>>>>the use of jUDDI's handlers and datatypes, ...
> >>>>>>We thought to use xmlbeans as a replacement for
> >>
> >>UDDI datatypes
> >>
> >>>>>>I want to know what do you think of this
> >>
> >>proposal ?
> >>
> >>>>>>I think it can be useful for geronimo guys too
> >>
> >>(and for the same
> >>
> >>>>>>classloader reasons).
> >>>>>>
> >>>>>>Regards
> >>>>>>Guillaume
> >>>>>>
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> 
> --
> Fernando Nasser
> Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
> 2323 Yonge Street, Suite #300
> Toronto, Ontario   M4P 2C9
> 


-- 
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform

---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Mime
View raw message