ws-scout-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@apache.org>
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:49:36 GMT

On Oct 28, 2005, at 3:14 PM, Anil Saldhana wrote:

> Hi Fernando,
>
> --- Fernando Nasser <fnasser@redhat.com> 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: scout-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: scout-dev-help@ws.apache.org
>
>

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: scout-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: scout-dev-help@ws.apache.org


Mime
View raw message