You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Quinton McCombs <qm...@nequalsone.com> on 2003/01/13 17:01:05 UTC
Re: [VOTE] Fulcrum deprecation
Fulcrum was never released. There has also been some work backporting
code from Fulcrum into the turbine-2 code base. I would anticipate that
there will be even more work to get the remaining services backported as
well.
The current plan is NOT to use Fulcrum for version 2.3. We do want to
be able to Avalon components. Considering that we want this ability in
2.3 and we don't currently use Fulcrum, I see no reason not to modify
Fulcrum to use Avalon.
Turbine users should have mostly stayed away from Fulcrum. Those that
did move to Fulcrum should have noticed that they were using alpha/beta
code. They chose to be on the bleeding edge. Development version are
prone to being unstable. I don't see the proposed changes as being much
of a problem.
I would like to see it working for just one or two services first,
though. This would give us all a chance to see exactly how it will be
implemented. This first phase of the Avalonization would be like a
proof of concept.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by Stephen Haberman <st...@beachead.com>.
On Mon, Jan 13, 2003 at 10:20:14PM +0000, Henning P. Schmiedehausen wrote:
> Stephen Haberman <st...@beachead.com> writes:
>
> >Don't get me wrong, I'm still all for it, but Henning is right, this
> >Avalonization thing won't be a walk in the park. Either for users or
> >developers.
>
> I still consider the formalization of the lifecycle in separate
> interfaces from Avalon, the death of stratum and Johns' work here very
> valuable and the right way to do. I just want to make it nice and
> smooth. :-)
Egad, I sure wish it will be too.
But after spending a few days digging through the code, I'm at a
loss for now. The crux of the issue is the configuration...I think
once that is resolved, the other issues like removing TurbineXxx
coupling in the security service will just be a matter of elegant
refactoring (which I wouldn't mind doing as I need practice at the
task, I just got frustrated with the configuration thing and am
context switching to other things for a few days).
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Stephen Haberman <st...@beachead.com> writes:
>Don't get me wrong, I'm still all for it, but Henning is right, this
>Avalonization thing won't be a walk in the park. Either for users or
>developers.
I still consider the formalization of the lifecycle in separate
interfaces from Avalon, the death of stratum and Johns' work here very
valuable and the right way to do. I just want to make it nice and
smooth. :-)
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: [VOTE] Fulcrum deprecation
Posted by Stephen Haberman <st...@beachead.com>.
On Mon, Jan 13, 2003 at 10:01:05AM -0600, Quinton McCombs wrote:
> Turbine users should have mostly stayed away from Fulcrum. Those
> that did move to Fulcrum should have noticed that they were using
> alpha/beta code.
And man have I learned my lesson. The whole reason for this
Avalonization kick all started from just wanting to 1) run the Fulcrum
Security service with Torque-3.0, and 2) run my app in an Avalon
container instead of Tomcat as we don't have a web frontend anymore.
I can see now why John McNally kept the old properties style
configuration, as ugly as it makes things. For one, the conversion
from properties to XML is just a bad idea, as, for example, with the
XML-RPC service, the properties that are like:
services.XmlRpcService.this.is.a.really.long.property.a = blah
services.XmlRpcService.this.is.a.really.long.property.b = blah
(they seriously get that long, e.g. that many periods, for no reason
at all).
So does this become:
<xmlrpc>
<this>
<is>
etc.
</is>
</this>
</xmlrpc>
Or:
<xmlrpc>
<this.is.a.really.long.property>blah</ >
</xmlrpc>
When really what the service probably wants is:
<xmlrpc>
<this.is.a.really.long>
<property.a>blah</ >
<property.b>blah</ >
</this.is.a.really.long>
</xmlrpc>
But then you lose the hierarchy all together. Which makes me think,
screw it, give per-service documentation on how users, on their own,
can convert their old TR.props settings and just plug them into the
new XML file format (I know, I know, Henning, I'm not seriously
proposing this :-).
So it becomes a choice of either screwing old users by making them
move to the new XML format, or screwing future users by making the
XML configuration format ugly and inflexible (e.g. current TR.props
entries with periods are either ALL x.y.z or <x><y><z/></y></x>.
On top of that, the security service in particular is what I'm
trying to convert over, is tightly coupled to the TurbineXxx
singleton/Class.forName way of doing things. Both of which are
frowned upon in Avalon, as container management and role
configuration, replacement these for very good reasons.
So with this app that all I wanted to get running in an Avalon
container was the Fulcrum Security service, replete of various
TurbineXxx stuff, will require major refactoring of the Security
service.
So for now, I'm screwing the idea of Avalonizing Fulcrum, I went
back to a snapshot just before John McNally committed the initial
changes, applied the various patches to get it to compile with
Torque 3.0, and will just use that until we get this Fulcrum
Avalonization thing sorted out (e.g. I meet a few deadlines that
require a running application and then can work on it later).
Don't get me wrong, I'm still all for it, but Henning is right, this
Avalonization thing won't be a walk in the park. Either for users or
developers.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by Stephen Haberman <st...@beachead.com>.
On Mon, Jan 13, 2003 at 10:18:08PM +0000, Henning P. Schmiedehausen wrote:
> Basically, pre-Avalonization, the Fulcrum and Turbine-2 code was
> identical except that you had to substitute "turbine.services" with
> "fulcrum". That made code moving back and forth easy. That's why at
> least I want to delay the complete assimi^Wavaloniziation until post
> Turbine-2.3. Which at least in my personal road map is planned End
> January.
Sounds good to me. Though perhaps we could start the Avalonization
on a branch as Dan suggested to see how it goes.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Quinton McCombs" <qm...@nequalsone.com> writes:
>Fulcrum was never released. There has also been some work backporting
>code from Fulcrum into the turbine-2 code base. I would anticipate that
>there will be even more work to get the remaining services backported as
>well.
>The current plan is NOT to use Fulcrum for version 2.3. We do want to
>be able to Avalon components. Considering that we want this ability in
>2.3 and we don't currently use Fulcrum, I see no reason not to modify
>Fulcrum to use Avalon.
Hi,
actually, I don't plan on backporting any more stuff than the
CryptoService (which was done by something resembling "find . -name
\*.java | xargs sed -e 's/fulcrum/turbine.services/g'") and the
extended DB Security Service which is painstakingly difficult, took
most of my Saturday and Sunday and still is not in there.
I do this, because there is demand from Users. To me, 2.3 is the last
release with coupled services. Actually, in our internal repository,
we're using a stripped down turbine-2 called turbine-light with
fulcrum since quite a while. I can send you the sources if you want
to.
Basically, pre-Avalonization, the Fulcrum and Turbine-2 code was
identical except that you had to substitute "turbine.services" with
"fulcrum". That made code moving back and forth easy. That's why at
least I want to delay the complete assimi^Wavaloniziation until post
Turbine-2.3. Which at least in my personal road map is planned End
January.
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: [VOTE] Fulcrum deprecation
Posted by Daniel Rall <dl...@collab.net>.
On Tue, 14 Jan 2003, Stephen Haberman wrote:
> On Mon, Jan 13, 2003 at 08:08:25PM -0800, Daniel Rall wrote:
> > The instability was caused by the porting of a fragile and
> > slightly crufty Ant build file to Maven during its early days and
> > a failure to keep it up to date.
>
> Speaking of which, what ant files in the fulcrum directory are still
> being used? I've been using solely maven for awhile now...do we need
> to keep them around, perhaps the gump one?, or can we kill some?
I've been using the Ant build files generated by Maven myself. John and Jon
may be using them to upgrade Scarab as well.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by Stephen Haberman <st...@beachead.com>.
On Mon, Jan 13, 2003 at 08:08:25PM -0800, Daniel Rall wrote:
> The instability was caused by the porting of a fragile and
> slightly crufty Ant build file to Maven during its early days and
> a failure to keep it up to date.
Speaking of which, what ant files in the fulcrum directory are still
being used? I've been using solely maven for awhile now...do we need
to keep them around, perhaps the gump one?, or can we kill some?
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Fulcrum deprecation
Posted by Daniel Rall <dl...@collab.net>.
On Mon, 13 Jan 2003, Quinton McCombs wrote:
> Fulcrum was never released. There has also been some work backporting
> code from Fulcrum into the turbine-2 code base. I would anticipate that
> there will be even more work to get the remaining services backported as
> well.
>
> The current plan is NOT to use Fulcrum for version 2.3. We do want to
> be able to Avalon components. Considering that we want this ability in
> 2.3 and we don't currently use Fulcrum, I see no reason not to modify
> Fulcrum to use Avalon.
>
> Turbine users should have mostly stayed away from Fulcrum. Those that
> did move to Fulcrum should have noticed that they were using alpha/beta
> code. They chose to be on the bleeding edge. Development version are
> prone to being unstable. I don't see the proposed changes as being much
> of a problem.
>
> I would like to see it working for just one or two services first,
> though. This would give us all a chance to see exactly how it will be
> implemented. This first phase of the Avalonization would be like a
> proof of concept.
Quinton, SecurityService aside, the only thing that is unstable about
the code currently in Fulcrum is the build system. The instability was
caused by the porting of a fragile and slightly crufty Ant build file to
Maven during its early days and a failure to keep it up to date.
Templating systems aside, the services in Fulcrum are of equal (or
possibly better) quality than the ones in Turbine 2.3, and include more
features. Many (but not all) of those features have been gradually
backported.
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>