You are viewing a plain text version of this content. The canonical link for it is here.
Posted to scout-dev@ws.apache.org by Anil Saldhana <an...@yahoo.com> on 2005/08/17 21:15:56 UTC
Re: Scout and jUDDI
Scout 0.5 release will be done the way it is.
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.
At Scout and jUDDI, we have always fostered pluggable
deployments.
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.
I will have to look at XMLBeans a bit further.
--- Fernando Nasser <fn...@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 <fn...@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
> <Gu...@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
---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org
Re: Scout and jUDDI
Posted by Steve Viens <sv...@gmail.com>.
>> Steve, I did not get your point about jUDDI does not
>> intend to support ebxml (apples and oranges. ;) ) I
>> presume you were talking about the juddi proxy.
Generally speaking, we've no intention supporting the ebXML API in the
proxy or the registry (in other words ... no plans for the jUDDI registry to
support ebXML requests).
Steve
On 8/18/05, Anil Saldhana <an...@yahoo.com> wrote:
>
> The goal for Scout is to be Level 0 Jaxr compliant.
> Lets get that to work satisfactorily. For that to
> happen, users have to use it in production.
>
> I do not see any immediate need for Apache Scout to be
> Level 1 compliant (read ebxml compliance). There is an
> open source implementation of ebxml (ebxmlrr) that
> provides JAXR capabilities also.
>
> We will propose Level 1 work in Scout when there are
> users asking for it.
>
> Scout/jUDDI combo passes the J2EE 1.4 TCK (JAXR
> Tests). This has been confirmed by seperate tests from
> Apache and JBoss.
>
> Steve, I did not get your point about jUDDI does not
> intend to support ebxml (apples and oranges. ;) ) I
> presume you were talking about the juddi proxy.
>
> --- Steve Viens <sv...@gmail.com> wrote:
>
> > Initially we developed Scout on top of jUDDI in
> > order to quickly produce a
> > type 0 JAXR provider. Type 0 (zero) providers
> > support accessing UDDI
> > registries only. The goal however is for Scout to
> > become a type 1 provider
> > which would include support for both UDDI and ebXML
> > registries.
> > As you would probably expect, there are no plans
> > for jUDDI to support
> > ebXML. If a move to an XMLBeans would enable Scout
> > to support both UDDI and
> > ebXML (a type 1 provider) then I'm in favor of a
> > move to XMLBeans and
> > eliminating Scout's dependency on jUDDI.
> > Steve
>
>
>
> ____________________________________________________
> Start your day with Yahoo! - make it your home page
> http://www.yahoo.com/r/hs
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
>
>
Re: Scout and jUDDI
Posted by Davanum Srinivas <da...@gmail.com>.
+1 :)
On 8/18/05, Anil Saldhana <an...@yahoo.com> wrote:
> A good step would be for Guillaume to submit his work
> involving JCA as a contribution to Apache so that we
> can use it in Apache Scout. Then the customer will
> have the choice of plug and play.
>
> --- Davanum Srinivas <da...@gmail.com> wrote:
>
> > Guillaume,
> >
> > If you sign up for the additional work :) then you
> > can have it :) :)
> > Seriously, am looking forward to improving both
> > projects AND looking
> > forward to more participation from redhat and
> > objectweb.
> >
> > -- dims
> >
> >
> > On 8/18/05, Steve Viens <sv...@gmail.com> wrote:
> > > Initially we developed Scout on top of jUDDI in
> > order to quickly produce a
> > > type 0 JAXR provider. Type 0 (zero) providers
> > support accessing UDDI
> > > registries only. The goal however is for Scout to
> > become a type 1 provider
> > > which would include support for both UDDI and
> > ebXML registries.
> > >
> > > As you would probably expect, there are no plans
> > for jUDDI to support ebXML.
> > > If a move to an XMLBeans would enable Scout to
> > support both UDDI and ebXML
> > > (a type 1 provider) then I'm in favor of a move to
> > XMLBeans and eliminating
> > > Scout's dependency on jUDDI.
> > >
> > > Steve
> > >
> > >
> > > On 8/18/05, Fernando Nasser <fn...@redhat.com>
> > wrote:
> > > > 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>
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: Scout and jUDDI
Posted by Anil Saldhana <an...@yahoo.com>.
A good step would be for Guillaume to submit his work
involving JCA as a contribution to Apache so that we
can use it in Apache Scout. Then the customer will
have the choice of plug and play.
--- Davanum Srinivas <da...@gmail.com> wrote:
> Guillaume,
>
> If you sign up for the additional work :) then you
> can have it :) :)
> Seriously, am looking forward to improving both
> projects AND looking
> forward to more participation from redhat and
> objectweb.
>
> -- dims
>
>
> On 8/18/05, Steve Viens <sv...@gmail.com> wrote:
> > Initially we developed Scout on top of jUDDI in
> order to quickly produce a
> > type 0 JAXR provider. Type 0 (zero) providers
> support accessing UDDI
> > registries only. The goal however is for Scout to
> become a type 1 provider
> > which would include support for both UDDI and
> ebXML registries.
> >
> > As you would probably expect, there are no plans
> for jUDDI to support ebXML.
> > If a move to an XMLBeans would enable Scout to
> support both UDDI and ebXML
> > (a type 1 provider) then I'm in favor of a move to
> XMLBeans and eliminating
> > Scout's dependency on jUDDI.
> >
> > Steve
> >
> >
> > On 8/18/05, Fernando Nasser <fn...@redhat.com>
> wrote:
> > > 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>
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Scout and jUDDI
Posted by Davanum Srinivas <da...@gmail.com>.
Guillaume,
If you sign up for the additional work :) then you can have it :) :)
Seriously, am looking forward to improving both projects AND looking
forward to more participation from redhat and objectweb.
-- dims
On 8/18/05, Steve Viens <sv...@gmail.com> wrote:
> Initially we developed Scout on top of jUDDI in order to quickly produce a
> type 0 JAXR provider. Type 0 (zero) providers support accessing UDDI
> registries only. The goal however is for Scout to become a type 1 provider
> which would include support for both UDDI and ebXML registries.
>
> As you would probably expect, there are no plans for jUDDI to support ebXML.
> If a move to an XMLBeans would enable Scout to support both UDDI and ebXML
> (a type 1 provider) then I'm in favor of a move to XMLBeans and eliminating
> Scout's dependency on jUDDI.
>
> Steve
>
>
> On 8/18/05, Fernando Nasser <fn...@redhat.com> wrote:
> > 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
> > >>>>
> > >>>><Gu...@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
> >
>
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: Scout and jUDDI
Posted by Anil Saldhana <an...@yahoo.com>.
The goal for Scout is to be Level 0 Jaxr compliant.
Lets get that to work satisfactorily. For that to
happen, users have to use it in production.
I do not see any immediate need for Apache Scout to be
Level 1 compliant (read ebxml compliance). There is an
open source implementation of ebxml (ebxmlrr) that
provides JAXR capabilities also.
We will propose Level 1 work in Scout when there are
users asking for it.
Scout/jUDDI combo passes the J2EE 1.4 TCK (JAXR
Tests). This has been confirmed by seperate tests from
Apache and JBoss.
Steve, I did not get your point about jUDDI does not
intend to support ebxml (apples and oranges. ;) ) I
presume you were talking about the juddi proxy.
--- Steve Viens <sv...@gmail.com> wrote:
> Initially we developed Scout on top of jUDDI in
> order to quickly produce a
> type 0 JAXR provider. Type 0 (zero) providers
> support accessing UDDI
> registries only. The goal however is for Scout to
> become a type 1 provider
> which would include support for both UDDI and ebXML
> registries.
> As you would probably expect, there are no plans
> for jUDDI to support
> ebXML. If a move to an XMLBeans would enable Scout
> to support both UDDI and
> ebXML (a type 1 provider) then I'm in favor of a
> move to XMLBeans and
> eliminating Scout's dependency on jUDDI.
> Steve
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org
Re: Scout and jUDDI
Posted by Anil Saldhana <an...@yahoo.com>.
The goal for Scout is to be Level 0 Jaxr compliant.
Lets get that to work satisfactorily. For that to
happen, users have to use it in production.
I do not see any immediate need for Apache Scout to be
Level 1 compliant (read ebxml compliance). There is an
open source implementation of ebxml (ebxmlrr) that
provides JAXR capabilities also.
We will propose Level 1 work in Scout when there are
users asking for it.
Scout/jUDDI combo passes the J2EE 1.4 TCK (JAXR
Tests). This has been confirmed by seperate tests from
Apache and JBoss.
Steve, I did not get your point about jUDDI does not
intend to support ebxml (apples and oranges. ;) ) I
presume you were talking about the juddi proxy.
--- Steve Viens <sv...@gmail.com> wrote:
> Initially we developed Scout on top of jUDDI in
> order to quickly produce a
> type 0 JAXR provider. Type 0 (zero) providers
> support accessing UDDI
> registries only. The goal however is for Scout to
> become a type 1 provider
> which would include support for both UDDI and ebXML
> registries.
> As you would probably expect, there are no plans
> for jUDDI to support
> ebXML. If a move to an XMLBeans would enable Scout
> to support both UDDI and
> ebXML (a type 1 provider) then I'm in favor of a
> move to XMLBeans and
> eliminating Scout's dependency on jUDDI.
> Steve
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
Re: Scout and jUDDI
Posted by Steve Viens <sv...@gmail.com>.
Initially we developed Scout on top of jUDDI in order to quickly produce a
type 0 JAXR provider. Type 0 (zero) providers support accessing UDDI
registries only. The goal however is for Scout to become a type 1 provider
which would include support for both UDDI and ebXML registries.
As you would probably expect, there are no plans for jUDDI to support
ebXML. If a move to an XMLBeans would enable Scout to support both UDDI and
ebXML (a type 1 provider) then I'm in favor of a move to XMLBeans and
eliminating Scout's dependency on jUDDI.
Steve
On 8/18/05, Fernando Nasser <fn...@redhat.com> wrote:
> 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 <fn...@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 <fn...@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 <fn...@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
> >>>>
> >>>><Gu...@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
>
Re: Scout and jUDDI
Posted by Fernando Nasser <fn...@redhat.com>.
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 <fn...@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 <fn...@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 <fn...@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
>>>>
>>>><Gu...@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
Re: Scout and jUDDI
Posted by Davanum Srinivas <da...@gmail.com>.
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 <fn...@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 <fn...@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 <fn...@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
> >>
> >><Gu...@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
Re: Scout and jUDDI
Posted by Steve Viens <sv...@gmail.com>.
My apologies for not jumping in on this conversation earlier.
It's unlikely that we'll attempt to move jUDDI to use XMLBeans anytime soon
though I think it's an interesting idea.
If classloading and the jUDDI dependencies is the driving force behind this
issue can't this be addressed by packaging jUDDI into different jars. I'm
95% certain that the jUDDI classes which Scout leverages (datatypes and
handlers mostly) do not have any dependencies outside of the standard java
packages (java.**) and W3C packages (org.w3c.**). If jUDDI is split into a
juddi_proxy.jar and a juddi_registry.jar (as it once was) then Scout would
only require the much smaller and semi-independent juddi_proxy.jar which
would contain only datatypes and handlers.
Just my two cents ... I'm not against the XMLBeans option just want to
assist in finding the right solution with the least effort and impact.
Steve
On 8/18/05, Fernando Nasser <fn...@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 <fn...@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 <fn...@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
> >>
> >><Gu...@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
>
Re: Scout and jUDDI
Posted by Davanum Srinivas <da...@gmail.com>.
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 <fn...@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 <fn...@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 <fn...@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
> >>
> >><Gu...@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
Re: Scout and jUDDI
Posted by Fernando Nasser <fn...@redhat.com>.
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 <fn...@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 <fn...@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
>>
>><Gu...@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