On Oct 28, 2005, at 3:14 PM, Anil Saldhana wrote:
Hi Fernando,
--- Fernando Nasser <[EMAIL PROTECTED]> wrote:
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.
I am not sure there is a standalone TCK for JAXR.
There is. We fail right now because of one feature not required by
J2EE. Hence we released v0.5, not 1.0
geir
There are large number of JAXR tests in the TCK for
J2EE 1.4. That is what I was referring to. Since you
guys have done the J2EE 1.4 tck, lets bring the stuff
in.
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?
Just one model that replaces the need for either juddi
data types or xmlbeans. It will only be Scout data
types for uddi. This is good because it will remove
the dependency on both juddi data types and xmlbeans.
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.
Ok, I see the point. If RedHat has resources to help
out with maintaining the ebxml stuff in Scout, I have
no worries.
Also I would like to point out that we need to
implement one last feature - "Asynchoronous Registry
Queries" to claim Jaxr 1.0 compliance. Hence we have
just done a v0.5 release of Scout, that passes the
J2EE 1.4 TCK (JAXR Section).
All on the same page? Happy weekend everyone.
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
