Hi Anil,
Anil Saldhana wrote:
Also I am going to point out my opinion here:
a) The Scout code as it stands has been tested against
the J2EE 1.4 TCK for JAXR. It is not wise to add new
code that can break this, until we test the TCK.
This is true. The new code has been tested but against the J2EE TCK,
and not against the standlalone JAXR TCK.
b) Given a), as I said earlier, there needs to be a
framework for the xmlbeans port that is driven by a
seperate JAXRConnectionFactory. So it is upto the
user to use a connectionfactory (that is based on
juddi data types and has been JAXR J2EE 1.4 certified)
or use the one Deepak is gonna provide (based on xml
beans).
However, Geir has offered to test it ("That said, the XMLBeans version *must
also* pass the standalone JAXR TCK eventually. Once the work is done, let me
know and I'll test.").
If he tests it and it passes the standlalone one as well, would we need to keep
the implementation that uses the jUDDI types?
In the long run, lets unify the data model in
Scout. Then the issue of juddi data types/xmlbeans
will not arise. For now, lets keep it seperate.
What "unify the data model" means, exactly?
c) I am still not convinced that Scout should provide
level 1 capability, as there is this other open source
project (ebxmlrr) that provides a JAXR provider for
ebxml and ebxml registry.
OK< here is our problem: the AppServers cannot have two different JAXR in it.
If they load Scout, they have no access to ebXML registries. If they load
ebxmlrr (the JAXR provider) then they have no access to UDDI registries).
In fact, some applications need to access a UDDI register to find the exCXML
registry.
So if we include this ebxml
project in Scout, will we keep up with the bug fixes
that the ebxml community makes?
Not a big deal. Classpath and Classpathx are examples of large software
projects that have externally developed parts. As long as someome merges back
the improvemnts/bug fixes from time to time (e.g. the last official release of
the external project before a Scout release) everything goes well. Releases are
not that frequent (specially because they require TCK re-testing) so it won't be
a major burden to anyone.
And the benefit is a complete JAXR (UDDI + ebXML) implementation.
Regards,
Fernando
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
