You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Scott Eade <se...@backstagetech.com.au> on 2002/09/09 14:51:12 UTC
Re: Attn Henning: Fulcrum SecurityService proposal
Note: This discussion began over on turbine-torque-dev when it rightly
belongs here on turbine-user.
Hi Henning,
My comments inline as well as at the bottom.
> From: "Henning P. Schmiedehausen" <hp...@intermeta.de>
>
>> Scott Eade <se...@backstagetech.com.au> writes:
>
>> Henning,
<snip>
>> 1. Can you please summarise the changes that your code introduces? I am
>> particularly interested in knowing how this affects the ability to extend
>> the TurbineUser table.
>
> the most important change is the decoupling of the Torque table
> description and the resulting Peers and Objects from the Security
> Object implementations. You still get the Peers and Torque Objects,
> but the service itself works with the DBGroup, DBUser, DBRole and
> DBPermission objects (which are the only ones visible to the
> application) and maps their fields to the Torque objects with the Peer
> Managers (UserPeerManager, GroupPeerManager..., you get the idea). All
> this mapping is done by Introspection and completely transparent to
> the Turbine / Fulcrum application.
>
> You can configure all the column names, the tables and the objects in
> the Fulcrum.properties. We e.g. use it all the time of an application
> which extends the Security System to the notion of "Accounts in
> Groups" which map onto Turbine Users. We need additional fields in the
> tables and simply add them, change the class definitions of the Torque
> objects in Fulcrum and then "extend" the Security Objects as described
> in the db-security-service.xml howto in the proposal.
Sounds very useful.
>
>> 2. What is the status of your proposal? It looks to me like the code would
>> have been moved from a proposal to the actual implementation by now, except
>> that there may have been some concern with regards to other suggested work
>> on the security service (which doesn't seem to have materialized).
>
> Well, that's a tough question. The code itself works fine for us. I
> think that many other projects (like Jetspeed or Scarab, which use the
> Turbine security service, too) could benefit greatly from it. I do
> have some more changes (mainly feature additions) and a few bug fixes
> added which aren't in the jakarta repository yet. If you want them, I can
> send it to you. Contact me directly via mail.
I most certainly will.
>
> I do have another massive change to the security service, though,
> which was absolutely necessary for the scaling of our application. I
> ripped out the current SecuritySet (GroupSet, RoleSet, PermissionSet)
> implementation which sucks rocks when it comes to
> groupSet.getGroup(groupName) and replaced it with a Map-based
> implementation which allows very fast lookup of name and
> id. Unfortunately this change would affect the SecurityService
> interface. No problem for our inhouse solution; big problem for the
> Fulcrum code itself (but then again, we don't have a release yet :-) )
It appears to me that backwards compatibility (at least on a micro scale)
has gone out the window between turbine 2.1/2.2/torque 3.0/et al.
>
> If you don't want to read about my opinion on apache project politics,
> skip down now. You will find an example of how to expand the user
> object. :-)
>
> <mode="rant">
>
> So now, you ask me: "If this is all so great, why isn't it in the CVS
> repository, yet". Basically, the reason for this, is the fact that
> many of my co-developers consider Turbine a "playground" for other
> things. I consider Turbine the base of many of our applications and
> I'm absolutely furious that things like the building process got
> crushed for no reason and that for people that can't upgrade to the
> lastest and greatest development tools every other morning, Turbine
> and Fulcrum got broken again and again. When pointing this out, I got
> told from one developer that "he's absolutely ready to take the fire
> and does not care about it. He considers himself on the right way and
> is ready to take some heat to show everybody that he's right. And the
> book isn't ready yet (whatever this means)".
>
> I'm unhappy about the decision making process in the projects, some
> seem to be considered the personal "property" of some developers
> ("Fulcrum? Ah, let's screw Fulcrum, there is something else around the
> bend. User base? We have no user base, because we have no
> releases. Making a release? Ah no, let's not make a release, there are
> some things, that will be eterenally changed and if we make a release,
> we might get a user base and then we can't screw around with the stuff
> like we used to do all the time").
>
> I voted down the change to Maven B5 with a long explanation just as
> required in http://jakarta.apache.org/site/decisions.html. This -1 got
> ignored by some people with a "this is my stuff, I don't care about
> other developers, votes suck if they don't go my way" attitude.
I witnessed the splatter of the dialogue to which you refer. While it did
seem to me that it would have been achievable to maintain concurrent build
systems for ant/maven-b4 and maven-b5/6, at the time I was seeing several
discrepancies between just the ant and maven-b4 configurations - adding
another flavour to this mix was only going to make the situation worse. Of
course a major part of the problem is as you refer to, the constant jumping
forward to new versions of dependencies - while maven seeks to make this
easy there are still wrinkles in the process and just because there is a new
development build of some dependency doesn't mean it should be used. This
is a case where a policy of some kind needs to be developed and followed (I
guess here is not really the place to discuss this).
>
> According to the apache guidelines, -1 votes with a reason are
> considered a "veto" which must be resolved. Some developers seem to
> have decided that "this would be a waste of time" and simply ignored
> it. One considered "Fuck Henning" on IRC to be a reasonable reaction
> to the veto. And that was it.
Hmm. I saw that too and was curious as to how it would be resolved. It
seems to me that this is a flaw with how this type of voting works - unless
all of the committers enforce the rules against the person making the change
regardless of their individual position on the subject being voted upon then
a -1 becomes worthless.
>
> So at the moment, I don't waste my time with people who treat
> community projects like it is their personal ~/scratch directory. I
> wait till Turbine and/or Fulcrum will stabilize and maybe one day we
> might even get releases of 'irrelevant things like the central build
> tool'. But then again, maybe not.
It seems to me that development on turbine itself (along with most of the
sub-components) is at a near standstill (either that or some pretty big
commits are going to appear at some stage) because some of the major
developers are currently absorbed by maven. I am actually really excited by
maven but I am totally not going to adopt it until there is a final release
- there have been just too many major revisions to jump in just yet. The
thing that is killing me is that I have some torque patches in the queue
(and further ones locally) that are not being committed because a new
testing framework is in the pipeline that requires... you guessed it,
maven-b7 ;-)
>
> We at INTERMETA have our internal CVS development tree and thanks to
> the Apache License I'm neither required nor forced to put our changes
> back into the main tree. I'd like to, but at the moment it would be a
> waste of time which I don't have.
>
> At the moment, our internal Fulcrum build tree differs from the jakarta one
> by about 16.800 lines of code:
>
> % cvs export -r HEAD -kk fulcrum > & /dev/null
> % cvs -d :ext:henning@cvs.apache.org:/home/cvspublic export -r HEAD -kk
> jakarta-turbine-fulcrum >& /dev/null
> % diff -Nurb jakarta-turbine-fulcrum/src/java fulcrum/src/java | wc -l
> 16817
>
> which splits down to
>
> Security Service 12946 lines
> Intake 1830 lines
> other stuff 2041 lines
>
> it would be moot to merge it to get told "I blow this away next
> week. No, I don't care about your concerns. Did you test BTW
> fooDevelop 0.0.2-snap-19700802.0824 from <some obscure server outside
> apache.org>? There are no docs about it, but you surely have lots of
> free time at hand to rework your 250 KLOC to work with it. Ah yes, and
> we will move the whole building process over to this tool in about 15
> minutes".
>
> We're at the moment running a stripped down Turbine-2 with fully
> integrated Fulcrum; remaining Turbine-2 services ported to Fulcrum and
> running under the Fulcrum Service broker.
>
> Everything uses commons.logging for its logging purposes and logging
> is integrated and centralized into Log4J (No more fscking LogService,
> which was a bad idea from the beginning anyway).
>
> We use an intake service which is able to use multiple XML files
> (Which is very important to us, because we use a module system where
> every module of our application registers itself as a Turbine service
> and contains its own intake files).
>
> I do intend to put all of this stuff back into Turbine-2, once 2.2
> _is_ released and we have a definite idea where to move with Fulcrum
> besides "let's blow it away and maybe we can use an Avalon container
> for it at some point". At the moment, I'm more concerned with getting our
> application to ship.
The "blow it away comments" freak me out as there seems to be no clearly
articulated strategy (apart from the "Avalon container" references which it
would seem only a few people are in the know about.
>
> </rant>
It is great that despite all this you still intend contributing these
enhancements.
>
>> Of concern to me is the difficulty in extending TurbineUser. I need to be
>> able to do this before I can migrate to turbine 2.2. Judging by the list
>> activity this is of critical importance to many others also. I am happy to
>> contribute to this effort in terms of documentation or whatever else is
>> necessary (time permitting).
>
> Docs should be included in the proposal. You basically do it like this:
>
> --- your-torque-schema.xml ---
> <table name="MY_USER" idMethod="idbroker">
> <!-- Standard Turbine Columns. Definitions just like the original Turbine for
> the sake of readability -->
> <column name="USER_ID" type="INTEGER" required="true"
> primaryKey="true" />
> <column name="LOGIN_NAME" type="VARCHAR" required="true" size="64"
> javaName="UserName"/>
> <column name="PASSWORD_VALUE" type="VARCHAR" required="true" size="16"
> javaName="Password"/>
> <column name="MODIFIED" type="TIMESTAMP"/>
> <column name="CREATED" type="TIMESTAMP"
> javaName="CreateDate"/>
> <column name="LAST_LOGIN" type="TIMESTAMP"/>
>
> <!-- (Putting these into the basic table was a fscking bad idea but we have
> to live with it, now) -->
> <column name="FIRST_NAME" type="VARCHAR" required="true" size="64" />
> <column name="LAST_NAME" type="VARCHAR" required="true" size="64" />
> <column name="EMAIL" type="VARCHAR" size="64" />
> <column name="CONFIRM_VALUE" type="VARCHAR" size="16"
> javaName="Confirmed"/>
> <column name="OBJECTDATA" type="VARBINARY"/>
>
> <!-- ****** Your Custom columns ***** -->
>
> <column name="MY_DATA type="VARCHAR" size="32" javaName="Data" />
> <column name="MY_INTEGER type="INTEGER" javaName="Value" />
>
> <unique>
> <unique-column name="LOGIN_NAME"/>
> </unique>
>
> </table>
> --- your-torque-schema.xml ---
>
> Now you build a torque object with your schema. You should get MyUser
> and MyUserPeer (names may vary according to the class creation policy
> that you configured for torque but you get the idea).
>
> Configure this to be your User class in the _DB_ Service (please note
> the DB!):
[Typo in the above sentence has been fixed.]
>
> --- Fulcrum.properties ---
> services.SecurityService.db.userPeer.class = com.mycompany.om.MyUserPeer
> --- Fulcrum.properties ---
>
> You don't _need_ any more properties, because everything else will be
> retrieved either with Introspection from the peer object or the
> defaults will be used, which is fine, because we copied the
> definition of the stock Turbine table.
>
> If you explicitly want to configure everything, you can use the
> following properties:
>
> --- Fulcrum.properties ---
> #
> # These are the defaults for the colum names in the Peer Object
> #
> services.SecurityService.db.userPeer.column.name = LOGIN_NAME
> services.SecurityService.db.userPeer.column.id = USER_ID
> services.SecurityService.db.userPeer.column.password = PASSWORD_VALUE
> services.SecurityService.db.userPeer.column.firstname = FIRST_NAME
> services.SecurityService.db.userPeer.column.lastname = LAST_NAME
> services.SecurityService.db.userPeer.column.email = EMAIL
> services.SecurityService.db.userPeer.column.confirm = CONFIRM_VALUE
> services.SecurityService.db.userPeer.column.createdate = CREATED
> services.SecurityService.db.userPeer.column.lastlogin = LAST_LOGIN
> services.SecurityService.db.userPeer.column.objectdata = OBJECTDATA
>
> #
> # This is the class of the Torque objects returned by the Peer. If
> # it is omitted, the class name is queried from the configured Peer.
> #
> services.SecurityService.db.user.class = com.mycompany.om.MyUser
>
> #
> # These are the bean properties for the required fields from the
> # Torque objects. If omitted, these defaults are used:
> #
> services.SecurityService.db.user.property.name = UserName
> services.SecurityService.db.user.property.id = UserId
> services.SecurityService.db.user.property.password = Password
> services.SecurityService.db.user.property.firstname = FirstName
> services.SecurityService.db.user.property.lastname = LastName
> services.SecurityService.db.user.property.email = Email
> services.SecurityService.db.user.property.confirm = Confirmed
> services.SecurityService.db.user.property.createdate = CreateDate
> services.SecurityService.db.user.property.lastlogin = LastLogin
> services.SecurityService.db.user.property.objectdata = Objectdata
> --- Fulcrum.properties ---
>
>
> Ok, now you ask yourself: "How can I access "MY_DATA" and
> "MY_INTEGER"?. You simply write yourself a new class which extends the
> implementation object from the database service:
>
> --- cut ---
> package com.mycompany.security;
>
> import org.apache.fulcrum.security.impl.db.DBUser;
> import org.apache.fulcrum.security.entity.User;
>
> import com.mycompany.om.MyUser;
>
> public class MyDbUser
> extends DBUser
> implements User
> {
> public MyDbUser()
> {
> super();
> }
>
> public String getData()
> {
> return ((MyUser) getPersistentObj()).getData();
> }
>
> public int getValue()
> {
> return ((MyUser) getPersistentObj()).getValue();
> }
>
> public void setData(String data)
> {
> ((MyUser) getPersistentObj()).setData(data);
> }
>
> public void setValue(int value)
> {
> ((MyUser) getPersistentObj()).setValue(value);
> }
> }
> --- cut ---
>
> and now (here comes the trick!), you tell the SecurityService (note
> the absence of DB! This is the main security service and this trick is
> not dependent on the DB Security Service!) no longer to return its
> default User-implementation objects but your very own MyDbUser
> objects:
>
> --- Fulcrum.properties ---
> #
> # Tell the security service to return objects of this type as objects
> # implementing the User interface.
> #
> services.SecurityService.user.class = com.mycompany.security.MyDbUser
> --- Fulcrum.properties ---
>
> and in your code you write
>
> MyDbUser myDbUser = (MyDbUser) TurbineSecurity.getUser("test");
> String data = myDbUser.getData();
>
> That's it. If you need to change your Peer objects, no more
> recompiling of Fulcrum or Turbine. Change them, extend your Custom
> MyDbUser class, deploy. Works. You should've seen some of the loops we
> went through before we got this... :-)
Most excellent. I hope to have time to explore this very soon.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
> D-91054 Buckenhof Fax.: 09131 / 50654-20
Henning, that was just the best response to any question I have ever seen on
the list (and your rant provides some useful background information too). I
will drop you a note directly requesting the further enhancements/fixes to
your security service proposal.
Good luck shipping your application and I do hope we see you back in the
thick of things when the dust settles.
Cheers,
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attn Henning: Fulcrum SecurityService proposal
Posted by Rodney Schneider <ro...@actf.com.au>.
On Mon, 9 Sep 2002 22:51, you wrote:
> > I do have another massive change to the security service, though,
> > which was absolutely necessary for the scaling of our application. I
> > ripped out the current SecuritySet (GroupSet, RoleSet, PermissionSet)
> > implementation which sucks rocks when it comes to
> > groupSet.getGroup(groupName) and replaced it with a Map-based
> > implementation which allows very fast lookup of name and
> > id. Unfortunately this change would affect the SecurityService
> > interface. No problem for our inhouse solution; big problem for the
> > Fulcrum code itself (but then again, we don't have a release yet :-) )
>
> It appears to me that backwards compatibility (at least on a micro scale)
> has gone out the window between turbine 2.1/2.2/torque 3.0/et al.
I tend to agree... I think that Turbine 2.2 is already incompatible with
Turbine 2.1 in many ways and Turbine 3.x is even worse in this respect. I
know that Jason did a lot of work cleaning up the RunData interface for
Turbine 3.x and there are some other other changes that need to be made to
clean up the various interfaces in Turbine 2.x and to clean up the Turbine
2.x API as a whole.
However, perhaps it would be better to leave many of these API changes to
Turbine 2.3? While I think your changes to the current SecuritySet
implementation are valuable, I am not sure whether they should be integrated
into Turbine 2.2 right now. However, IMHO the other changes in your
SecurityService proposal would be useful immediately and would not make
Turbine 2.2 less backwards compatible than it already is.
> > According to the apache guidelines, -1 votes with a reason are
> > considered a "veto" which must be resolved. Some developers seem to
> > have decided that "this would be a waste of time" and simply ignored
> > it. One considered "Fuck Henning" on IRC to be a reasonable reaction
> > to the veto. And that was it.
>
> Hmm. I saw that too and was curious as to how it would be resolved. It
> seems to me that this is a flaw with how this type of voting works - unless
> all of the committers enforce the rules against the person making the
> change regardless of their individual position on the subject being voted
> upon then a -1 becomes worthless.
I agree, a vote of -1 is useless if it is completely ignored.
> > So at the moment, I don't waste my time with people who treat
> > community projects like it is their personal ~/scratch directory. I
> > wait till Turbine and/or Fulcrum will stabilize and maybe one day we
> > might even get releases of 'irrelevant things like the central build
> > tool'. But then again, maybe not.
>
> It seems to me that development on turbine itself (along with most of the
> sub-components) is at a near standstill (either that or some pretty big
> commits are going to appear at some stage) because some of the major
> developers are currently absorbed by maven. I am actually really excited
> by maven but I am totally not going to adopt it until there is a final
> release - there have been just too many major revisions to jump in just
> yet. The thing that is killing me is that I have some torque patches in
> the queue (and further ones locally) that are not being committed because a
> new testing framework is in the pipeline that requires... you guessed it,
> maven-b7 ;-)
I think that Maven probably should have been used only for Turbine 3.x, not
Turbine 2.x (which should have been maintained in a stable state), but it is
too late for that now. We are now in a position where all we can ask is
"Where do we go from here?". I personally think that, given the current
situation, the Turbine lead developers are heading down the right path,
albeit rather slowly, due to their other committments.
> > We at INTERMETA have our internal CVS development tree and thanks to
> > the Apache License I'm neither required nor forced to put our changes
> > back into the main tree. I'd like to, but at the moment it would be a
> > waste of time which I don't have.
> >
> > At the moment, our internal Fulcrum build tree differs from the jakarta
> > one by about 16.800 lines of code:
> >
> > % cvs export -r HEAD -kk fulcrum > & /dev/null
> > % cvs -d :ext:henning@cvs.apache.org:/home/cvspublic export -r HEAD -kk
> > jakarta-turbine-fulcrum >& /dev/null
> > % diff -Nurb jakarta-turbine-fulcrum/src/java fulcrum/src/java | wc -l
> > 16817
> >
> > which splits down to
> >
> > Security Service 12946 lines
> > Intake 1830 lines
> > other stuff 2041 lines
> >
> > it would be moot to merge it to get told "I blow this away next
> > week. No, I don't care about your concerns. Did you test BTW
> > fooDevelop 0.0.2-snap-19700802.0824 from <some obscure server outside
> > apache.org>? There are no docs about it, but you surely have lots of
> > free time at hand to rework your 250 KLOC to work with it. Ah yes, and
> > we will move the whole building process over to this tool in about 15
> > minutes".
I share the same sentiments, but I think that the lead developers are
actually trying to do the right thing, some of them just need to improve
their communication skills a bit.
> > We're at the moment running a stripped down Turbine-2 with fully
> > integrated Fulcrum; remaining Turbine-2 services ported to Fulcrum and
> > running under the Fulcrum Service broker.
> >
> > Everything uses commons.logging for its logging purposes and logging
> > is integrated and centralized into Log4J (No more fscking LogService,
> > which was a bad idea from the beginning anyway).
> >
> > We use an intake service which is able to use multiple XML files
> > (Which is very important to us, because we use a module system where
> > every module of our application registers itself as a Turbine service
> > and contains its own intake files).
> >
> > I do intend to put all of this stuff back into Turbine-2, once 2.2
> > _is_ released and we have a definite idea where to move with Fulcrum
> > besides "let's blow it away and maybe we can use an Avalon container
> > for it at some point". At the moment, I'm more concerned with getting our
> > application to ship.
>
> The "blow it away comments" freak me out as there seems to be no clearly
> articulated strategy (apart from the "Avalon container" references which it
> would seem only a few people are in the know about.
>
> It is great that despite all this you still intend contributing these
> enhancements.
I agree. It is great that you are still committed to the project, Henning,
and I appreciate all the hard work you are doing to sort out the Turbine 2.x
security issues. Hopefully I'll be able to contribute more meaningfully once
things settle down again.
Thanks and best of luck,
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attn Henning: Fulcrum SecurityService proposal
Posted by Rodney Schneider <ro...@actf.com.au>.
On Tue, 10 Sep 2002 02:25, you wrote:
> "David Wynter" <da...@btclick.com> writes:
> >something that has no stability as a project. Any perceived advantages are
> >too risky because there is never a stable release and they can just
> >disappear.
>
> one could always split the tree (which is much easier with projects
> under Apache License than with e.g. GPL), but this would be about the
> most sucking thing to do.
This certainly is the most sucking thing to do. We just need more of an
overall strategy for Turbine 2.x and better communication between all parties.
> I really appreciate the hard work that some developers do in trying to
> get a Turbine release out of the door. I'm just unhappy about the fact
> that Turbine (and Fulcrum and Torque) are considered "playground for
> other applications" by some of the developers.
I don't mind Turbine 3.x being a "playground for other applications". It's
Turbine 2.x that I'm worried about. There hasn't been a stable release for
over 15 months now, and I think the main reason is that all parties involved
(including me) are concentrating on their own applications, or Turbine 3.x,
or Maven or...
I am not sure what the best course of action is. It seems to me that there
is still a community of developers committed to using and developing Turbine
2.x, and that is a good thing.
Maybe the turbine-dev mailing list should be split into turbine-2-dev and
turbine-3-dev so that we know who is committed to Turbine 2.x?
Comments?
-- Rodney
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Attn Henning: Fulcrum SecurityService proposal
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"David Wynter" <da...@btclick.com> writes:
>something that has no stability as a project. Any perceived advantages are
>too risky because there is never a stable release and they can just
>disappear.
Well,
one could always split the tree (which is much easier with projects
under Apache License than with e.g. GPL), but this would be about the
most sucking thing to do.
I really appreciate the hard work that some developers do in trying to
get a Turbine release out of the door. I'm just unhappy about the fact
that Turbine (and Fulcrum and Torque) are considered "playground for
other applications" by some of the developers.
Unfortunately, I don't get a nice salary for playing with designs,
either...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Attn Henning: Fulcrum SecurityService proposal
Posted by David Wynter <da...@btclick.com>.
Hi,
I'd like to comment on the rant section of the previous email.
People have different perspectives on things depending on where they are
coming from. Personally I do not get a nice salary and a remit that allows
me to 'play' with new designs. With me it is pure survival, if I can build a
product in less time then it allows me to sell it sooner. This is why I am
still using T2.1 with a few patches. I don't have time to invest in learning
a new build system or even security model unless it give me some advantages.
Turbine 2.2+ no longer has validity as a development tool as it has become
something that has no stability as a project. Any perceived advantages are
too risky because there is never a stable release and they can just
disappear.
My opinion only, but I imagine shared by other folk who committed to Turbine
last year and maybe now regret it. I don't regret it as I have a nice
product that when I replace the TurbineScheduler with Quartz I will be happy
with. The concept embodied by Turbine deserves to be really popular, but the
way the project is run means that it probably won't be.
My 2c worth.
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>