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:04:25 GMT
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

Mime
View raw message