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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
