Anil Saldhana wrote:
Hi Guillaume and Deepak,
can you guys try to resolve the CL issues exist in JonAS if we use
juddi proxy for the data types (without the package name change)?
This will simplify things and maintain status quo of v0.5.
I think the package name change is really needed (it is the fastest
solution, IMO) for us.
But I think that we can do it during the JOnAS packaging process. Even,
if it should be simpler if scout could make that change itself, and
everyone will benefits from that ...
I will ask Steve Viens about juddi proxy and a seperate datatypes jar.
Great thanks
Regarding ebxml integration, ebxmlrr has a JAXR implementation. What
we need to do is allow our ConnectionFactory to return an ebxmlrr
connection. We will do that after we do Scoutv1.0
I am "no" to castor also. Trust me, if Scout is independent of any xml
binding libraries (xmlbeans, castor,JiBX etc etc), it will be very
integratable.
Cheers,
Anil
*/Deepak Bhole <[EMAIL PROTECTED]>/* wrote:
Hi Guillaume,
To answer a couple of your queries:
On Fri, 2006-03-17 at 10:59 +0100, Guillaume Sauthie r wrote:
> Anil Saldhana wrote:
>
> > The moral of the story is:
> > a) I had asked for the XMLBeans data types for juddi to be
integrated
> > into Scout. Not to bring in a dependency on xmlbeans.
>
> AFAIK, If you're using using XMLBeans, you add a compile time
deps (when
> you geenrate your object classes) AND a runtime deps (because
theses
> generated objects needs XMLBeans Runtime - XMLObject ?).
>
Right. xmlbeans is needed at run time as well, since it handles
serialization/deserialization and other generic things (e.g
validation).
>
> And the support of ebXML ?
> Is it based on XMLBeans too ?
> If this is the case, dropping xmlbeans, will drop ebxml too :'(
>
ebXMLrr uses castor, not xmlbeans. But it too will be needed at run
time.
> >
> > Juddi data types are stable and do not change. What is the
guarantee
> > that xmlbeans will generate the right types over time? There
will be
> > bugs in either juddi data types or xmlbeans generated types
and we are
> > here to fix them.
>
> True, we're here to correct bugs :)
> Anyway, I still think that copying java classes into Scout is
not the
> right solution.
> Adding a dependency (and changing package name) is cleaner...
>
> >
> > JUddi has the juddi proxy jar which just contains the
datatypes and
> > the proxy code. Are you guys ok with that or you have CL
issues also
> > with that? If you are ok with that, then that is what we have in
> > Scout v0.5
>
> We're not OK with reusing juddi datatypes 'as is'.
> I think it's a good compromise to have a deps on juddi proxy.jar
AND
> changing the package name.
> So there is no code duplication, if there is a fix in juddi
datatypes,
> we just have to take the next version of the proxy.jar. package
names
> change should be integrated in the build process ...
>
> Guillaume
>
> >
> >
> > */Guillaume Sauthier /* wrote:
> >
> > So if I sum up :
> > * You don't want an XMLBeans dependency for Scout
> > * We don't want to use jUDDI datatypes 'as is' because of some
> > obscure
> > ClassLoader issue
> > * You propose to copy the jUDDI datatypes into Scout
> >
> > Here are my comments :
> > * XMLBeans integration is something started a long time ago... Why
> > didn't you have any reactions about that integration sooner ?
> > * Copying jUDDI datatypes as is (ie not changing package name)
> > will not
> > solve our ClassLoader issue
> > * If there is a fix in jUDDI datatypes (jUDDI seems pretty stable,
> > but a
> > bug can be found at anytime), Scout developpers has to manually
> > update
> > their own codebase. This is error prone :'(
> > * Moreover, that solution is not very elegant, don't you think ?
> > Seems
> > like "Quick and dirty" ...
> >
> > And my proposition :
> > * separate cleanly jUDDI datatypes from jUDDI (aka having a
separate
> > project ?)
> > * jUDDI w ill declare a dependency on juddi-datatypes.jar
> > * Scout can reuse that shared codebase if scout build process
> > includes
> > something like JarJar
(http://tonicsystems.com/products/jarjar/) that
> > will change package names from org.apache.juddi.datatypes to
> > org.apache.scout.uddi.v2
> > => So at runtime, Scout will use it's own repackaged classes,
> > resolving
> > our CloassLoader issue, their will be no deps on XMLBeans, and
> > there is
> > a clean separation between jUDDI, datatypes and Scout ...
> >
> > Notes :
> > JarJar is used in cglib to provide a cglib-nodep jar file for ASM
> > (suppress ClassLoader issues with ASM versionning)
> >
> > Thoughts ?
> >
> > Regards
> > Guillaume
> >
> > Anil Saldhana wrote:
> >
> > > As much as I like XMLBeans. Even though it is an Apache project
> > (good
> > > for us). But the XML Binding space is in flux now- JAXB is
the only
> > > standard that is available IMO. I do not want to introduce a
> > > dependence on a xml binding library into Scout.
> > >
> > > You can clearly s ee the introduction of xmlbeans library
> > dependence in
> > > Scout: *http://tinyurl.com/mp7r7
> > > *
> > > Scout is anyway required to carry the uddi types. So we may
as well
> > > have it borrowed from the juddi project. As per the additional
> > juddi
> > > stuff that gets pulled into Scout, it is still fine because we
> > remove
> > > the dependence on both juddi and xmlbeans. As we move forward,
> > we can
> > > remove the additional baggage.
> > >
> > > When we do uddiv3, we will have its datatypes in Scout - no
problem
> > > with that.
> > >
> > >
> >
Deepak
------------------------------------------------------------------------
Yahoo! Mail
Use Photomail
<http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=38867/*http://photomail.mail.yahoo.com>
to share photos without annoying attachments.
begin:vcard
fn:Guillaume Sauthier
n:Sauthier;Guillaume
org:<a href="http://www.objectweb.org";><img title="Objectweb" alt="Objectweb" border="0" src="http://www.objectweb.org/media/interface/logoow3.gif"; /></a> Open Source Middleware
adr:;;;;;;France
email;internet:[EMAIL PROTECTED]
title:<a href="http://jonas.objectweb.org";>JOnAS Application Server</a>
x-mozilla-html:FALSE
url:http://jonas.objectweb.org
version:2.1
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
![http://www.objectweb.org/media/interface/logoow3.gif"](http://www.objectweb.org/media/interface/logoow3.gif"){kind=link}