juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fernando Nasser <fnas...@redhat.com>
Subject Re: Scout and jUDDI
Date Thu, 18 Aug 2005 13:56:23 GMT
Davanum Srinivas wrote:
> 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.
> 

It actually seems that the types used by jUDDI are unrelated (i.e. they 
should be) to the ones used by Scout (except for some JARX types to UDDI 
or ebXML mapping defined by the JAXR spec).

Scout and jUDDI should only communicate using SOAP messages and be 
completely independent code-wise.

So jUDDI can continue to use its own types (UDDI types?) and Scout can 
switch to the more independent XMLBeans, as it should not be using any 
UDDI or ebXML type internally.

Does that make sense?



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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Mime
View raw message