ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil Saldhana <>
Subject Re: Commit Privileges for Deepak (Re: Patch to remove jUDDI dependency from scout + patch to add ebxml support to scout)
Date Fri, 28 Oct 2005 19:14:45 GMT
Hi Fernando,

--- Fernando Nasser <> 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 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

> > 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message