You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Sean Mullan <Se...@Sun.COM> on 2005/07/21 21:02:36 UTC
JSR 105 integration plan
I'm happy to announce that we're (IBM & Sun) finally ready to contribute
the JSR 105 [1] (Java XML DSig) implementation back to Apache. As you
might know the JSR 105 reference implementation is largely based on the
Apache Java XMLSec implementation, and we'll be contributing the API and
additional code that was necessary to retrofit Apache's implementation.
I have some ideas about the best way to integrate this code, and I would
like to share that with you and see if you have any other advice or
suggestions.
I think a two phased approach is best. Phase 1 would consist of a
release in the next 1-3 months and phase 2 would be a longer term
release in the next 6 months.
The purpose of phase 1 is to release JSR 105 as quickly as possible so
the Apache XMLSec community can start using and working on it in the
near term. The current JSR 105 implementation works pretty much
out-of-the-box with XMLSec v1.2.1 with minimal changes to the Apache
source code. This phase 1 release would not break API compatibility and
allow developers to migrate to JSR 105 at their own speed. For phase 1,
I think a 1.4 release makes most sense, since I know Raul is close to
releasing a 1.3 bug-fix/performance improvement release.
Phase 2 would be a longer-term release and would consist of removing
redundant code and APIs and generally making a cleaner fit beneath the
JSR 105 APIs. This means that API compatibility would be broken so it
would have to be a 2.0 release.
What do people feel about this plan?
Thanks,
Sean
[1]: http://jcp.org/en/jsr/detail?id=105
Re: JSR 105 integration plan
Posted by Sean Mullan <Se...@Sun.COM>.
Raul Benito wrote:
> I have something implemented for SAX as you can see bugzilla entry
> http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=32657 .
>
> And I have take a look for JSR105, but i think the tree API is not
> 100% applicable to
> for example one pass implementations.
> In this cases, there should be a way in the verification API, to tell
> when the element to digest begins and what transforms apply.
> In case enveloping signatures this information can be stored from there.
> But in case of enveloped signatures, this information should be passed
> by the caller, if he/she wants a one pass verification (i.e. no
> backstore/replay mechanism; store every event/node to replay it latter
> when all information has been gotten).
>
> I don't know how to handle this case in JSR105, perhaps it is a way or
> perhaps it should extended to this cases.
>
> What do you think?
Right, it will probably need to be extended in a future revision to add
support for one-pass implementations. But that's ok we can add
non-standard APIs for now and work it thru the JCP later. I think what
is more important is seeing if the 105 API is flexible enough to be
extended to handle your implementation.
Thanks,
Sean
Re: JSR 105 integration plan
Posted by Raul Benito <ra...@gmail.com>.
I have something implemented for SAX as you can see bugzilla entry
http://issues.eu.apache.org/bugzilla/show_bug.cgi?id=32657 .
And I have take a look for JSR105, but i think the tree API is not
100% applicable to
for example one pass implementations.
In this cases, there should be a way in the verification API, to tell
when the element to digest begins and what transforms apply.
In case enveloping signatures this information can be stored from there.
But in case of enveloped signatures, this information should be passed
by the caller, if he/she wants a one pass verification (i.e. no
backstore/replay mechanism; store every event/node to replay it latter
when all information has been gotten).
I don't know how to handle this case in JSR105, perhaps it is a way or
perhaps it should extended to this cases.
What do you think?
On 7/22/05, Sean Mullan <Se...@sun.com> wrote:
> Raul Benito wrote:
> > Also, +1 for me. I think is a good plan.
> > To have a bugfix CVS branch with 1.x API and JSR105.
> > And 2.x JSR105 only branch.
> >
> > Really good.
> >
> > Regarding the 1,3 version. I was thinking of adding stax/sax API but
> > perhaps it is better to concentrate in JSR105.
>
> Do you have any of the stax/sax API done yet? It's possible it may be
> adapted to work as a JSR 105 provider (JSR 105 is designed to be a DOM
> independent API).
>
> --Sean
>
> >
> > Regards,
> >
> > On 7/21/05, Davanum Srinivas <da...@gmail.com> wrote:
> >
> >>Awesome. Am all for it. +1 to 1.4 release with JSR 105 support.
> >>
> >>-- dims
> >>
> >>On 7/21/05, Sean Mullan <Se...@sun.com> wrote:
> >>
> >>>I'm happy to announce that we're (IBM & Sun) finally ready to contribute
> >>>the JSR 105 [1] (Java XML DSig) implementation back to Apache. As you
> >>>might know the JSR 105 reference implementation is largely based on the
> >>>Apache Java XMLSec implementation, and we'll be contributing the API and
> >>>additional code that was necessary to retrofit Apache's implementation.
> >>>
> >>>I have some ideas about the best way to integrate this code, and I would
> >>>like to share that with you and see if you have any other advice or
> >>>suggestions.
> >>>
> >>>I think a two phased approach is best. Phase 1 would consist of a
> >>>release in the next 1-3 months and phase 2 would be a longer term
> >>>release in the next 6 months.
> >>>
> >>>The purpose of phase 1 is to release JSR 105 as quickly as possible so
> >>>the Apache XMLSec community can start using and working on it in the
> >>>near term. The current JSR 105 implementation works pretty much
> >>>out-of-the-box with XMLSec v1.2.1 with minimal changes to the Apache
> >>>source code. This phase 1 release would not break API compatibility and
> >>>allow developers to migrate to JSR 105 at their own speed. For phase 1,
> >>>I think a 1.4 release makes most sense, since I know Raul is close to
> >>>releasing a 1.3 bug-fix/performance improvement release.
> >>>
> >>>Phase 2 would be a longer-term release and would consist of removing
> >>>redundant code and APIs and generally making a cleaner fit beneath the
> >>>JSR 105 APIs. This means that API compatibility would be broken so it
> >>>would have to be a 2.0 release.
> >>>
> >>>What do people feel about this plan?
> >>>
> >>>Thanks,
> >>>Sean
> >>>
> >>>[1]: http://jcp.org/en/jsr/detail?id=105
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>--
> >>Davanum Srinivas -http://blogs.cocoondev.org/dims/
> >>
> >
> >
> >
>
>
--
http://r-bg.com
Re: JSR 105 integration plan
Posted by Sean Mullan <Se...@Sun.COM>.
Raul Benito wrote:
> Also, +1 for me. I think is a good plan.
> To have a bugfix CVS branch with 1.x API and JSR105.
> And 2.x JSR105 only branch.
>
> Really good.
>
> Regarding the 1,3 version. I was thinking of adding stax/sax API but
> perhaps it is better to concentrate in JSR105.
Do you have any of the stax/sax API done yet? It's possible it may be
adapted to work as a JSR 105 provider (JSR 105 is designed to be a DOM
independent API).
--Sean
>
> Regards,
>
> On 7/21/05, Davanum Srinivas <da...@gmail.com> wrote:
>
>>Awesome. Am all for it. +1 to 1.4 release with JSR 105 support.
>>
>>-- dims
>>
>>On 7/21/05, Sean Mullan <Se...@sun.com> wrote:
>>
>>>I'm happy to announce that we're (IBM & Sun) finally ready to contribute
>>>the JSR 105 [1] (Java XML DSig) implementation back to Apache. As you
>>>might know the JSR 105 reference implementation is largely based on the
>>>Apache Java XMLSec implementation, and we'll be contributing the API and
>>>additional code that was necessary to retrofit Apache's implementation.
>>>
>>>I have some ideas about the best way to integrate this code, and I would
>>>like to share that with you and see if you have any other advice or
>>>suggestions.
>>>
>>>I think a two phased approach is best. Phase 1 would consist of a
>>>release in the next 1-3 months and phase 2 would be a longer term
>>>release in the next 6 months.
>>>
>>>The purpose of phase 1 is to release JSR 105 as quickly as possible so
>>>the Apache XMLSec community can start using and working on it in the
>>>near term. The current JSR 105 implementation works pretty much
>>>out-of-the-box with XMLSec v1.2.1 with minimal changes to the Apache
>>>source code. This phase 1 release would not break API compatibility and
>>>allow developers to migrate to JSR 105 at their own speed. For phase 1,
>>>I think a 1.4 release makes most sense, since I know Raul is close to
>>>releasing a 1.3 bug-fix/performance improvement release.
>>>
>>>Phase 2 would be a longer-term release and would consist of removing
>>>redundant code and APIs and generally making a cleaner fit beneath the
>>>JSR 105 APIs. This means that API compatibility would be broken so it
>>>would have to be a 2.0 release.
>>>
>>>What do people feel about this plan?
>>>
>>>Thanks,
>>>Sean
>>>
>>>[1]: http://jcp.org/en/jsr/detail?id=105
>>>
>>>
>>>
>>>
>>>
>>
>>
>>--
>>Davanum Srinivas -http://blogs.cocoondev.org/dims/
>>
>
>
>
Re: JSR 105 integration plan
Posted by Raul Benito <ra...@gmail.com>.
Also, +1 for me. I think is a good plan.
To have a bugfix CVS branch with 1.x API and JSR105.
And 2.x JSR105 only branch.
Really good.
Regarding the 1,3 version. I was thinking of adding stax/sax API but
perhaps it is better to concentrate in JSR105.
Regards,
On 7/21/05, Davanum Srinivas <da...@gmail.com> wrote:
> Awesome. Am all for it. +1 to 1.4 release with JSR 105 support.
>
> -- dims
>
> On 7/21/05, Sean Mullan <Se...@sun.com> wrote:
> > I'm happy to announce that we're (IBM & Sun) finally ready to contribute
> > the JSR 105 [1] (Java XML DSig) implementation back to Apache. As you
> > might know the JSR 105 reference implementation is largely based on the
> > Apache Java XMLSec implementation, and we'll be contributing the API and
> > additional code that was necessary to retrofit Apache's implementation.
> >
> > I have some ideas about the best way to integrate this code, and I would
> > like to share that with you and see if you have any other advice or
> > suggestions.
> >
> > I think a two phased approach is best. Phase 1 would consist of a
> > release in the next 1-3 months and phase 2 would be a longer term
> > release in the next 6 months.
> >
> > The purpose of phase 1 is to release JSR 105 as quickly as possible so
> > the Apache XMLSec community can start using and working on it in the
> > near term. The current JSR 105 implementation works pretty much
> > out-of-the-box with XMLSec v1.2.1 with minimal changes to the Apache
> > source code. This phase 1 release would not break API compatibility and
> > allow developers to migrate to JSR 105 at their own speed. For phase 1,
> > I think a 1.4 release makes most sense, since I know Raul is close to
> > releasing a 1.3 bug-fix/performance improvement release.
> >
> > Phase 2 would be a longer-term release and would consist of removing
> > redundant code and APIs and generally making a cleaner fit beneath the
> > JSR 105 APIs. This means that API compatibility would be broken so it
> > would have to be a 2.0 release.
> >
> > What do people feel about this plan?
> >
> > Thanks,
> > Sean
> >
> > [1]: http://jcp.org/en/jsr/detail?id=105
> >
> >
> >
> >
> >
>
>
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>
--
http://r-bg.com
Re: JSR 105 integration plan
Posted by Davanum Srinivas <da...@gmail.com>.
Awesome. Am all for it. +1 to 1.4 release with JSR 105 support.
-- dims
On 7/21/05, Sean Mullan <Se...@sun.com> wrote:
> I'm happy to announce that we're (IBM & Sun) finally ready to contribute
> the JSR 105 [1] (Java XML DSig) implementation back to Apache. As you
> might know the JSR 105 reference implementation is largely based on the
> Apache Java XMLSec implementation, and we'll be contributing the API and
> additional code that was necessary to retrofit Apache's implementation.
>
> I have some ideas about the best way to integrate this code, and I would
> like to share that with you and see if you have any other advice or
> suggestions.
>
> I think a two phased approach is best. Phase 1 would consist of a
> release in the next 1-3 months and phase 2 would be a longer term
> release in the next 6 months.
>
> The purpose of phase 1 is to release JSR 105 as quickly as possible so
> the Apache XMLSec community can start using and working on it in the
> near term. The current JSR 105 implementation works pretty much
> out-of-the-box with XMLSec v1.2.1 with minimal changes to the Apache
> source code. This phase 1 release would not break API compatibility and
> allow developers to migrate to JSR 105 at their own speed. For phase 1,
> I think a 1.4 release makes most sense, since I know Raul is close to
> releasing a 1.3 bug-fix/performance improvement release.
>
> Phase 2 would be a longer-term release and would consist of removing
> redundant code and APIs and generally making a cleaner fit beneath the
> JSR 105 APIs. This means that API compatibility would be broken so it
> would have to be a 2.0 release.
>
> What do people feel about this plan?
>
> Thanks,
> Sean
>
> [1]: http://jcp.org/en/jsr/detail?id=105
>
>
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: JSR 105 integration plan
Posted by Ron Forrester <it...@gmail.com>.
On 7/21/05, Sean Mullan <Se...@sun.com> wrote:
> Phase 2 would be a longer-term release and would consist of removing
> redundant code and APIs and generally making a cleaner fit beneath the
> JSR 105 APIs. This means that API compatibility would be broken so it
> would have to be a 2.0 release.
>
> What do people feel about this plan?
Although I am a relatively new user of Apache xmlsec, I think this is
a great plan, and I look forward to migrating to the standard.
Thanks,
--
rjf&