You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Daniel Kulp <dk...@apache.org> on 2009/06/15 16:49:59 UTC
Neethi 3.0
Some of you have noticed some discussions on WSCOMMONS-299. I've also been
thinking about some of those issues and I DID have a discussion with Glen
Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
With the comments and stuff on WSCOMMONS-299, it might be time to really start
it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
maintenance and start making trunk 3.0.
Things I'd like tackled for 3.0:
1) Java 5 - make the collections and everything typed. Use Enums where
appropriate, etc.... Basically, general cleanup. Also, I see that many
operations aren't threadsafe due to use of HashMap's with no synchronization.
Possibly fix those with ConcurrentHashMaps or similar.
2) Better support for the nested policies as described in WSCOMMONS-299.
3) Change the builders to use XMLStreamReader. The Policies use
XMLStreamWriter. For consistency, using the reader is preferred. This also
removes Axiom as a dependency making the requirement list smaller.
4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
back. CXF has a few utilities and such that would be good to push back and
then remove from CXF.
5) Once all of that is done, it would open up the door to allow some more
"common" Policies objects for standard policies. Some could be in Neethi
directly (things like policies objects for WS-Addressing assertions, mtom
stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
into Neethi or might be better in WSS4J. This could help eliminate a BUNCH
of duplicate code between users of Neethi, particularly CXF and Rampart.
(maybe if I keep pushing similar code down into commons, we can have a big
merger in the future. Acxfis 3? Maybe not. :-) )
6) Support for WS-Policy 1.5.
Anyway, if no one really objects to starting the 3.0 work, I'd like to create
the 2.x branch later this week. Thoughts?
BTW: This is also why I STRONGLY am in favor of Neethi staying in commons and
not going to an Axis2 TLP.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Let me clarify .. Rampart2 shows a potentially major issue in WSS4J/Rampart
- which is that it does policy validation *after* doing security processing,
giving a nice way to do a DoS attack.
I guess the issue with Rampart2 is its by design a layer of Axiom with its
own XML Security impl ... which is what gives it its performance (avoiding
the conversion to DOM for C14N and XMLSec processing in WSS4J). I'm not sure
how its possible to achieve good performance without avoiding XML Infoset
representation model conversion. That's why Rampart2 work included C14N, XML
Security and WS-Security stuff. It has ways to go in terms of finishing all
the stuff of course, but the approach has proven to deliver good results.
Sanjiva.
2009/6/16 Sanjiva Weerawarana <sa...@opensource.lk>
> Um I'm confused Nandana ... I thought our strategy is Rampart2, which *is*
> policy-aware. Why would we invest anything into WSS4J at this point?
>
> Sanjiva.
>
> 2009/6/16 Nandana Mihindukulasooriya <na...@gmail.com>
>
> +1, I also agree that Security Policy stuff should be ideally in WSS4J or
>> Neethi and eventually we should make WSS4J security policy aware. Both
>> Rampart and CXF will benefit from that.
>>
>> thanks,
>> Nandana
>>
>> On Mon, Jun 15, 2009 at 8:19 PM, Daniel Kulp <dk...@apache.org> wrote:
>>
>> >
>> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
>> > been
>> > thinking about some of those issues and I DID have a discussion with
>> Glen
>> > Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
>> > With the comments and stuff on WSCOMMONS-299, it might be time to really
>> > start
>> > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
>> > maintenance and start making trunk 3.0.
>> >
>> > Things I'd like tackled for 3.0:
>> >
>> > 1) Java 5 - make the collections and everything typed. Use Enums where
>> > appropriate, etc.... Basically, general cleanup. Also, I see that
>> many
>> > operations aren't threadsafe due to use of HashMap's with no
>> > synchronization.
>> > Possibly fix those with ConcurrentHashMaps or similar.
>> >
>> > 2) Better support for the nested policies as described in WSCOMMONS-299.
>> >
>> > 3) Change the builders to use XMLStreamReader. The Policies use
>> > XMLStreamWriter. For consistency, using the reader is preferred. This
>> > also
>> > removes Axiom as a dependency making the requirement list smaller.
>> >
>> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
>> ported
>> > back. CXF has a few utilities and such that would be good to push back
>> and
>> > then remove from CXF.
>> >
>> > 5) Once all of that is done, it would open up the door to allow some
>> more
>> > "common" Policies objects for standard policies. Some could be in
>> Neethi
>> > directly (things like policies objects for WS-Addressing assertions,
>> mtom
>> > stuff, etc...). Others, like the WS-SecurityPolicy stuff could either
>> go
>> > into Neethi or might be better in WSS4J. This could help eliminate a
>> > BUNCH
>> > of duplicate code between users of Neethi, particularly CXF and Rampart.
>> > (maybe if I keep pushing similar code down into commons, we can have a
>> big
>> > merger in the future. Acxfis 3? Maybe not. :-) )
>> >
>> > 6) Support for WS-Policy 1.5.
>> >
>> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
>> > create
>> > the 2.x branch later this week. Thoughts?
>> >
>> > BTW: This is also why I STRONGLY am in favor of Neethi staying in
>> commons
>> > and
>> > not going to an Axis2 TLP.
>> >
>> > --
>> > Daniel Kulp
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>>
>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Director & Chief Scientist; Lanka Software Foundation;
> http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> Blog: http://sanjiva.weerawarana.org/
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Um I'm confused Nandana ... I thought our strategy is Rampart2, which *is*
policy-aware. Why would we invest anything into WSS4J at this point?
Sanjiva.
2009/6/16 Nandana Mihindukulasooriya <na...@gmail.com>
> +1, I also agree that Security Policy stuff should be ideally in WSS4J or
> Neethi and eventually we should make WSS4J security policy aware. Both
> Rampart and CXF will benefit from that.
>
> thanks,
> Nandana
>
> On Mon, Jun 15, 2009 at 8:19 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> >
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been
> > thinking about some of those issues and I DID have a discussion with Glen
> > Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> > With the comments and stuff on WSCOMMONS-299, it might be time to really
> > start
> > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> > maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization.
> > Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also
> > removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> and
> > then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> Neethi
> > directly (things like policies objects for WS-Addressing assertions, mtom
> > stuff, etc...). Others, like the WS-SecurityPolicy stuff could either
> go
> > into Neethi or might be better in WSS4J. This could help eliminate a
> > BUNCH
> > of duplicate code between users of Neethi, particularly CXF and Rampart.
> > (maybe if I keep pushing similar code down into commons, we can have a
> big
> > merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create
> > the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and
> > not going to an Axis2 TLP.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Tue June 16 2009 1:58:51 am Nandana Mihindukulasooriya wrote:
> +1, I also agree that Security Policy stuff should be ideally in WSS4J or
> Neethi and eventually we should make WSS4J security policy aware. Both
> Rampart and CXF will benefit from that.
The first step is to just get a common set of policy objects. The CXF model
and builders for the WS-SecurityPolicy stuff is pretty much a port of the
Rampart model, but cleaned up a lot (to avoid a lot of duplicate code),
updated to Java 5, and additional policy objects created for some of the stuff
Rampart doesn't yet handle (like KeyValueToken). Getting those into a
shareable state is a good thing. I think it would eliminate the entire
rampart-policy module.
As far as making WSS4J security policy aware and using those policies,
definitely doable long term, but not really a huge priority at THIS point.
Possibly just pulling the *BindingBuilder stuff from CXF. Not really sure as
I haven't thought enough about it. It definitely could have benefits for
other users of WSS4J (like Spring WebServices and others).
Basically, the steps for that are:
1) Agree on changes to Neethi to allow for:
2) Create the common/shareable WS-SecurityPolicy model
3) Use (2) in wss4j to make it policy aware.
I'm more concerned right now with the first two bullets. One (or maybe two)
steps at a time. :-)
Dan
> thanks,
> Nandana
>
> On Mon, Jun 15, 2009 at 8:19 PM, Daniel Kulp <dk...@apache.org> wrote:
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been
> > thinking about some of those issues and I DID have a discussion with Glen
> > Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> > With the comments and stuff on WSCOMMONS-299, it might be time to really
> > start
> > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> > maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization.
> > Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also
> > removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> > and then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> > Neethi directly (things like policies objects for WS-Addressing
> > assertions, mtom stuff, etc...). Others, like the WS-SecurityPolicy
> > stuff could either go into Neethi or might be better in WSS4J. This
> > could help eliminate a BUNCH
> > of duplicate code between users of Neethi, particularly CXF and Rampart.
> > (maybe if I keep pushing similar code down into commons, we can have a
> > big merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create
> > the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and
> > not going to an Axis2 TLP.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Nandana Mihindukulasooriya <na...@gmail.com>.
+1, I also agree that Security Policy stuff should be ideally in WSS4J or
Neethi and eventually we should make WSS4J security policy aware. Both
Rampart and CXF will benefit from that.
thanks,
Nandana
On Mon, Jun 15, 2009 at 8:19 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> Some of you have noticed some discussions on WSCOMMONS-299. I've also
> been
> thinking about some of those issues and I DID have a discussion with Glen
> Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> With the comments and stuff on WSCOMMONS-299, it might be time to really
> start
> it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no
> synchronization.
> Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This
> also
> removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a
> BUNCH
> of duplicate code between users of Neethi, particularly CXF and Rampart.
> (maybe if I keep pushing similar code down into commons, we can have a big
> merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to
> create
> the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> and
> not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 for OSGi enabling everything. On the particular approach, I have to defer
to more OSGi experts .. I thought using declarative services allows you to
avoid having bundle activators but I'm prolly off!
Sanjiva.
2009/6/17 Daniel Kulp <dk...@apache.org>
>
> One more thing to add to the list:
>
> 7) Add an OSGi BundleActivator and BundleListener to have allow it to find
> the
> policy providers and stuff in an OSGi environment where the
> META-INF/services
> lookup method doesn't really work very well.
>
> Dan
>
>
> On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been thinking about some of those issues and I DID have a discussion with
> > Glen Daniels at TSSJS about the possibility of starting work on a Neethi
> > 3.0. With the comments and stuff on WSCOMMONS-299, it might be time to
> > really start it. Thus, I'd like to "svn cp" the trunk to a 2.x branch
> for
> > future maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization. Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> and
> > then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> Neethi
> > directly (things like policies objects for WS-Addressing assertions, mtom
> > stuff, etc...). Others, like the WS-SecurityPolicy stuff could either
> go
> > into Neethi or might be better in WSS4J. This could help eliminate a
> > BUNCH of duplicate code between users of Neethi, particularly CXF and
> > Rampart. (maybe if I keep pushing similar code down into commons, we can
> > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Sameera Jayasoma <sa...@gmail.com>.
On Thu, Jun 18, 2009 at 9:10 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Wed June 17 2009 11:16:36 pm Sanjiva Weerawarana wrote:
> > +1 for OSGi enabling everything. On the particular approach, I have to
> > defer to more OSGi experts .. I thought using declarative services allows
> > you to avoid having bundle activators but I'm prolly off!
>
> From my understanding, it kind of depends on the the target audience and
> how
> much "work" you want people writing their own policies to go through to get
> them registered and how much they will need to know about OSGi.
The requirement here is to use neethi with other libraries which have domain
specific policy builders in normal java applications and OSGi enviroments.
IMHO, DS approach is the clean way to solve this problem.
Say foo.jar which can also behave as a bundle, contains policy builders and
they are listed under META-INF/services. When foo.jar is in standard java
application, neethi can access the policy builder list. But neethi does not
have access to the META-INF/services, when it is running in an OSGi
environment. Therefore foo.jar has to inform neethi explicitly that I have
some policy builders.
Say we expose AssertionBuilderFactory as an OSGi service using DS component.
We only need to write an xml file here. Or else we can use Maven SCR plugin
[1]. And we need to add a method to the AssertionBuilderFactory with the
following signature. This method accepts a class loader and it can be used
to search for META-INF/services and load builders if any.
*public void registerBuilders(ClassLoader cl);
*In this case, what foo.jar has to do is, accuire the
AssertionBuilderFactory and invoke the registerBuilders() method by giving
the bundle class loader as a parameter. Writing a DS component which has a
dependency on AssertionBuilderFactory service, with a component
implementation class will do the rest here.
Thanks
Sameera
[1] http://felix.apache.org/site/apache-felix-maven-scr-plugin.html
>
>
> Currently, all they need to do is add a file in META-INF/services that
> lists
> their builder classes. That's it. With a BundleActivator/Listener, we
> can
> use that same approach and it will "just work". All they need to do is
> make
> sure their jar is loadable in OSGi. (mavne bundle plugin would work for
> example)
>
> With DS, they would need to write an XML file that describes their
> "services"
> (assertion builders). Then they need to register that by adding an entry
> into
> the manifest. Most common way to do that would be to configure the maven-
> bundle-plugin. Those would require some extra "knowledge" and expertise
> in
> OSGi. For example, let's say for a minute that we don't put the WS-SecPol
> stuff into a common area, then porting Rampart would involve creating XML
> entries describing ALL the builders in Rampart (a bunch of them) as well as
> configuring the OSGi stuff. Definitely a bit of work.
>
> I guess if the target audience for Neethi 3 would ALWAYS be OSGi experts,
> then
> DS is probably the way to go. However, my gut feeling is that that isn't
> ALWAYS the case and the "simple" META-INF/services stuff that is there now
> is
> a bit easier. (and certainly easier to port older code)
>
> Caveat: I'm by no means an "OSGi expert".
>
> Dan
>
>
>
> >
> > Sanjiva.
> >
> > 2009/6/17 Daniel Kulp <dk...@apache.org>
> >
> > > One more thing to add to the list:
> > >
> > > 7) Add an OSGi BundleActivator and BundleListener to have allow it to
> > > find the
> > > policy providers and stuff in an OSGi environment where the
> > > META-INF/services
> > > lookup method doesn't really work very well.
> > >
> > > Dan
> > >
> > > On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> > > > Some of you have noticed some discussions on WSCOMMONS-299. I've
> also
> > > > been thinking about some of those issues and I DID have a discussion
> > > > with Glen Daniels at TSSJS about the possibility of starting work on
> a
> > > > Neethi 3.0. With the comments and stuff on WSCOMMONS-299, it might be
> > > > time to really start it. Thus, I'd like to "svn cp" the trunk to a
> > > > 2.x branch
> > >
> > > for
> > >
> > > > future maintenance and start making trunk 3.0.
> > > >
> > > > Things I'd like tackled for 3.0:
> > > >
> > > > 1) Java 5 - make the collections and everything typed. Use Enums
> where
> > > > appropriate, etc.... Basically, general cleanup. Also, I see that
> > > > many operations aren't threadsafe due to use of HashMap's with no
> > > > synchronization. Possibly fix those with ConcurrentHashMaps or
> similar.
> > > >
> > > > 2) Better support for the nested policies as described in
> > > > WSCOMMONS-299.
> > > >
> > > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > > XMLStreamWriter. For consistency, using the reader is preferred.
> > > > This also removes Axiom as a dependency making the requirement list
> > > > smaller.
> > > >
> > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
> > > > ported back. CXF has a few utilities and such that would be good to
> > > > push back
> > >
> > > and
> > >
> > > > then remove from CXF.
> > > >
> --
> Sameera Jayasoma
> Software Engineer
> WSO2 Inc.
> Oxygenating the Web Service Platform.
> http://wso2.org/
>
> blog: http://tech.jayasoma.org
> > > > 5) Once all of that is done, it would open up the door to allow some
> > > > more "common" Policies objects for standard policies. Some could be
> > > > in
> > >
> > > Neethi
> > >
> > > > directly (things like policies objects for WS-Addressing assertions,
> > > > mtom stuff, etc...). Others, like the WS-SecurityPolicy stuff
> could
> > > > either
> > >
> > > go
> > >
> > > > into Neethi or might be better in WSS4J. This could help eliminate
> a
> > > > BUNCH of duplicate code between users of Neethi, particularly CXF and
> > > > Rampart. (maybe if I keep pushing similar code down into commons, we
> > > > can have a big merger in the future. Acxfis 3? Maybe not. :-) )
> > > >
> > > > 6) Support for WS-Policy 1.5.
> > > >
> > > > Anyway, if no one really objects to starting the 3.0 work, I'd like
> to
> > > > create the 2.x branch later this week. Thoughts?
> > > >
> > > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> > > > commons and not going to an Axis2 TLP.
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://www.dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Wed June 17 2009 11:16:36 pm Sanjiva Weerawarana wrote:
> +1 for OSGi enabling everything. On the particular approach, I have to
> defer to more OSGi experts .. I thought using declarative services allows
> you to avoid having bundle activators but I'm prolly off!
From my understanding, it kind of depends on the the target audience and how
much "work" you want people writing their own policies to go through to get
them registered and how much they will need to know about OSGi.
Currently, all they need to do is add a file in META-INF/services that lists
their builder classes. That's it. With a BundleActivator/Listener, we can
use that same approach and it will "just work". All they need to do is make
sure their jar is loadable in OSGi. (mavne bundle plugin would work for
example)
With DS, they would need to write an XML file that describes their "services"
(assertion builders). Then they need to register that by adding an entry into
the manifest. Most common way to do that would be to configure the maven-
bundle-plugin. Those would require some extra "knowledge" and expertise in
OSGi. For example, let's say for a minute that we don't put the WS-SecPol
stuff into a common area, then porting Rampart would involve creating XML
entries describing ALL the builders in Rampart (a bunch of them) as well as
configuring the OSGi stuff. Definitely a bit of work.
I guess if the target audience for Neethi 3 would ALWAYS be OSGi experts, then
DS is probably the way to go. However, my gut feeling is that that isn't
ALWAYS the case and the "simple" META-INF/services stuff that is there now is
a bit easier. (and certainly easier to port older code)
Caveat: I'm by no means an "OSGi expert".
Dan
>
> Sanjiva.
>
> 2009/6/17 Daniel Kulp <dk...@apache.org>
>
> > One more thing to add to the list:
> >
> > 7) Add an OSGi BundleActivator and BundleListener to have allow it to
> > find the
> > policy providers and stuff in an OSGi environment where the
> > META-INF/services
> > lookup method doesn't really work very well.
> >
> > Dan
> >
> > On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> > > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > > been thinking about some of those issues and I DID have a discussion
> > > with Glen Daniels at TSSJS about the possibility of starting work on a
> > > Neethi 3.0. With the comments and stuff on WSCOMMONS-299, it might be
> > > time to really start it. Thus, I'd like to "svn cp" the trunk to a
> > > 2.x branch
> >
> > for
> >
> > > future maintenance and start making trunk 3.0.
> > >
> > > Things I'd like tackled for 3.0:
> > >
> > > 1) Java 5 - make the collections and everything typed. Use Enums where
> > > appropriate, etc.... Basically, general cleanup. Also, I see that
> > > many operations aren't threadsafe due to use of HashMap's with no
> > > synchronization. Possibly fix those with ConcurrentHashMaps or similar.
> > >
> > > 2) Better support for the nested policies as described in
> > > WSCOMMONS-299.
> > >
> > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > XMLStreamWriter. For consistency, using the reader is preferred.
> > > This also removes Axiom as a dependency making the requirement list
> > > smaller.
> > >
> > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
> > > ported back. CXF has a few utilities and such that would be good to
> > > push back
> >
> > and
> >
> > > then remove from CXF.
> > >
> > > 5) Once all of that is done, it would open up the door to allow some
> > > more "common" Policies objects for standard policies. Some could be
> > > in
> >
> > Neethi
> >
> > > directly (things like policies objects for WS-Addressing assertions,
> > > mtom stuff, etc...). Others, like the WS-SecurityPolicy stuff could
> > > either
> >
> > go
> >
> > > into Neethi or might be better in WSS4J. This could help eliminate a
> > > BUNCH of duplicate code between users of Neethi, particularly CXF and
> > > Rampart. (maybe if I keep pushing similar code down into commons, we
> > > can have a big merger in the future. Acxfis 3? Maybe not. :-) )
> > >
> > > 6) Support for WS-Policy 1.5.
> > >
> > > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > > create the 2.x branch later this week. Thoughts?
> > >
> > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> > > commons and not going to an Axis2 TLP.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 for OSGi enabling everything. On the particular approach, I have to defer
to more OSGi experts .. I thought using declarative services allows you to
avoid having bundle activators but I'm prolly off!
Sanjiva.
2009/6/17 Daniel Kulp <dk...@apache.org>
>
> One more thing to add to the list:
>
> 7) Add an OSGi BundleActivator and BundleListener to have allow it to find
> the
> policy providers and stuff in an OSGi environment where the
> META-INF/services
> lookup method doesn't really work very well.
>
> Dan
>
>
> On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been thinking about some of those issues and I DID have a discussion with
> > Glen Daniels at TSSJS about the possibility of starting work on a Neethi
> > 3.0. With the comments and stuff on WSCOMMONS-299, it might be time to
> > really start it. Thus, I'd like to "svn cp" the trunk to a 2.x branch
> for
> > future maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization. Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> and
> > then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> Neethi
> > directly (things like policies objects for WS-Addressing assertions, mtom
> > stuff, etc...). Others, like the WS-SecurityPolicy stuff could either
> go
> > into Neethi or might be better in WSS4J. This could help eliminate a
> > BUNCH of duplicate code between users of Neethi, particularly CXF and
> > Rampart. (maybe if I keep pushing similar code down into commons, we can
> > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
One more thing to add to the list:
7) Add an OSGi BundleActivator and BundleListener to have allow it to find the
policy providers and stuff in an OSGi environment where the META-INF/services
lookup method doesn't really work very well.
Dan
On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> Some of you have noticed some discussions on WSCOMMONS-299. I've also
> been thinking about some of those issues and I DID have a discussion with
> Glen Daniels at TSSJS about the possibility of starting work on a Neethi
> 3.0. With the comments and stuff on WSCOMMONS-299, it might be time to
> really start it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for
> future maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no
> synchronization. Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This
> also removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a
> BUNCH of duplicate code between users of Neethi, particularly CXF and
> Rampart. (maybe if I keep pushing similar code down into commons, we can
> have a big merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to
> create the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> and not going to an Axis2 TLP.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Andreas Veithen <an...@gmail.com>.
+1 Sounds good.
Andreas
On Mon, Jun 15, 2009 at 16:49, Daniel Kulp<dk...@apache.org> wrote:
>
> Some of you have noticed some discussions on WSCOMMONS-299. I've also been
> thinking about some of those issues and I DID have a discussion with Glen
> Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> With the comments and stuff on WSCOMMONS-299, it might be time to really start
> it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no synchronization.
> Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This also
> removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a BUNCH
> of duplicate code between users of Neethi, particularly CXF and Rampart.
> (maybe if I keep pushing similar code down into commons, we can have a big
> merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to create
> the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons and
> not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Tue June 16 2009 11:29:05 pm Sanjiva Weerawarana wrote:
> +1 from me.
>
> So WSS4J is currently not really policy- aware .. that's done in Rampart.
> I'd say that that's a WSS4J2 we're talking about right?
Possibly. Since pulling code from CXF/Rampart could just be additions to
WSS4J, it could be a 1.6 type thing as well. Not really sure at this point.
Dan
>
> Sanjiva.
>
> 2009/6/17 Daniel Kulp <dk...@apache.org>
>
> > The more I think about this, the more I like it. Porting existing code
> > to 3.0 becomes quite easy: just change:
> >
> > public class MyBuilder implements AssertionBuilder{
> >
> > to
> >
> > public class MyBuilder implements AssertionBuilder<OMEelement>{
> >
> > and it should be fine. Obviously, those builders would only work when
> > Axiom
> > is available (ex: in Axis2) but that should be fine. For builders we
> > "build
> > in" to Neethi or WSS4J, we can use either Element (if easier/complex) or
> > StAX
> > (simple things) to make them usable when Axiom isn't there.
> >
> > Anyway, I change my #3 proposal to this idea. :-)
> >
> > Dan
> >
> > On Tue June 16 2009 2:45:54 pm Daniel Kulp wrote:
> > > Since we're going Java 5, the other option COULD be to make the
> > > AssertionBuilder interface something like:
> > >
> > > public interface AssertionBuilder<T> {
> > > Assertion build(T element, AssertionBuilderFactory factory)
> > > ...
> > > }
> > > where T could be Element, XMLStreamReader, or OEElement (or others in
> > > the future) and do some "magic" in the AssertionBuilderFactory to do
> > > conversions back and forth as needed depending on what the registered
> > > Builder requires and what gets passed in. Quite a bit more complex,
> > > but definitely more flexible.
> > >
> > > Dan
> > >
> > > On Tue June 16 2009 2:41:14 pm Daniel Kulp wrote:
> > > > On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > > > > The way Neethi works is that it basically uses Axiom only to
> >
> > implement
> >
> > > > > the policy-domain specific parser to create the policy-domain
> >
> > specific
> >
> > > > > object model. That is, it is TOTALLY internal.
> > > >
> > > > Not entirely. The PolicyEngine object has public methods like:
> > > > Policy getPolicy(OMElement element)
> > > > that make it NOT totally internal.
> > > >
> > > > > Its of course possible to do without it, but that would make it
> > > > > that much harder to write a security policy parser for example as
> >
> > everything
> >
> > > > > would have to be done directly in StAX instead of Axiom - a tree
> > > > > API
> >
> > is
> >
> > > > > of course easier to deal with than a streaming API.
> > > >
> > > > That's a matter of opinion. I personally find dealing with StAX
> > > > quite easy, but I'm completely used to it by now. :-)
> > > >
> > > > That said, if you want to keep it a tree, I'm QUITE OK with using
> > > > org.w3c.dom.Element. That would make my life MUCH easier as all the
> >
> > CXF
> >
> > > > builders are already using it. :-) I mostly suggested StAX
> >
> > since
> >
> > > > the writers are already using it. Kind of a mirror thing.
> > > >
> > > > > That could could easily be factory'ed away but that would still
> >
> > require
> >
> > > > > CXF and Axis2 to have their own domain specific builders. Have you
> > > > > evaluated the pain level of going down to StAX to do the building?
> > > >
> > > > The main point of what I'm trying to do with 3.0 is to make it so CXF
> >
> > and
> >
> > > > Axis2 don't need their own domain specific builders. We can share
> > > > the policy model objects, the builders that go with them, etc....
> > > > For example, I know that several of the Rampart builders don't
> > > > properly record some of the attributes into the model. I know cause
> > > > I fixed
> >
> > them
> >
> > > > in the CXF builders. It would be good to have a single set of
> > > > builders and models where we can both benefit from fixes such as
> > > > that.
> > > >
> > > > However, that cannot happen until we agree on an API for the
> > > > builders. Using Axiom is a non-starter for me. StAX or DOM Element
> > > > is OK by me. Doesn't matter which. You have a preference between
> > > > those two? I'd
> >
> > be
> >
> > > > happy either way.
> > > >
> > > > > I'm not sure what MEX impacts here .. Axis2 has a MEX module and
> > > > > there's no overlap/issue with Neethi's parsing model there. What am
> > > > > I missing?
> > > >
> > > > It mostly has to do if you get a Policy as an InputStream (MEX or
> > > > from
> >
> > a
> >
> > > > Policy repository via REST or similar), what is the most efficient
> > > > way
> >
> > of
> >
> > > > converting that stream into a usable Policy object. InputStream ->
> >
> > StAX
> >
> > > > -> builders is quite efficient requiring near 0 memory overhead
> > > > during the conversion. However, policy docs are "generally" fairly
> > > > smallish (unless you are really nuts and LOVE policy docs ;-) so
> > > > doing an InputStream -> some infoset model like Axiom/DOM -> builders
> > > > is really not THAT big of a deal.
> > > >
> > > > Dan
> > > >
> > > > > Sanjiva.
> > > > >
> > > > > 2009/6/16 Daniel Kulp <dk...@apache.org>
> > > > >
> > > > > > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > > > > > +1 Dan. Can you clarify #3 a bit please?
> > > > > >
> > > > > > Sure. Basically, in order to make this workable at all (and
> > > > > > worth my time to
> > > > > > proceed down this course), we need to have an API that is
> > > > > > palatable by everyone involved. The PRIMARY reason for the fork
> > > > > > of some of the Neethi stuff in CXF is the Axiom dependency which
> > > > > > is not acceptable for our core use
> > > > > > cases. If that is eliminated, the fork in CXF can go away.
> >
> > There
> >
> > > > > > were two
> > > > > > main options I considered:
> > > > > >
> > > > > > 1) DOM element - this is currently what the CXF version uses.
> >
> > This
> >
> > > > > > is because things like WSDL4J DOM parses extensor elements (by
> > > > > > default) and spring provides configuration things as DOM elements
> >
> > and
> >
> > > > > > such. Thus, it worked best for us. However, for Axis2, that
> > > > > > would require flipping the Axiom stuff over to DOM mode which has
> > > > > > performance issues.
> > > > > >
> > > > > > 2) StAX - The proposal below is to use StAX. The Policy objects
> > > > > > themselves
> > > > > > already use StAX for writing XML. Thus, using it to read the
> > > > > > xml would make
> > > > > > it consistent. Also, that makes it pretty easy for both Axis2
> > > > > > and CXF to work with it. Creating an XMLStreamReader from a DOM
> > > > > > or Axiom thing is "trivial" so whatever path you choose should
> > > > > > work fairly well. Plus, as we
> > > > > > go down the route of WS-MEX and other remote policy retrieval
> > > > > > mechanisms, it
> > > > > > would allow direct StAX streaming. (like directly from the HTTP
> > > > > > InputStream)
> > > > > >
> > > > > > Anyway, switching to StAX seemed to be the most palatable by both
> > > > > > parties. If we can agree on that, then the common policy objects
> >
> > and
> >
> > > > > > stuff can become a
> > > > > > reality.
> > > > > >
> > > > > > Dan
> > > > > >
> > > > > > > Sanjiva.
> > > > > > >
> > > > > > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > > > > > >
> > > > > > > > Some of you have noticed some discussions on WSCOMMONS-299.
> > > > > > > > I've also been
> > > > > > > > thinking about some of those issues and I DID have a
> > > > > > > > discussion with
> > > > > >
> > > > > > Glen
> > > > > >
> > > > > > > > Daniels at TSSJS about the possibility of starting work on a
> > > > > > > > Neethi
> > > > > >
> > > > > > 3.0.
> > > > > >
> > > > > > > > With the comments and stuff on WSCOMMONS-299, it might be
> > > > > > > > time
> >
> > to
> >
> > > > > > really
> > > > > >
> > > > > > > > start
> > > > > > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch
> > > > > > > > for future maintenance and start making trunk 3.0.
> > > > > > > >
> > > > > > > > Things I'd like tackled for 3.0:
> > > > > > > >
> > > > > > > > 1) Java 5 - make the collections and everything typed. Use
> >
> > Enums
> >
> > > > > > > > where appropriate, etc.... Basically, general cleanup.
> > > > > > > > Also,
> >
> > I
> >
> > > > > > > > see that
> > > > > >
> > > > > > many
> > > > > >
> > > > > > > > operations aren't threadsafe due to use of HashMap's with no
> > > > > > > > synchronization.
> > > > > > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > > > > > >
> > > > > > > > 2) Better support for the nested policies as described in
> > > > > >
> > > > > > WSCOMMONS-299.
> > > > > >
> > > > > > > > 3) Change the builders to use XMLStreamReader. The Policies
> >
> > use
> >
> > > > > > > > XMLStreamWriter. For consistency, using the reader is
> >
> > preferred.
> >
> > > > > > This
> > > > > >
> > > > > > > > also
> > > > > > > > removes Axiom as a dependency making the requirement list
> > > > > > > > smaller.
> > > > > > > >
> > > > > > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF
> > > > > > > > can be
> > > > > >
> > > > > > ported
> > > > > >
> > > > > > > > back. CXF has a few utilities and such that would be good to
> > > > > > > > push back and then remove from CXF.
> > > > > > > >
> > > > > > > > 5) Once all of that is done, it would open up the door to
> > > > > > > > allow some
> > > > > >
> > > > > > more
> > > > > >
> > > > > > > > "common" Policies objects for standard policies. Some could
> >
> > be
> >
> > > > > > > > in Neethi directly (things like policies objects for
> > > > > > > > WS-Addressing assertions, mtom stuff, etc...). Others,
> > > > > > > > like the
> > > > > > > > WS-SecurityPolicy stuff could either go into Neethi or might
> > > > > > > > be better in WSS4J. This could help eliminate a BUNCH of
> > > > > > > > duplicate code between users of Neethi, particularly CXF and
> > > > > >
> > > > > > Rampart.
> > > > > >
> > > > > > > > (maybe if I keep pushing similar code down into commons, we
> > > > > > > > can have a big merger in the future. Acxfis 3? Maybe not.
> > > > > > > > :-) )
> > > > > > > >
> > > > > > > > 6) Support for WS-Policy 1.5.
> > > > > > > >
> > > > > > > > Anyway, if no one really objects to starting the 3.0 work,
> > > > > > > > I'd like to create
> > > > > > > > the 2.x branch later this week. Thoughts?
> > > > > > > >
> > > > > > > > BTW: This is also why I STRONGLY am in favor of Neethi
> > > > > > > > staying
> >
> > in
> >
> > > > > > commons
> > > > > >
> > > > > > > > and
> > > > > > > > not going to an Axis2 TLP.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Daniel Kulp
> > > > > > > > dkulp@apache.org
> > > > > > > > http://www.dankulp.com/blog
> > > > > >
> > > > > > --
> > > > > > Daniel Kulp
> > > > > > dkulp@apache.org
> > > > > > http://www.dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 from me.
So WSS4J is currently not really policy- aware .. that's done in Rampart.
I'd say that that's a WSS4J2 we're talking about right?
Sanjiva.
2009/6/17 Daniel Kulp <dk...@apache.org>
>
> The more I think about this, the more I like it. Porting existing code to
> 3.0 becomes quite easy: just change:
>
> public class MyBuilder implements AssertionBuilder{
>
> to
>
> public class MyBuilder implements AssertionBuilder<OMEelement>{
>
> and it should be fine. Obviously, those builders would only work when
> Axiom
> is available (ex: in Axis2) but that should be fine. For builders we
> "build
> in" to Neethi or WSS4J, we can use either Element (if easier/complex) or
> StAX
> (simple things) to make them usable when Axiom isn't there.
>
> Anyway, I change my #3 proposal to this idea. :-)
>
> Dan
>
>
>
> On Tue June 16 2009 2:45:54 pm Daniel Kulp wrote:
> > Since we're going Java 5, the other option COULD be to make the
> > AssertionBuilder interface something like:
> >
> > public interface AssertionBuilder<T> {
> > Assertion build(T element, AssertionBuilderFactory factory)
> > ...
> > }
> > where T could be Element, XMLStreamReader, or OEElement (or others in the
> > future) and do some "magic" in the AssertionBuilderFactory to do
> > conversions back and forth as needed depending on what the registered
> > Builder requires and what gets passed in. Quite a bit more complex, but
> > definitely more flexible.
> >
> > Dan
> >
> > On Tue June 16 2009 2:41:14 pm Daniel Kulp wrote:
> > > On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > > > The way Neethi works is that it basically uses Axiom only to
> implement
> > > > the policy-domain specific parser to create the policy-domain
> specific
> > > > object model. That is, it is TOTALLY internal.
> > >
> > > Not entirely. The PolicyEngine object has public methods like:
> > > Policy getPolicy(OMElement element)
> > > that make it NOT totally internal.
> > >
> > > > Its of course possible to do without it, but that would make it that
> > > > much harder to write a security policy parser for example as
> everything
> > > > would have to be done directly in StAX instead of Axiom - a tree API
> is
> > > > of course easier to deal with than a streaming API.
> > >
> > > That's a matter of opinion. I personally find dealing with StAX quite
> > > easy, but I'm completely used to it by now. :-)
> > >
> > > That said, if you want to keep it a tree, I'm QUITE OK with using
> > > org.w3c.dom.Element. That would make my life MUCH easier as all the
> CXF
> > > builders are already using it. :-) I mostly suggested StAX
> since
> > > the writers are already using it. Kind of a mirror thing.
> > >
> > > > That could could easily be factory'ed away but that would still
> require
> > > > CXF and Axis2 to have their own domain specific builders. Have you
> > > > evaluated the pain level of going down to StAX to do the building?
> > >
> > > The main point of what I'm trying to do with 3.0 is to make it so CXF
> and
> > > Axis2 don't need their own domain specific builders. We can share the
> > > policy model objects, the builders that go with them, etc.... For
> > > example, I know that several of the Rampart builders don't properly
> > > record some of the attributes into the model. I know cause I fixed
> them
> > > in the CXF builders. It would be good to have a single set of builders
> > > and models where we can both benefit from fixes such as that.
> > >
> > > However, that cannot happen until we agree on an API for the builders.
> > > Using Axiom is a non-starter for me. StAX or DOM Element is OK by me.
> > > Doesn't matter which. You have a preference between those two? I'd
> be
> > > happy either way.
> > >
> > > > I'm not sure what MEX impacts here .. Axis2 has a MEX module and
> > > > there's no overlap/issue with Neethi's parsing model there. What am I
> > > > missing?
> > >
> > > It mostly has to do if you get a Policy as an InputStream (MEX or from
> a
> > > Policy repository via REST or similar), what is the most efficient way
> of
> > > converting that stream into a usable Policy object. InputStream ->
> StAX
> > > -> builders is quite efficient requiring near 0 memory overhead during
> > > the conversion. However, policy docs are "generally" fairly smallish
> > > (unless you are really nuts and LOVE policy docs ;-) so doing an
> > > InputStream -> some infoset model like Axiom/DOM -> builders is really
> > > not THAT big of a deal.
> > >
> > > Dan
> > >
> > > > Sanjiva.
> > > >
> > > > 2009/6/16 Daniel Kulp <dk...@apache.org>
> > > >
> > > > > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > > > > +1 Dan. Can you clarify #3 a bit please?
> > > > >
> > > > > Sure. Basically, in order to make this workable at all (and worth
> > > > > my time to
> > > > > proceed down this course), we need to have an API that is palatable
> > > > > by everyone involved. The PRIMARY reason for the fork of some of
> > > > > the Neethi stuff in CXF is the Axiom dependency which is not
> > > > > acceptable for our core use
> > > > > cases. If that is eliminated, the fork in CXF can go away.
> There
> > > > > were two
> > > > > main options I considered:
> > > > >
> > > > > 1) DOM element - this is currently what the CXF version uses.
> This
> > > > > is because things like WSDL4J DOM parses extensor elements (by
> > > > > default) and spring provides configuration things as DOM elements
> and
> > > > > such. Thus, it worked best for us. However, for Axis2, that would
> > > > > require flipping the Axiom stuff over to DOM mode which has
> > > > > performance issues.
> > > > >
> > > > > 2) StAX - The proposal below is to use StAX. The Policy objects
> > > > > themselves
> > > > > already use StAX for writing XML. Thus, using it to read the xml
> > > > > would make
> > > > > it consistent. Also, that makes it pretty easy for both Axis2 and
> > > > > CXF to work with it. Creating an XMLStreamReader from a DOM or
> > > > > Axiom thing is "trivial" so whatever path you choose should work
> > > > > fairly well. Plus, as we
> > > > > go down the route of WS-MEX and other remote policy retrieval
> > > > > mechanisms, it
> > > > > would allow direct StAX streaming. (like directly from the HTTP
> > > > > InputStream)
> > > > >
> > > > > Anyway, switching to StAX seemed to be the most palatable by both
> > > > > parties. If we can agree on that, then the common policy objects
> and
> > > > > stuff can become a
> > > > > reality.
> > > > >
> > > > > Dan
> > > > >
> > > > > > Sanjiva.
> > > > > >
> > > > > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > > > > >
> > > > > > > Some of you have noticed some discussions on WSCOMMONS-299.
> > > > > > > I've also been
> > > > > > > thinking about some of those issues and I DID have a discussion
> > > > > > > with
> > > > >
> > > > > Glen
> > > > >
> > > > > > > Daniels at TSSJS about the possibility of starting work on a
> > > > > > > Neethi
> > > > >
> > > > > 3.0.
> > > > >
> > > > > > > With the comments and stuff on WSCOMMONS-299, it might be time
> to
> > > > >
> > > > > really
> > > > >
> > > > > > > start
> > > > > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for
> > > > > > > future maintenance and start making trunk 3.0.
> > > > > > >
> > > > > > > Things I'd like tackled for 3.0:
> > > > > > >
> > > > > > > 1) Java 5 - make the collections and everything typed. Use
> Enums
> > > > > > > where appropriate, etc.... Basically, general cleanup. Also,
> I
> > > > > > > see that
> > > > >
> > > > > many
> > > > >
> > > > > > > operations aren't threadsafe due to use of HashMap's with no
> > > > > > > synchronization.
> > > > > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > > > > >
> > > > > > > 2) Better support for the nested policies as described in
> > > > >
> > > > > WSCOMMONS-299.
> > > > >
> > > > > > > 3) Change the builders to use XMLStreamReader. The Policies
> use
> > > > > > > XMLStreamWriter. For consistency, using the reader is
> preferred.
> > > > >
> > > > > This
> > > > >
> > > > > > > also
> > > > > > > removes Axiom as a dependency making the requirement list
> > > > > > > smaller.
> > > > > > >
> > > > > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can
> > > > > > > be
> > > > >
> > > > > ported
> > > > >
> > > > > > > back. CXF has a few utilities and such that would be good to
> > > > > > > push back and then remove from CXF.
> > > > > > >
> > > > > > > 5) Once all of that is done, it would open up the door to allow
> > > > > > > some
> > > > >
> > > > > more
> > > > >
> > > > > > > "common" Policies objects for standard policies. Some could
> be
> > > > > > > in Neethi directly (things like policies objects for
> > > > > > > WS-Addressing assertions, mtom stuff, etc...). Others, like
> > > > > > > the
> > > > > > > WS-SecurityPolicy stuff could either go into Neethi or might be
> > > > > > > better in WSS4J. This could help eliminate a BUNCH
> > > > > > > of duplicate code between users of Neethi, particularly CXF and
> > > > >
> > > > > Rampart.
> > > > >
> > > > > > > (maybe if I keep pushing similar code down into commons, we can
> > > > > > > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> > > > > > >
> > > > > > > 6) Support for WS-Policy 1.5.
> > > > > > >
> > > > > > > Anyway, if no one really objects to starting the 3.0 work, I'd
> > > > > > > like to create
> > > > > > > the 2.x branch later this week. Thoughts?
> > > > > > >
> > > > > > > BTW: This is also why I STRONGLY am in favor of Neethi staying
> in
> > > > >
> > > > > commons
> > > > >
> > > > > > > and
> > > > > > > not going to an Axis2 TLP.
> > > > > > >
> > > > > > > --
> > > > > > > Daniel Kulp
> > > > > > > dkulp@apache.org
> > > > > > > http://www.dankulp.com/blog
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > dkulp@apache.org
> > > > > http://www.dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
The more I think about this, the more I like it. Porting existing code to
3.0 becomes quite easy: just change:
public class MyBuilder implements AssertionBuilder{
to
public class MyBuilder implements AssertionBuilder<OMEelement>{
and it should be fine. Obviously, those builders would only work when Axiom
is available (ex: in Axis2) but that should be fine. For builders we "build
in" to Neethi or WSS4J, we can use either Element (if easier/complex) or StAX
(simple things) to make them usable when Axiom isn't there.
Anyway, I change my #3 proposal to this idea. :-)
Dan
On Tue June 16 2009 2:45:54 pm Daniel Kulp wrote:
> Since we're going Java 5, the other option COULD be to make the
> AssertionBuilder interface something like:
>
> public interface AssertionBuilder<T> {
> Assertion build(T element, AssertionBuilderFactory factory)
> ...
> }
> where T could be Element, XMLStreamReader, or OEElement (or others in the
> future) and do some "magic" in the AssertionBuilderFactory to do
> conversions back and forth as needed depending on what the registered
> Builder requires and what gets passed in. Quite a bit more complex, but
> definitely more flexible.
>
> Dan
>
> On Tue June 16 2009 2:41:14 pm Daniel Kulp wrote:
> > On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > > The way Neethi works is that it basically uses Axiom only to implement
> > > the policy-domain specific parser to create the policy-domain specific
> > > object model. That is, it is TOTALLY internal.
> >
> > Not entirely. The PolicyEngine object has public methods like:
> > Policy getPolicy(OMElement element)
> > that make it NOT totally internal.
> >
> > > Its of course possible to do without it, but that would make it that
> > > much harder to write a security policy parser for example as everything
> > > would have to be done directly in StAX instead of Axiom - a tree API is
> > > of course easier to deal with than a streaming API.
> >
> > That's a matter of opinion. I personally find dealing with StAX quite
> > easy, but I'm completely used to it by now. :-)
> >
> > That said, if you want to keep it a tree, I'm QUITE OK with using
> > org.w3c.dom.Element. That would make my life MUCH easier as all the CXF
> > builders are already using it. :-) I mostly suggested StAX since
> > the writers are already using it. Kind of a mirror thing.
> >
> > > That could could easily be factory'ed away but that would still require
> > > CXF and Axis2 to have their own domain specific builders. Have you
> > > evaluated the pain level of going down to StAX to do the building?
> >
> > The main point of what I'm trying to do with 3.0 is to make it so CXF and
> > Axis2 don't need their own domain specific builders. We can share the
> > policy model objects, the builders that go with them, etc.... For
> > example, I know that several of the Rampart builders don't properly
> > record some of the attributes into the model. I know cause I fixed them
> > in the CXF builders. It would be good to have a single set of builders
> > and models where we can both benefit from fixes such as that.
> >
> > However, that cannot happen until we agree on an API for the builders.
> > Using Axiom is a non-starter for me. StAX or DOM Element is OK by me.
> > Doesn't matter which. You have a preference between those two? I'd be
> > happy either way.
> >
> > > I'm not sure what MEX impacts here .. Axis2 has a MEX module and
> > > there's no overlap/issue with Neethi's parsing model there. What am I
> > > missing?
> >
> > It mostly has to do if you get a Policy as an InputStream (MEX or from a
> > Policy repository via REST or similar), what is the most efficient way of
> > converting that stream into a usable Policy object. InputStream -> StAX
> > -> builders is quite efficient requiring near 0 memory overhead during
> > the conversion. However, policy docs are "generally" fairly smallish
> > (unless you are really nuts and LOVE policy docs ;-) so doing an
> > InputStream -> some infoset model like Axiom/DOM -> builders is really
> > not THAT big of a deal.
> >
> > Dan
> >
> > > Sanjiva.
> > >
> > > 2009/6/16 Daniel Kulp <dk...@apache.org>
> > >
> > > > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > > > +1 Dan. Can you clarify #3 a bit please?
> > > >
> > > > Sure. Basically, in order to make this workable at all (and worth
> > > > my time to
> > > > proceed down this course), we need to have an API that is palatable
> > > > by everyone involved. The PRIMARY reason for the fork of some of
> > > > the Neethi stuff in CXF is the Axiom dependency which is not
> > > > acceptable for our core use
> > > > cases. If that is eliminated, the fork in CXF can go away. There
> > > > were two
> > > > main options I considered:
> > > >
> > > > 1) DOM element - this is currently what the CXF version uses. This
> > > > is because things like WSDL4J DOM parses extensor elements (by
> > > > default) and spring provides configuration things as DOM elements and
> > > > such. Thus, it worked best for us. However, for Axis2, that would
> > > > require flipping the Axiom stuff over to DOM mode which has
> > > > performance issues.
> > > >
> > > > 2) StAX - The proposal below is to use StAX. The Policy objects
> > > > themselves
> > > > already use StAX for writing XML. Thus, using it to read the xml
> > > > would make
> > > > it consistent. Also, that makes it pretty easy for both Axis2 and
> > > > CXF to work with it. Creating an XMLStreamReader from a DOM or
> > > > Axiom thing is "trivial" so whatever path you choose should work
> > > > fairly well. Plus, as we
> > > > go down the route of WS-MEX and other remote policy retrieval
> > > > mechanisms, it
> > > > would allow direct StAX streaming. (like directly from the HTTP
> > > > InputStream)
> > > >
> > > > Anyway, switching to StAX seemed to be the most palatable by both
> > > > parties. If we can agree on that, then the common policy objects and
> > > > stuff can become a
> > > > reality.
> > > >
> > > > Dan
> > > >
> > > > > Sanjiva.
> > > > >
> > > > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > > > >
> > > > > > Some of you have noticed some discussions on WSCOMMONS-299.
> > > > > > I've also been
> > > > > > thinking about some of those issues and I DID have a discussion
> > > > > > with
> > > >
> > > > Glen
> > > >
> > > > > > Daniels at TSSJS about the possibility of starting work on a
> > > > > > Neethi
> > > >
> > > > 3.0.
> > > >
> > > > > > With the comments and stuff on WSCOMMONS-299, it might be time to
> > > >
> > > > really
> > > >
> > > > > > start
> > > > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for
> > > > > > future maintenance and start making trunk 3.0.
> > > > > >
> > > > > > Things I'd like tackled for 3.0:
> > > > > >
> > > > > > 1) Java 5 - make the collections and everything typed. Use Enums
> > > > > > where appropriate, etc.... Basically, general cleanup. Also, I
> > > > > > see that
> > > >
> > > > many
> > > >
> > > > > > operations aren't threadsafe due to use of HashMap's with no
> > > > > > synchronization.
> > > > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > > > >
> > > > > > 2) Better support for the nested policies as described in
> > > >
> > > > WSCOMMONS-299.
> > > >
> > > > > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > > > > XMLStreamWriter. For consistency, using the reader is preferred.
> > > >
> > > > This
> > > >
> > > > > > also
> > > > > > removes Axiom as a dependency making the requirement list
> > > > > > smaller.
> > > > > >
> > > > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can
> > > > > > be
> > > >
> > > > ported
> > > >
> > > > > > back. CXF has a few utilities and such that would be good to
> > > > > > push back and then remove from CXF.
> > > > > >
> > > > > > 5) Once all of that is done, it would open up the door to allow
> > > > > > some
> > > >
> > > > more
> > > >
> > > > > > "common" Policies objects for standard policies. Some could be
> > > > > > in Neethi directly (things like policies objects for
> > > > > > WS-Addressing assertions, mtom stuff, etc...). Others, like
> > > > > > the
> > > > > > WS-SecurityPolicy stuff could either go into Neethi or might be
> > > > > > better in WSS4J. This could help eliminate a BUNCH
> > > > > > of duplicate code between users of Neethi, particularly CXF and
> > > >
> > > > Rampart.
> > > >
> > > > > > (maybe if I keep pushing similar code down into commons, we can
> > > > > > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> > > > > >
> > > > > > 6) Support for WS-Policy 1.5.
> > > > > >
> > > > > > Anyway, if no one really objects to starting the 3.0 work, I'd
> > > > > > like to create
> > > > > > the 2.x branch later this week. Thoughts?
> > > > > >
> > > > > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> > > >
> > > > commons
> > > >
> > > > > > and
> > > > > > not going to an Axis2 TLP.
> > > > > >
> > > > > > --
> > > > > > Daniel Kulp
> > > > > > dkulp@apache.org
> > > > > > http://www.dankulp.com/blog
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org
> > > > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
Since we're going Java 5, the other option COULD be to make the
AssertionBuilder interface something like:
public interface AssertionBuilder<T> {
Assertion build(T element, AssertionBuilderFactory factory)
...
}
where T could be Element, XMLStreamReader, or OEElement (or others in the
future) and do some "magic" in the AssertionBuilderFactory to do conversions
back and forth as needed depending on what the registered Builder requires and
what gets passed in. Quite a bit more complex, but definitely more flexible.
Dan
On Tue June 16 2009 2:41:14 pm Daniel Kulp wrote:
> On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > The way Neethi works is that it basically uses Axiom only to implement
> > the policy-domain specific parser to create the policy-domain specific
> > object model. That is, it is TOTALLY internal.
>
> Not entirely. The PolicyEngine object has public methods like:
> Policy getPolicy(OMElement element)
> that make it NOT totally internal.
>
> > Its of course possible to do without it, but that would make it that much
> > harder to write a security policy parser for example as everything would
> > have to be done directly in StAX instead of Axiom - a tree API is of
> > course easier to deal with than a streaming API.
>
> That's a matter of opinion. I personally find dealing with StAX quite
> easy, but I'm completely used to it by now. :-)
>
> That said, if you want to keep it a tree, I'm QUITE OK with using
> org.w3c.dom.Element. That would make my life MUCH easier as all the CXF
> builders are already using it. :-) I mostly suggested StAX since
> the writers are already using it. Kind of a mirror thing.
>
> > That could could easily be factory'ed away but that would still require
> > CXF and Axis2 to have their own domain specific builders. Have you
> > evaluated the pain level of going down to StAX to do the building?
>
> The main point of what I'm trying to do with 3.0 is to make it so CXF and
> Axis2 don't need their own domain specific builders. We can share the
> policy model objects, the builders that go with them, etc.... For
> example, I know that several of the Rampart builders don't properly record
> some of the attributes into the model. I know cause I fixed them in the
> CXF builders. It would be good to have a single set of builders and models
> where we can both benefit from fixes such as that.
>
> However, that cannot happen until we agree on an API for the builders.
> Using Axiom is a non-starter for me. StAX or DOM Element is OK by me.
> Doesn't matter which. You have a preference between those two? I'd be
> happy either way.
>
> > I'm not sure what MEX impacts here .. Axis2 has a MEX module and there's
> > no overlap/issue with Neethi's parsing model there. What am I missing?
>
> It mostly has to do if you get a Policy as an InputStream (MEX or from a
> Policy repository via REST or similar), what is the most efficient way of
> converting that stream into a usable Policy object. InputStream -> StAX
> -> builders is quite efficient requiring near 0 memory overhead during the
> conversion. However, policy docs are "generally" fairly smallish (unless
> you are really nuts and LOVE policy docs ;-) so doing an InputStream ->
> some infoset model like Axiom/DOM -> builders is really not THAT big of a
> deal.
>
> Dan
>
> > Sanjiva.
> >
> > 2009/6/16 Daniel Kulp <dk...@apache.org>
> >
> > > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > > +1 Dan. Can you clarify #3 a bit please?
> > >
> > > Sure. Basically, in order to make this workable at all (and worth my
> > > time to
> > > proceed down this course), we need to have an API that is palatable by
> > > everyone involved. The PRIMARY reason for the fork of some of the
> > > Neethi stuff in CXF is the Axiom dependency which is not acceptable for
> > > our core use
> > > cases. If that is eliminated, the fork in CXF can go away. There
> > > were two
> > > main options I considered:
> > >
> > > 1) DOM element - this is currently what the CXF version uses. This is
> > > because things like WSDL4J DOM parses extensor elements (by default)
> > > and spring provides configuration things as DOM elements and such.
> > > Thus, it worked best for us. However, for Axis2, that would require
> > > flipping the Axiom stuff over to DOM mode which has performance issues.
> > >
> > > 2) StAX - The proposal below is to use StAX. The Policy objects
> > > themselves
> > > already use StAX for writing XML. Thus, using it to read the xml
> > > would make
> > > it consistent. Also, that makes it pretty easy for both Axis2 and CXF
> > > to work with it. Creating an XMLStreamReader from a DOM or Axiom
> > > thing is "trivial" so whatever path you choose should work fairly well.
> > > Plus, as we
> > > go down the route of WS-MEX and other remote policy retrieval
> > > mechanisms, it
> > > would allow direct StAX streaming. (like directly from the HTTP
> > > InputStream)
> > >
> > > Anyway, switching to StAX seemed to be the most palatable by both
> > > parties. If we can agree on that, then the common policy objects and
> > > stuff can become a
> > > reality.
> > >
> > > Dan
> > >
> > > > Sanjiva.
> > > >
> > > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > > >
> > > > > Some of you have noticed some discussions on WSCOMMONS-299. I've
> > > > > also been
> > > > > thinking about some of those issues and I DID have a discussion
> > > > > with
> > >
> > > Glen
> > >
> > > > > Daniels at TSSJS about the possibility of starting work on a Neethi
> > >
> > > 3.0.
> > >
> > > > > With the comments and stuff on WSCOMMONS-299, it might be time to
> > >
> > > really
> > >
> > > > > start
> > > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for
> > > > > future maintenance and start making trunk 3.0.
> > > > >
> > > > > Things I'd like tackled for 3.0:
> > > > >
> > > > > 1) Java 5 - make the collections and everything typed. Use Enums
> > > > > where appropriate, etc.... Basically, general cleanup. Also, I
> > > > > see that
> > >
> > > many
> > >
> > > > > operations aren't threadsafe due to use of HashMap's with no
> > > > > synchronization.
> > > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > > >
> > > > > 2) Better support for the nested policies as described in
> > >
> > > WSCOMMONS-299.
> > >
> > > > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > > > XMLStreamWriter. For consistency, using the reader is preferred.
> > >
> > > This
> > >
> > > > > also
> > > > > removes Axiom as a dependency making the requirement list smaller.
> > > > >
> > > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
> > >
> > > ported
> > >
> > > > > back. CXF has a few utilities and such that would be good to push
> > > > > back and then remove from CXF.
> > > > >
> > > > > 5) Once all of that is done, it would open up the door to allow
> > > > > some
> > >
> > > more
> > >
> > > > > "common" Policies objects for standard policies. Some could be in
> > > > > Neethi directly (things like policies objects for WS-Addressing
> > > > > assertions, mtom stuff, etc...). Others, like the
> > > > > WS-SecurityPolicy stuff could either go into Neethi or might be
> > > > > better in WSS4J. This could help eliminate a BUNCH
> > > > > of duplicate code between users of Neethi, particularly CXF and
> > >
> > > Rampart.
> > >
> > > > > (maybe if I keep pushing similar code down into commons, we can
> > > > > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> > > > >
> > > > > 6) Support for WS-Policy 1.5.
> > > > >
> > > > > Anyway, if no one really objects to starting the 3.0 work, I'd like
> > > > > to create
> > > > > the 2.x branch later this week. Thoughts?
> > > > >
> > > > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> > >
> > > commons
> > >
> > > > > and
> > > > > not going to an Axis2 TLP.
> > > > >
> > > > > --
> > > > > Daniel Kulp
> > > > > dkulp@apache.org
> > > > > http://www.dankulp.com/blog
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
2009/6/17 Daniel Kulp <dk...@apache.org>
> On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> > The way Neethi works is that it basically uses Axiom only to implement
> the
> > policy-domain specific parser to create the policy-domain specific object
> > model. That is, it is TOTALLY internal.
>
> Not entirely. The PolicyEngine object has public methods like:
> Policy getPolicy(OMElement element)
> that make it NOT totally internal.
That can be fixed easily ... that can be moved to a utility.
That's a matter of opinion. I personally find dealing with StAX quite easy,
> but I'm completely used to it by now. :-)
>
> That said, if you want to keep it a tree, I'm QUITE OK with using
> org.w3c.dom.Element. That would make my life MUCH easier as all the CXF
> builders are already using it. :-) I mostly suggested StAX since
> the
> writers are already using it. Kind of a mirror thing.
I'm afraid DOM is not an option from an Axis2 point of view. We're trying to
get away from it in order to achieve better performance - Rampart2 being one
of those efforts.
> That could could easily be factory'ed away but that would still require
> CXF
> > and Axis2 to have their own domain specific builders. Have you evaluated
> > the pain level of going down to StAX to do the building?
>
> The main point of what I'm trying to do with 3.0 is to make it so CXF and
> Axis2 don't need their own domain specific builders. We can share the
> policy
> model objects, the builders that go with them, etc.... For example, I
> know
> that several of the Rampart builders don't properly record some of the
> attributes into the model. I know cause I fixed them in the CXF builders.
> It would be good to have a single set of builders and models where we can
> both
> benefit from fixes such as that.
Absolutely +1 if we can achieve that.
However, that cannot happen until we agree on an API for the builders.
> Using
> Axiom is a non-starter for me. StAX or DOM Element is OK by me. Doesn't
> matter which. You have a preference between those two? I'd be happy
> either
> way.
If you're willing to rewrite all the current domain specific builders using
straight StAX and not Axiom that's ok but there's a lot of those in security
policy :). I'd rather not.
PolicyEngine is really a policy builder class. That could be moved to a util
package and devalued to what it is - a way to build a model. By doing that
we can avoid a hard coded Axiom dependency and yet share the domain specific
models etc, even if not the builders.
> I'm not sure what MEX impacts here .. Axis2 has a MEX module and there's
no
> overlap/issue with Neethi's parsing model there. What am I missing?
It mostly has to do if you get a Policy as an InputStream (MEX or from a
> Policy repository via REST or similar), what is the most efficient way of
> converting that stream into a usable Policy object. InputStream -> StAX
> ->
> builders is quite efficient requiring near 0 memory overhead during the
> conversion. However, policy docs are "generally" fairly smallish (unless
> you
> are really nuts and LOVE policy docs ;-) so doing an InputStream -> some
> infoset model like Axiom/DOM -> builders is really not THAT big of a deal.
Yeah its usually not a big deal and often these are cached after first hit.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Tue June 16 2009 10:32:50 am Sanjiva Weerawarana wrote:
> The way Neethi works is that it basically uses Axiom only to implement the
> policy-domain specific parser to create the policy-domain specific object
> model. That is, it is TOTALLY internal.
Not entirely. The PolicyEngine object has public methods like:
Policy getPolicy(OMElement element)
that make it NOT totally internal.
> Its of course possible to do without it, but that would make it that much
> harder to write a security policy parser for example as everything would
> have to be done directly in StAX instead of Axiom - a tree API is of course
> easier to deal with than a streaming API.
That's a matter of opinion. I personally find dealing with StAX quite easy,
but I'm completely used to it by now. :-)
That said, if you want to keep it a tree, I'm QUITE OK with using
org.w3c.dom.Element. That would make my life MUCH easier as all the CXF
builders are already using it. :-) I mostly suggested StAX since the
writers are already using it. Kind of a mirror thing.
> That could could easily be factory'ed away but that would still require CXF
> and Axis2 to have their own domain specific builders. Have you evaluated
> the pain level of going down to StAX to do the building?
The main point of what I'm trying to do with 3.0 is to make it so CXF and
Axis2 don't need their own domain specific builders. We can share the policy
model objects, the builders that go with them, etc.... For example, I know
that several of the Rampart builders don't properly record some of the
attributes into the model. I know cause I fixed them in the CXF builders.
It would be good to have a single set of builders and models where we can both
benefit from fixes such as that.
However, that cannot happen until we agree on an API for the builders. Using
Axiom is a non-starter for me. StAX or DOM Element is OK by me. Doesn't
matter which. You have a preference between those two? I'd be happy either
way.
> I'm not sure what MEX impacts here .. Axis2 has a MEX module and there's no
> overlap/issue with Neethi's parsing model there. What am I missing?
It mostly has to do if you get a Policy as an InputStream (MEX or from a
Policy repository via REST or similar), what is the most efficient way of
converting that stream into a usable Policy object. InputStream -> StAX ->
builders is quite efficient requiring near 0 memory overhead during the
conversion. However, policy docs are "generally" fairly smallish (unless you
are really nuts and LOVE policy docs ;-) so doing an InputStream -> some
infoset model like Axiom/DOM -> builders is really not THAT big of a deal.
Dan
> Sanjiva.
>
> 2009/6/16 Daniel Kulp <dk...@apache.org>
>
> > On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > > +1 Dan. Can you clarify #3 a bit please?
> >
> > Sure. Basically, in order to make this workable at all (and worth my
> > time to
> > proceed down this course), we need to have an API that is palatable by
> > everyone involved. The PRIMARY reason for the fork of some of the
> > Neethi stuff in CXF is the Axiom dependency which is not acceptable for
> > our core use
> > cases. If that is eliminated, the fork in CXF can go away. There
> > were two
> > main options I considered:
> >
> > 1) DOM element - this is currently what the CXF version uses. This is
> > because things like WSDL4J DOM parses extensor elements (by default) and
> > spring provides configuration things as DOM elements and such. Thus,
> > it worked best for us. However, for Axis2, that would require flipping
> > the Axiom stuff over to DOM mode which has performance issues.
> >
> > 2) StAX - The proposal below is to use StAX. The Policy objects
> > themselves
> > already use StAX for writing XML. Thus, using it to read the xml would
> > make
> > it consistent. Also, that makes it pretty easy for both Axis2 and CXF
> > to work with it. Creating an XMLStreamReader from a DOM or Axiom thing
> > is "trivial" so whatever path you choose should work fairly well.
> > Plus, as we
> > go down the route of WS-MEX and other remote policy retrieval mechanisms,
> > it
> > would allow direct StAX streaming. (like directly from the HTTP
> > InputStream)
> >
> > Anyway, switching to StAX seemed to be the most palatable by both
> > parties. If we can agree on that, then the common policy objects and
> > stuff can become a
> > reality.
> >
> > Dan
> >
> > > Sanjiva.
> > >
> > > 2009/6/15 Daniel Kulp <dk...@apache.org>
> > >
> > > > Some of you have noticed some discussions on WSCOMMONS-299. I've
> > > > also been
> > > > thinking about some of those issues and I DID have a discussion with
> >
> > Glen
> >
> > > > Daniels at TSSJS about the possibility of starting work on a Neethi
> >
> > 3.0.
> >
> > > > With the comments and stuff on WSCOMMONS-299, it might be time to
> >
> > really
> >
> > > > start
> > > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> > > > maintenance and start making trunk 3.0.
> > > >
> > > > Things I'd like tackled for 3.0:
> > > >
> > > > 1) Java 5 - make the collections and everything typed. Use Enums
> > > > where appropriate, etc.... Basically, general cleanup. Also, I see
> > > > that
> >
> > many
> >
> > > > operations aren't threadsafe due to use of HashMap's with no
> > > > synchronization.
> > > > Possibly fix those with ConcurrentHashMaps or similar.
> > > >
> > > > 2) Better support for the nested policies as described in
> >
> > WSCOMMONS-299.
> >
> > > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > > XMLStreamWriter. For consistency, using the reader is preferred.
> >
> > This
> >
> > > > also
> > > > removes Axiom as a dependency making the requirement list smaller.
> > > >
> > > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
> >
> > ported
> >
> > > > back. CXF has a few utilities and such that would be good to push
> > > > back and then remove from CXF.
> > > >
> > > > 5) Once all of that is done, it would open up the door to allow some
> >
> > more
> >
> > > > "common" Policies objects for standard policies. Some could be in
> > > > Neethi directly (things like policies objects for WS-Addressing
> > > > assertions, mtom stuff, etc...). Others, like the
> > > > WS-SecurityPolicy stuff could either go into Neethi or might be
> > > > better in WSS4J. This could help eliminate a BUNCH
> > > > of duplicate code between users of Neethi, particularly CXF and
> >
> > Rampart.
> >
> > > > (maybe if I keep pushing similar code down into commons, we can have
> > > > a big merger in the future. Acxfis 3? Maybe not. :-) )
> > > >
> > > > 6) Support for WS-Policy 1.5.
> > > >
> > > > Anyway, if no one really objects to starting the 3.0 work, I'd like
> > > > to create
> > > > the 2.x branch later this week. Thoughts?
> > > >
> > > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> >
> > commons
> >
> > > > and
> > > > not going to an Axis2 TLP.
> > > >
> > > > --
> > > > Daniel Kulp
> > > > dkulp@apache.org
> > > > http://www.dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
The way Neethi works is that it basically uses Axiom only to implement the
policy-domain specific parser to create the policy-domain specific object
model. That is, it is TOTALLY internal.
Its of course possible to do without it, but that would make it that much
harder to write a security policy parser for example as everything would
have to be done directly in StAX instead of Axiom - a tree API is of course
easier to deal with than a streaming API.
That could could easily be factory'ed away but that would still require CXF
and Axis2 to have their own domain specific builders. Have you evaluated the
pain level of going down to StAX to do the building?
I'm not sure what MEX impacts here .. Axis2 has a MEX module and there's no
overlap/issue with Neethi's parsing model there. What am I missing?
Sanjiva.
2009/6/16 Daniel Kulp <dk...@apache.org>
>
>
> On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> > +1 Dan. Can you clarify #3 a bit please?
>
> Sure. Basically, in order to make this workable at all (and worth my time
> to
> proceed down this course), we need to have an API that is palatable by
> everyone involved. The PRIMARY reason for the fork of some of the Neethi
> stuff in CXF is the Axiom dependency which is not acceptable for our core
> use
> cases. If that is eliminated, the fork in CXF can go away. There were
> two
> main options I considered:
>
> 1) DOM element - this is currently what the CXF version uses. This is
> because things like WSDL4J DOM parses extensor elements (by default) and
> spring provides configuration things as DOM elements and such. Thus, it
> worked best for us. However, for Axis2, that would require flipping the
> Axiom stuff over to DOM mode which has performance issues.
>
> 2) StAX - The proposal below is to use StAX. The Policy objects
> themselves
> already use StAX for writing XML. Thus, using it to read the xml would
> make
> it consistent. Also, that makes it pretty easy for both Axis2 and CXF to
> work with it. Creating an XMLStreamReader from a DOM or Axiom thing is
> "trivial" so whatever path you choose should work fairly well. Plus, as
> we
> go down the route of WS-MEX and other remote policy retrieval mechanisms,
> it
> would allow direct StAX streaming. (like directly from the HTTP
> InputStream)
>
> Anyway, switching to StAX seemed to be the most palatable by both parties.
> If we can agree on that, then the common policy objects and stuff can
> become a
> reality.
>
> Dan
>
>
> > Sanjiva.
> >
> > 2009/6/15 Daniel Kulp <dk...@apache.org>
> >
> > > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > > been
> > > thinking about some of those issues and I DID have a discussion with
> Glen
> > > Daniels at TSSJS about the possibility of starting work on a Neethi
> 3.0.
> > > With the comments and stuff on WSCOMMONS-299, it might be time to
> really
> > > start
> > > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> > > maintenance and start making trunk 3.0.
> > >
> > > Things I'd like tackled for 3.0:
> > >
> > > 1) Java 5 - make the collections and everything typed. Use Enums where
> > > appropriate, etc.... Basically, general cleanup. Also, I see that
> many
> > > operations aren't threadsafe due to use of HashMap's with no
> > > synchronization.
> > > Possibly fix those with ConcurrentHashMaps or similar.
> > >
> > > 2) Better support for the nested policies as described in
> WSCOMMONS-299.
> > >
> > > 3) Change the builders to use XMLStreamReader. The Policies use
> > > XMLStreamWriter. For consistency, using the reader is preferred.
> This
> > > also
> > > removes Axiom as a dependency making the requirement list smaller.
> > >
> > > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be
> ported
> > > back. CXF has a few utilities and such that would be good to push back
> > > and then remove from CXF.
> > >
> > > 5) Once all of that is done, it would open up the door to allow some
> more
> > > "common" Policies objects for standard policies. Some could be in
> > > Neethi directly (things like policies objects for WS-Addressing
> > > assertions, mtom stuff, etc...). Others, like the WS-SecurityPolicy
> > > stuff could either go into Neethi or might be better in WSS4J. This
> > > could help eliminate a BUNCH
> > > of duplicate code between users of Neethi, particularly CXF and
> Rampart.
> > > (maybe if I keep pushing similar code down into commons, we can have a
> > > big merger in the future. Acxfis 3? Maybe not. :-) )
> > >
> > > 6) Support for WS-Policy 1.5.
> > >
> > > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > > create
> > > the 2.x branch later this week. Thoughts?
> > >
> > > BTW: This is also why I STRONGLY am in favor of Neethi staying in
> commons
> > > and
> > > not going to an Axis2 TLP.
> > >
> > > --
> > > Daniel Kulp
> > > dkulp@apache.org
> > > http://www.dankulp.com/blog
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
On Tue June 16 2009 1:41:25 am Sanjiva Weerawarana wrote:
> +1 Dan. Can you clarify #3 a bit please?
Sure. Basically, in order to make this workable at all (and worth my time to
proceed down this course), we need to have an API that is palatable by
everyone involved. The PRIMARY reason for the fork of some of the Neethi
stuff in CXF is the Axiom dependency which is not acceptable for our core use
cases. If that is eliminated, the fork in CXF can go away. There were two
main options I considered:
1) DOM element - this is currently what the CXF version uses. This is
because things like WSDL4J DOM parses extensor elements (by default) and
spring provides configuration things as DOM elements and such. Thus, it
worked best for us. However, for Axis2, that would require flipping the
Axiom stuff over to DOM mode which has performance issues.
2) StAX - The proposal below is to use StAX. The Policy objects themselves
already use StAX for writing XML. Thus, using it to read the xml would make
it consistent. Also, that makes it pretty easy for both Axis2 and CXF to
work with it. Creating an XMLStreamReader from a DOM or Axiom thing is
"trivial" so whatever path you choose should work fairly well. Plus, as we
go down the route of WS-MEX and other remote policy retrieval mechanisms, it
would allow direct StAX streaming. (like directly from the HTTP InputStream)
Anyway, switching to StAX seemed to be the most palatable by both parties.
If we can agree on that, then the common policy objects and stuff can become a
reality.
Dan
> Sanjiva.
>
> 2009/6/15 Daniel Kulp <dk...@apache.org>
>
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been
> > thinking about some of those issues and I DID have a discussion with Glen
> > Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> > With the comments and stuff on WSCOMMONS-299, it might be time to really
> > start
> > it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> > maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization.
> > Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also
> > removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> > and then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> > Neethi directly (things like policies objects for WS-Addressing
> > assertions, mtom stuff, etc...). Others, like the WS-SecurityPolicy
> > stuff could either go into Neethi or might be better in WSS4J. This
> > could help eliminate a BUNCH
> > of duplicate code between users of Neethi, particularly CXF and Rampart.
> > (maybe if I keep pushing similar code down into commons, we can have a
> > big merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create
> > the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and
> > not going to an Axis2 TLP.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: Neethi 3.0
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1 Dan. Can you clarify #3 a bit please?
Sanjiva.
2009/6/15 Daniel Kulp <dk...@apache.org>
>
> Some of you have noticed some discussions on WSCOMMONS-299. I've also
> been
> thinking about some of those issues and I DID have a discussion with Glen
> Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> With the comments and stuff on WSCOMMONS-299, it might be time to really
> start
> it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no
> synchronization.
> Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This
> also
> removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a
> BUNCH
> of duplicate code between users of Neethi, particularly CXF and Rampart.
> (maybe if I keep pushing similar code down into commons, we can have a big
> merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to
> create
> the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> and
> not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sanjiva Weerawarana, Ph.D.
Founder, Director & Chief Scientist; Lanka Software Foundation;
http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
Blog: http://sanjiva.weerawarana.org/
Re: Neethi 3.0
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
-- dims
On 06/15/2009 10:49 AM, Daniel Kulp wrote:
> Some of you have noticed some discussions on WSCOMMONS-299. I've also been
> thinking about some of those issues and I DID have a discussion with Glen
> Daniels at TSSJS about the possibility of starting work on a Neethi 3.0.
> With the comments and stuff on WSCOMMONS-299, it might be time to really start
> it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for future
> maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no synchronization.
> Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This also
> removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a BUNCH
> of duplicate code between users of Neethi, particularly CXF and Rampart.
> (maybe if I keep pushing similar code down into commons, we can have a big
> merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to create
> the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons and
> not going to an Axis2 TLP.
>
Re: Neethi 3.0
Posted by Sameera Jayasoma <sa...@gmail.com>.
Hi Dan,
I would like to contribute to the neethi 3.0. Let me know if you need any
help in OSGifying Neethi.
Thanks
Sameera.
On Mon, Jun 22, 2009 at 10:09 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> There definitely doesn't seem to be any reservations about branching a 2.x
> branch and starting work on 3.0. Thus, I'm going to go ahead and do that.
>
> Dan
>
>
>
> On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> > Some of you have noticed some discussions on WSCOMMONS-299. I've also
> > been thinking about some of those issues and I DID have a discussion with
> > Glen Daniels at TSSJS about the possibility of starting work on a Neethi
> > 3.0. With the comments and stuff on WSCOMMONS-299, it might be time to
> > really start it. Thus, I'd like to "svn cp" the trunk to a 2.x branch
> for
> > future maintenance and start making trunk 3.0.
> >
> > Things I'd like tackled for 3.0:
> >
> > 1) Java 5 - make the collections and everything typed. Use Enums where
> > appropriate, etc.... Basically, general cleanup. Also, I see that many
> > operations aren't threadsafe due to use of HashMap's with no
> > synchronization. Possibly fix those with ConcurrentHashMaps or similar.
> >
> > 2) Better support for the nested policies as described in WSCOMMONS-299.
> >
> > 3) Change the builders to use XMLStreamReader. The Policies use
> > XMLStreamWriter. For consistency, using the reader is preferred. This
> > also removes Axiom as a dependency making the requirement list smaller.
> >
> > 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> > back. CXF has a few utilities and such that would be good to push back
> and
> > then remove from CXF.
> >
> > 5) Once all of that is done, it would open up the door to allow some more
> > "common" Policies objects for standard policies. Some could be in
> Neethi
> > directly (things like policies objects for WS-Addressing assertions, mtom
> > stuff, etc...). Others, like the WS-SecurityPolicy stuff could either
> go
> > into Neethi or might be better in WSS4J. This could help eliminate a
> > BUNCH of duplicate code between users of Neethi, particularly CXF and
> > Rampart. (maybe if I keep pushing similar code down into commons, we can
> > have a big merger in the future. Acxfis 3? Maybe not. :-) )
> >
> > 6) Support for WS-Policy 1.5.
> >
> > Anyway, if no one really objects to starting the 3.0 work, I'd like to
> > create the 2.x branch later this week. Thoughts?
> >
> > BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> > and not going to an Axis2 TLP.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
--
Sameera Jayasoma
Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
blog: http://tech.jayasoma.org
Re: Neethi 3.0
Posted by Daniel Kulp <dk...@apache.org>.
There definitely doesn't seem to be any reservations about branching a 2.x
branch and starting work on 3.0. Thus, I'm going to go ahead and do that.
Dan
On Mon June 15 2009 10:49:59 am Daniel Kulp wrote:
> Some of you have noticed some discussions on WSCOMMONS-299. I've also
> been thinking about some of those issues and I DID have a discussion with
> Glen Daniels at TSSJS about the possibility of starting work on a Neethi
> 3.0. With the comments and stuff on WSCOMMONS-299, it might be time to
> really start it. Thus, I'd like to "svn cp" the trunk to a 2.x branch for
> future maintenance and start making trunk 3.0.
>
> Things I'd like tackled for 3.0:
>
> 1) Java 5 - make the collections and everything typed. Use Enums where
> appropriate, etc.... Basically, general cleanup. Also, I see that many
> operations aren't threadsafe due to use of HashMap's with no
> synchronization. Possibly fix those with ConcurrentHashMaps or similar.
>
> 2) Better support for the nested policies as described in WSCOMMONS-299.
>
> 3) Change the builders to use XMLStreamReader. The Policies use
> XMLStreamWriter. For consistency, using the reader is preferred. This
> also removes Axiom as a dependency making the requirement list smaller.
>
> 4) With (3) fixed, most of the Neethi "fork" we have in CXF can be ported
> back. CXF has a few utilities and such that would be good to push back and
> then remove from CXF.
>
> 5) Once all of that is done, it would open up the door to allow some more
> "common" Policies objects for standard policies. Some could be in Neethi
> directly (things like policies objects for WS-Addressing assertions, mtom
> stuff, etc...). Others, like the WS-SecurityPolicy stuff could either go
> into Neethi or might be better in WSS4J. This could help eliminate a
> BUNCH of duplicate code between users of Neethi, particularly CXF and
> Rampart. (maybe if I keep pushing similar code down into commons, we can
> have a big merger in the future. Acxfis 3? Maybe not. :-) )
>
> 6) Support for WS-Policy 1.5.
>
> Anyway, if no one really objects to starting the 3.0 work, I'd like to
> create the 2.x branch later this week. Thoughts?
>
> BTW: This is also why I STRONGLY am in favor of Neethi staying in commons
> and not going to an Axis2 TLP.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog