You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Stephen Haberman <st...@beachead.com> on 2003/01/11 19:45:52 UTC
[VOTE] fulcrum deprecation
On Thu, Jan 09, 2003 at 01:09:57PM -0800, Daniel Rall wrote:
> I'd also be a fan of seeing the TurbineXxx classes go. I'm +1 on
> deprecating them today and removing them in a while. I'm unsure
> about the interface classes -- I suppose that those should
> probably stay.
Given that Fulcrum hasn't had a release and we're abandoning the
singleton model of TurbineXxx classes, could we bump the version
number to b3-dev and just remove them (them being the TurbineXxx
singleton classes, the Service/BaseService and
ServiceBroker/BaseServiceBroker)?
(Hear me out below...a stark removal of them really does not place
much burden on clients of Fulcrum)
As I see it, there are three things the user sees when interacting
with Fulcrum:
1) Properties-based configuration file
2) TurbineServices.getInstance().getService(name) lookup
3) Service interfaces
So, when going to Avalon:
1) Changes to XML-based configuration, but we can probably set up an
adaptor that reads in the services.xxx.yyy style and converts it to
an Avalon Configuration object. So this would be transparent to
users, e.g. TurbineResources.properties will still work just fine,
but services would be converted completely over to the Avalon
configuration style.
2) Changes to something like
FulcrumContainer.lookup(ServiceInterface.ROLE). This would not be
transparent, but it is a straight forward conversion.
(Note that FulcrumContainer just composes ECM or Fortress and
forwards the lookup to it; also note that FulcrumContainer would
have methods like initialize(String newXmlFile) and
initializeOldConfiguration(String oldPropertiesFile)).
3) Stay the same, except NAME is changed to ROLE.
None of the changes involve architectural changes in the clients of
Fulcrum. And so if these changes are well documented, e.g. on the
wiki as UpgradingToAvalonizedFulcrum, I think it is safe to do a
straight conversion instead of worrying about the baggage of
deprecation and backwards compatibility (which removes a lot of
the potential elegantness that Avalon promises).
Also as a part of this stark conversion, service implementations
would no longer have Service/BaseService to implement/inherit, but
the conversion over to Avalon lifecycles interfaces is
straightforward and is much easier to do in one step than
implementing both the Fulcrum lifecycle and Avalon lifecycle
interfaces.
Alternatively, if this scares people, can I have a branch to do
exactly this? I've been going through code and the itch to just do
away with Service/BaseService/ServiceBroker/BaseServiceBroker and
start with clean Avalon is just killing me.
Thanks,
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henning P. Schmiedehausen wrote:
> Nicola Ken Barozzi <ni...@apache.org> writes:
>
>
>>>If you want XML based configuration, you should add an adaptor to the
>>>commons-configuration and simply use it. That way, people who want to
>>>keep their properties files won't get fucked up.
>
>
>>Or send us a patch so that Avalon can use property files for
>>configuration. A Configuration is not necessarily based on XML, just our
>>default implementation is.
>
> So basically your position is "we're Avalon. We convert what we
> consider useful to work with us and don't care if any other project
> using these components falls wayside. Either you adapt or die".
Eh? What do we convert? I don't get it. We have an avalon Configuration
object that is gotten by default from XML. But any container can load it
as he wishes, from whatever source.
> Sounds like the Borg. Maybe some of the Turbine developers will now start
> to understand my sceptical position on "avalonization".
I don't get it.
> I'm working on the turbine project. I'm trying to support my needs and
> the needs of the turbine users. The patch for avalon is easy: Use
> commons-configuration and write an adaptor that can read avalon XML
> configuration files and present them as a Configuration object. End of
> Story.
I don't get this. An adaptor that can read XML files and give them as a
Configuration? Sorry, but isn't this what our default implementation
does? I'm confused...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Leo Simons <le...@apache.org>.
Hey peeps,
Henning P. Schmiedehausen wrote:
> So basically your position is "we're Avalon. We convert what we
> consider useful to work with us and don't care if any other project
> using these components falls wayside. Either you adapt or die".
that is not the avalon position at all, or the position of any of the
avalon developers, nor has it been that way in the past, nor will it be
that way in the future. Avalon is an apache project, and follows the
apache ideas, which are not those of the borg.
------
I will make myself rather silly by pointing this out. Go ahead and skip
to the next few dashes. I enjoy looking up stuff like this every now and
then :D
You will find the most important interface dealing with avalon
configuration @
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apache/avalon/framework/configuration/Configuration.java
moved from
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apache/avalon/configuration/Attic/Configuration.java
moved from
http://cvs.apache.org/viewcvs.cgi/java-framework/src/java/org/apache/avalon/configuration/Configuration.java
This has been around for a long time. There's probably traces of the
idea in the JServ cvs as well if you look well enough.
Besides the interface, there is obviously also an implementaton (dubbed
DefaultConfiguration). There's also a parser which converts xml files
into Configurations using SAX. Ie it's a bit like JDOM, but different,
and also dates back basically from the original avalon 1.0alpha code. I
think it has some roots in JServ as well.
The initial commits date from November 1999. I would argue that this bit
of history proves avalon is not about a Borg-like "embrace and extend"
of the commons-configuration code, as I believe jakarta, and hence
commons-configuration barely existed around that time.
------
Here's the "avalon position": as part of the lifecycle, it was deemed
wise (probably by Stefano or Jon or Fede, ie by one of the avalon
founders, and before I ever heard about avalon) that there was a
configuration stage, for which there was devised a Configuration
interface. People probably felt DOM was too heavy so a thin layer was
added on top of SAX to enable use of XML. These classes have existed
since, and will stay at least as long as backwards compatibility toward
end-users requires.
That's it, no more no less.
We are not out to "embrace and extend" at all. In fact, we're trying
real hard to get back to the avalon core business and "donate elsewhere
or throw away" if it doesn't fit in.
------
The relationship between commons-configuration and avalon's configuration?
I don't know too much about commons-configuration, but apparantely its
interface is somewhat from avalon's, different and it knows what to do
with java Properties files, while avalon's Sax-based configuration
builder does not. (Avalon's Configuration and DefaultConfiguration
basically don't know how to do anything, which is a feature, not bug :D)
Avalon does have Parameters, which has a fromProperties(), to allow flat
properties to be used in place of hierarchical configuration, ie
http://cvs.apache.org/viewcvs.cgi/jakarta-avalon/src/java/org/apache/avalon/framework/parameters/Parameters.java
but I'm not sure how that relates to commons configuration and how it
parses properties files. We've talked about merging Parameters back into
Configuration for a future avalon release, but we can't for quite some
time because of backwards compatibility issues. Perhaps this is the big
edge that commons-configuration in effect has over avalon.
Maybe, if commons-configuration grows and develops to be a better
configuration tool than the code that exists in avalon, avalon will
replace its own code with commons-configuration. But not for the life of
avalon-framework 4.x, since we don't want to break existing stuff.
------
I don't know how commons-configuration was started, nor why, nor from
which project it came, nor how "compatible" it is with the avalon
interfaces. I don't want to challenge any of that background, nor do I
think it wise to challenge the background behind the configuration code
in avalon. Both initiatives make sense. I certainly hope
commons-configuration did an "embrace and extend" of the avalon code
though....it'd make the current problem easier to fix :D
------
What should turbine do? I think the answer is similar to the one I gave
when this was about logging. The avalon configuration makes sense in the
context of an avalon application.
If you want to build turbine as an avalon app, and use that code, but
the blocker is the ability to read properties files, we should figure
out how to overcome that blocker. Not get into a fight about it.
If you want to build turbine as an avalon app but you wish to use the
commons-configuration code in place of the avalon one, I think you will
have to build or modify your own avalon container which supports that,
as avalon itself can't move to commons-configuration because we don't
want to break backwards compatibility.
But if commons configuration and the avalon Configuration interface are
or can be made compatible, maybe all that's needed is a
CommonsConfiguration implements Configurable extends
<CommonsConfigurationClass> { ... }
and it might even make sense to put that class in avalon-framework. If
it can work, I'm certainly in favour of it. But commons-config will have
to be a stable released product before we can do that.
------
cheers,
- Leo
--
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>.
Nicola Ken Barozzi <ni...@apache.org> writes:
>> If you want XML based configuration, you should add an adaptor to the
>> commons-configuration and simply use it. That way, people who want to
>> keep their properties files won't get fucked up.
>Or send us a patch so that Avalon can use property files for
>configuration. A Configuration is not necessarily based on XML, just our
>default implementation is.
So basically your position is "we're Avalon. We convert what we
consider useful to work with us and don't care if any other project
using these components falls wayside. Either you adapt or die".
Sounds like the Borg. Maybe some of the Turbine developers will now start
to understand my sceptical position on "avalonization".
I'm working on the turbine project. I'm trying to support my needs and
the needs of the turbine users. The patch for avalon is easy: Use
commons-configuration and write an adaptor that can read avalon XML
configuration files and present them as a Configuration object. End of
Story.
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 Nicola Ken Barozzi <ni...@apache.org>.
Henning P. Schmiedehausen wrote:
> Dan Diephouse <da...@envoisolutions.com> writes:
>
>
>>>1) Changes to XML-based configuration, but we can probably set up an
>>>adaptor that reads in the services.xxx.yyy style and converts it to
>>>an Avalon Configuration object. So this would be transparent to
>>>users, e.g. TurbineResources.properties will still work just fine,
>>>but services would be converted completely over to the Avalon
>>>configuration style.
>
> That would be the dumbest decision I've seen in many months.
>
> If you want XML based configuration, you should add an adaptor to the
> commons-configuration and simply use it. That way, people who want to
> keep their properties files won't get fucked up.
Or send us a patch so that Avalon can use property files for
configuration. A Configuration is not necessarily based on XML, just our
default implementation is.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
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:26:54PM -0800, Daniel Rall wrote:
> On Sun, 12 Jan 2003, Stephen Haberman wrote:
>
> > For now, I'll continue my Avalonization of Fulcrum without checking
> > anything in. Assuming/when I get to a good stopping point, I'll play
> > with hooking it into Turbine-2, post the results to the list, and
> > then it can be decided what to do with the code.
>
> Stephen, why not just work in a branch where everyone can see your changes?
> Duncan describes the reasoning behind this approach well:
>
> http://incubator.apache.org/rules-for-revolutionaries.html
Thanks for the link. I'm open to playing around on a branch (e.g.
AVALONIZED :-) if the other Turbine devs think it is not futile.
A big part of what will perk my interest in participating is the
amount of backwards compatibility that the Avalonized Fulcrum will
honor (e.g. the whole configuration thing). I don't mean to say,
'let me break backwards compatibility or I won't contribute,' but
maintaining stuff like that at the expense of clean code, to me,
just sucks.
Perhaps I need to mature a bit more in that aspect, e.g. learning
how to refactor/code inelegant requirements into elegant code.
Actually, now that I think about it, I'm sure I do. But that doesn't
necessarily mean that I want to. :-)
Basically I'm asking that if we do go the branch route, we can
refactor all we want and not worry about backwards compatibility,
and instead push off that issue until something reasonable develops
in the branch and is ready to be merged back into HEAD to reopen
that can of worms.
- 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 Sun, 12 Jan 2003, Stephen Haberman wrote:
> For now, I'll continue my Avalonization of Fulcrum without checking
> anything in. Assuming/when I get to a good stopping point, I'll play
> with hooking it into Turbine-2, post the results to the list, and
> then it can be decided what to do with the code.
Stephen, why not just work in a branch where everyone can see your changes?
Duncan describes the reasoning behind this approach well:
http://incubator.apache.org/rules-for-revolutionaries.html
- Dan
--
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 12:28:57AM +0000, Henning P. Schmiedehausen wrote:
> As you may have noticed, this is still the Turbine development list.
> Fulcrum are decoupled services to be used with Turbine (2 and 3). If
> you change the code so that the current Turbine user base falls wayside,
> there is not much sense to discuss this here.
I don't understand why Avalonizing Fulcrum makes Turbine users fall
by the wayside. Does it take complete backwards compatibilty for
users to not fall by the wayside? (Real question, not meant to be
sarcastic.)
As I see it, Turbine-2 completely wraps the services from the users
view point. The user just puts together the properties file and
calls up the servlet. So what goes on behind the scenes, whether it
is with built-in, same-repo services or via decoupled Avalon
services shouldn't matter a hoot to users.
> At least not for another (2.3) release of Turbine. That's why I said
> "wait with this until after 2.3 release". I still don't get the point
> why using Avalon configuration is better than using our tried and true
> commons-configuration.
I should go back and look at the proposed roadmaps, but aren't you
undoing a lot of the decoupling that Fulcrum was meant to enforce by
checking in a bunch of the security code into turbine-2? Why can't
turbine-2.2 use Fulcrum instead of having mass code duplication
between the turbine-2 and fulcrum repos?
(I looked through the archives for 'roadmap' and didn't find a
reason why turbine-2.2 can't use fulcrum instead of copying all of
the code into the repo and backing it all out for turbine-2.3 when
it goes back to Fulcrum. I did find in [url below] where it was
agreed turbine-2.3 would use Avalonized services).
http://archives.apache.org/eyebrowse/ReadMsg?listName=turbine-dev@jakarta.apache.org&msgId=597404
So, turbine-2 is not using Fulcrum right now, correct? turbine-2.3
will want to use an Avalonized Fulcrum. I desire an Avalonized
Fulcrum now, so why not let me go through with it and just get it
over with?
> At least I will peek there from time to time and ste^Wborrow code
> ideas for Turbine. Eventually even Turbine will arrive there. But at
> least I will take my time, cruise leisurely along and try not to lose
> the Turbine users that we have in the meantime.
I appreciate your dedication to Turbine's user base. And I apologize
upfront for not always putting their considerations first; but given
that Fulcrum has no real user base (especially in relation to
turbine-2), other than turbine-3-alpha users who in are already on
the bleeding edge and should be comfortable the the no backwards
compatibility thing, I thought my proposal of going with no
deprecation would be okay.
> >The current Avalonization of Fulcrum, to me, is just a step to
> >Fulcrum being integrated into whatever components repository Avalon
> >soon forms for people like Cocoon, James, and Turbine so that
>
> I've seen no discussion about this. The only developer who really
> worked in this direction took his code off-jakarta because "he prefers
> to work this way" (Jason).
Avalonization was discussed with approval by you and Martin in the
roadmap I found (though I'll readily admit there may be other emails
I am missing out on). But true; Jason did take a lot of the
Avalonization stuff off-jakarta. I certainly don't want to go that
route and fracture the community more than it already is.
> To me, it seems that Martin, Quinton and I make road maps for Turbine
> post-2.2 and noone else seems to be interested in anything of this. If
> it is so, please tell. Then I'll pull out the current Turbine source
> level and we fork to somewhere else. Probably SourceForge.
There is no need for that. Turbine is more important to Turbine than
Fulcrum is to Turbine, as you well know.
For now, I'll continue my Avalonization of Fulcrum without checking
anything in. Assuming/when I get to a good stopping point, I'll play
with hooking it into Turbine-2, post the results to the list, and
then it can be decided what to do with the code.
Thanks,
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:
>On Sun, Jan 12, 2003 at 11:11:46AM +0000, Henning P. Schmiedehausen wrote:
>> >> 1) Changes to XML-based configuration, but we can probably set up an
>> >> adaptor that reads in the services.xxx.yyy style and converts it to
>> >> an Avalon Configuration object. So this would be transparent to
>> >> users, e.g. TurbineResources.properties will still work just fine,
>> >> but services would be converted completely over to the Avalon
>> >> configuration style.
>>
>> That would be the dumbest decision I've seen in many months.
>>
>> If you want XML based configuration, you should add an adaptor to the
>> commons-configuration and simply use it. That way, people who want to
>> keep their properties files won't get fucked up.
>The problem with using commons-configuration is that Avalon's
>Framework (which is firmly stable, unlike the container situation
>and they're very touchy about breaking backwards compatibility with
>it, from what I've seen) has it's own Configuration interface that
>everything in Avalon (components, containers, etc.) already uses.
As you may have noticed, this is still the Turbine development list.
Fulcrum are decoupled services to be used with Turbine (2 and 3). If
you change the code so that the current Turbine user base falls wayside,
there is not much sense to discuss this here.
>But isn't 'jakarta-avalon-services' precisely what
>'jakarta-turbine-fulcrum' should become? I was under the impression
>it was group consensus for this Avalonization to happen as Fulcrum
>was evolving away from the Turbine core to become an awful lot like
>Avalon (a server/component/services framework) to the point where
>the duplication inefficient?
At least not for another (2.3) release of Turbine. That's why I said
"wait with this until after 2.3 release". I still don't get the point
why using Avalon configuration is better than using our tried and true
commons-configuration.
Everytime I hear "Avalon has only the best intentions" it ends in
"embrace and extend". And screws the current Turbine user base which
struggles to keep somehow something running.
Sorry. I'll keep a "-1" on this. If you insist on going this path with
fulcrum, please create jakarta-avalon-fulcrum and move the code there.
At least I will peek there from time to time and ste^Wborrow code
ideas for Turbine. Eventually even Turbine will arrive there. But at
least I will take my time, cruise leisurely along and try not to lose
the Turbine users that we have in the meantime.
>The current Avalonization of Fulcrum, to me, is just a step to
>Fulcrum being integrated into whatever components repository Avalon
>soon forms for people like Cocoon, James, and Turbine so that
I've seen no discussion about this. The only developer who really
worked in this direction took his code off-jakarta because "he prefers
to work this way" (Jason).
To me, it seems that Martin, Quinton and I make road maps for Turbine
post-2.2 and noone else seems to be interested in anything of this. If
it is so, please tell. Then I'll pull out the current Turbine source
level and we fork to somewhere else. Probably SourceForge.
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 Robert McIntosh <ro...@bull-enterprises.com>.
I may not be a commiter to Avalon, but for the .02 of a user (and a
happy one at that), I can say that the commons configuration, well,
doens't come close to doing what Avalon's does. For apparently obvious
reasons, the commons configuration is geared towards property files and
therefore doesn't really provide any constructs for the tree nature of
XML files, namely children nodes/configs and attributes. I believe that
Avalon's configuration does this beautifully without constraining me in
how I design my configuration. The configuration API was actually one of
the reasons I jumped onto Avalon in the first place (the second being
the container architecture/concepts).
I'm sure that the commons configuration meets the needs of its intended
audience, but I think it needs a lot of work before it can meet the
needs of Avalon's audience. I agree with Berin that maybe commons could
or should adopt Avalon's configuration API.
A satisfied user,
Robert
>>Stephen Haberman wrote:
>>
>>
>>>On Mon, Jan 13, 2003 at 08:18:21PM -0800, Daniel Rall wrote:
>>>
>>>
>>>
>>>>I would very much like to see Avalon adopt the Commons Configuration
>>>>interface, and am willing to write code to make that happen.
>>>>
>>>>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] fulcrum deprecation
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> Stephen Haberman wrote:
> > On Mon, Jan 13, 2003 at 08:18:21PM -0800, Daniel Rall wrote:
> >
> >>I would very much like to see Avalon adopt the Commons Configuration
> >>interface, and am willing to write code to make that happen.
>
> Please try to understand us, we have users to take care of. We cannot
> simply change the interface of one of our core interfaces
> just like that.
Not to mention the gall of seeing that we have an *established* interface,
creating an alternative after that fact, and then expecting us to change
to your solution.
What about collaboration? What about checking to see if you can work with
what we have? What compatibility layers have you provided? Is your
solution
friendly to IoC based development, or does it provide ways of circumventing
that like Commons Logging?
> This is now. For the future, who knows... we are now starting
> to discuss
> about Avalon 5. I heartily suggest you and all who are interested to
> join us on the avalon-dev list to discuss this and other matters. We
> really want to get this sorted out once and for all.
Keep in mind that nothing is set in stone for A5--but we will follow
the principles that make Avalon successful and powerful.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Haberman wrote:
> On Mon, Jan 13, 2003 at 08:18:21PM -0800, Daniel Rall wrote:
>
>>I would very much like to see Avalon adopt the Commons Configuration
>>interface, and am willing to write code to make that happen.
Please try to understand us, we have users to take care of. We cannot
simply change the interface of one of our core interfaces just like that.
We have a Configuration that's pluggable, and that is used in all our
containers. Commons Configuration is a Commons package, ie a utility
package. IMHO the most reasonable thing to do now is to use Commons
configuration as the (default?) implementation for our Configuration.
Same for logging I guess.
This is now. For the future, who knows... we are now starting to discuss
about Avalon 5. I heartily suggest you and all who are interested to
join us on the avalon-dev list to discuss this and other matters. We
really want to get this sorted out once and for all.
Thank you :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen Haberman wrote:
> On Mon, Jan 13, 2003 at 08:18:21PM -0800, Daniel Rall wrote:
>
>>I would very much like to see Avalon adopt the Commons Configuration
>>interface, and am willing to write code to make that happen.
Please try to understand us, we have users to take care of. We cannot
simply change the interface of one of our core interfaces just like that.
We have a Configuration that's pluggable, and that is used in all our
containers. Commons Configuration is a Commons package, ie a utility
package. IMHO the most reasonable thing to do now is to use Commons
configuration as the (default?) implementation for our Configuration.
Same for logging I guess.
This is now. For the future, who knows... we are now starting to discuss
about Avalon 5. I heartily suggest you and all who are interested to
join us on the avalon-dev list to discuss this and other matters. We
really want to get this sorted out once and for all.
Thank you :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
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:18:21PM -0800, Daniel Rall wrote:
> I would very much like to see Avalon adopt the Commons Configuration
> interface, and am willing to write code to make that happen. In the mean
> time, I recommend that Turbine/Fulcrum/Torque/etc. continue to use Commons
> Configuration, and that we write a light weight adapter for Avalon's
> configuration (as suggested by others as well), which delegates to a Commons
> Configuration implementation.
I agree that's ideal, but is the commons-figuration based
implementation of the Avalon configuration class and it's
integration into the lifecycle configurable in the containers? E.g.
phoenix/Fortress/ECM? Or would we need to wait for special builds of
these to be released?
I'm doubting that as flexible as Avalon is
with the roles/components/etc., that currently the Configuration
class is not pluggable.
I guess if we do wait for a patch to Avalon Framework, plus
subsequent release, it is no big deal to me, as I'm falling back on a
Tomcat-run, Turbine-3-intialized, Novemeber 1st snapshot of Fulcrum
to run the old app as is until this Avalonization muck gets sorted
out, nor others as it seems Turbine-2.x using Fulcrum, or an
Avalonized Fulcrum, is still a (little) ways off.
Though again, even if the Avalon Framework could read in either
properties or XML, we haven't figured out how to map the two back
and forth as Henning highlightly very nicely [that XML has multiple
representations of the same hierarchy while properties have only
one].
This is ugly, but would we have to resort to something like:
services!XmlRpcService!this.is.one.property = x
To map to:
<services>
<XmlRpcService>
<this.is.one.property>x</this.is.one.property>
</XmlRpcService>
</services>
I'll give you that it is ugly, but until we have such a scheme in
place, having Avalon do both properties and XML elegantly is not
doable (at least as I see the problem; hopefully someone else has a
better idea, but I sure don't see it).
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by David Worms <da...@simpledesign.com>.
On Monday, January 13, 2003, at 02:40 PM, Henning P. Schmiedehausen
wrote:
> Martin Poeschl <mp...@marmot.at> writes:
>
> --- cut ---
> services.VelocityService.earlyInit= true
> services.VelocityService.template.extension= vm
> services.VelocityService.default.page= VelocityPage
> services.VelocityService.default.screen= VelocitySecureScreen
> services.VelocityService.default.layout= VelocityECSLayout
> services.VelocityService.default.navigation= VelocityNavigation
> services.VelocityService.default.error.screen= VelocityErrorScreen
> services.VelocityService.default.layout.template= Default.vm
> services.VelocityService.input.encoding=UTF-8
> services.VelocityService.velocimacro.library.autoreload= true
> services.VelocityService.velocimacro.library.messages= false
> services.VelocityService.resource.manager.logwhenfound= false
> services.VelocityService.resource.loader= classpath
> services.VelocityService.classpath.resource.loader.description=
> Velocity Classpath Resource Loader
> services.VelocityService.classpath.resource.loader.class=
> org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
> --- cut ---
>
Just throwing some idees, why not something like,
<services>
< VelocityService>
<parameters>
<property name="earlyInit" value="true">
<property name="default.page" value="VelocityPage">
</parameters>
< /VelocityService>
</services>
This would be easily resolved as a generic map object and used to setup
the VelocityContext, or any other services.
--
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>.
Martin Poeschl <mp...@marmot.at> writes:
>avalon has xml configuration, but no way to use properties files ...
>commons-configuration loads properties files, but can't read xml files
>.. so an adapter to exchange configurations between them sounds like a
>good idea :-)
As Stephen wrote, the main problem with a straight conversion is
that we have a quite deep properties hierarchy with five or more
sub-levels of properties. If you convert this to straight
<a>
<b>
<c>foobar</c>
</b>
</a>
for a.b.c = foobar
this will get really messy. As I wrote some days ago on commons-dev;
while the properties configuration is pretty simple, because you have
only one way to express a property; this is not the case in XML. You
can express some simple property configuration in lots of valid XML
configurations. And just straight tag conversion might not be the best
idea. A simple example. I'm just picking this because I have it handy:
--- cut ---
services.VelocityService.earlyInit= true
services.VelocityService.template.extension= vm
services.VelocityService.default.page= VelocityPage
services.VelocityService.default.screen= VelocitySecureScreen
services.VelocityService.default.layout= VelocityECSLayout
services.VelocityService.default.navigation= VelocityNavigation
services.VelocityService.default.error.screen= VelocityErrorScreen
services.VelocityService.default.layout.template= Default.vm
services.VelocityService.input.encoding=UTF-8
services.VelocityService.velocimacro.library.autoreload= true
services.VelocityService.velocimacro.library.messages= false
services.VelocityService.resource.manager.logwhenfound= false
services.VelocityService.resource.loader= classpath
services.VelocityService.classpath.resource.loader.description= Velocity Classpath Resource Loader
services.VelocityService.classpath.resource.loader.class= org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
--- cut ---
Very messy:
<services>
<VelocityService>
<earlyInit>true</earlyInit>
<template>
<extension>vm</extension>
</template>
<default>
<page>VelocityPage</page>
<screen>VelocitySecureScreen</screen>
<layout>VelocityECSLayout</layout>
<navigation>VelocityNavigation</navigation>
<error>
<screen>VelocityErrorScreen</screen>
</error>
<layout>
<template>Default.vm</template>
</layout>
</default>
<input>
<encoding>UTF-8</encoding>
</input>
<velocimacro>
<library>
<autoreload>true/autoreload>
<messages>false</messages>
</library>
</velocimacro>
<resource>
<manager>
<logwhenfound>false</logwhenfound>
</manager>
<loader>classpath</loader>
</resource>
<classpath>
<resource>
<loader>
<description>Velocity Classpath Resource Loader</description>
<class>org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader</class>
</loader>
</resource>
</classpath>
</VelocityService>
</services>
And what I would think of a such a configuration file:
--- cut ---
<services>
<service name="VelocityService"
earlyInit="true">
<template extension="vm"/>
<page default="VelocityPage"/>
<screen default="VelocitySecureScreen"
error="VelocityErrorScreen"/>
<layout default="VelocityECSLayout"/>
<navigation default="VelocityNavigation" />
<input encoding="UTF-8"/>
<velocimacro autoreload="true" messages="false"/>
<resources>
<manager logwhenfound="false"/>
<loader name="classpath" description="Velocity Classpath Resource Loader"
class="org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader"/>
</resources>
</service>
</services>
Much more grouped, using the natural XML style of grouping (like
e.g. the loaders here). But the problem is: Both configurations are
syntactically valid XML (besides the typoes I did put in there. :-)
). Only the semantics change and this is something that I still can't
see in a generic configuration package. Avalon has one style of XML
configuration. Other packages have others (Maven has even two
different ways of expressing a file set in just one application! ant
filesets in its maven.xml, and a self rolled XML in project.xml!)
So, to me, the "grand unified XML configuration" is still quite a bit
away. I admit that I didn't look too deep into Avalon XML configuration.
But problems like these are the main reason why I still like
properties files. Ah well, and because I'm a diehard Unix bigot who
loves to hack text files instead of using a graphical editor for my
configuration files. :-)
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 Martin Poeschl <mp...@marmot.at>.
avalon has xml configuration, but no way to use properties files ...
commons-configuration loads properties files, but can't read xml files
.. so an adapter to exchange configurations between them sounds like a
good idea :-)
martin
Nicola Ken Barozzi wrote:
>
>
> Henning P. Schmiedehausen wrote:
>
>> Dan Diephouse <da...@envoisolutions.com> writes:
>>
>>
>>> Avalon's configuration classes are the only way to go. They *are*
>>> firmly embedded into the API and work very well. Commons-configuration
>>
>>
>> Borg way. As I expected. "Adapt or die".
>
>
> Avalon Configuration was born way before Commons Configuration. But
> you can always use Commons Configuration as an implementation behind
> the Avalon Configuration interface. If this is Borg, than every API is.
>
--
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, Nicola Ken Barozzi wrote:
>
>
> Henning P. Schmiedehausen wrote:
> > Dan Diephouse <da...@envoisolutions.com> writes:
> >
> >
> >>Avalon's configuration classes are the only way to go. They *are*
> >>firmly embedded into the API and work very well. Commons-configuration
> >
> > Borg way. As I expected. "Adapt or die".
>
> Avalon Configuration was born way before Commons Configuration. But you
> can always use Commons Configuration as an implementation behind the
> Avalon Configuration interface. If this is Borg, than every API is.
Note: Commons Configuration's java.util.Property-like implementation is from
JServ -- AFAIK, it's actually much older than anything in Avalon.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Henning P. Schmiedehausen wrote:
> Dan Diephouse <da...@envoisolutions.com> writes:
>
>
>>Avalon's configuration classes are the only way to go. They *are*
>>firmly embedded into the API and work very well. Commons-configuration
>
> Borg way. As I expected. "Adapt or die".
Avalon Configuration was born way before Commons Configuration. But you
can always use Commons Configuration as an implementation behind the
Avalon Configuration interface. If this is Borg, than every API is.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
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 02:24:03AM +0100, Martin Poeschl wrote:
> it would be nice to make torque an avalon component and extend the
> ComponentService to enable the configuration and initialisation of
> avalon components .. so we can kill stratum
Agreed. Getting rid of the stratum jar from my project.xml was an
initial motivation towards looking into this Avalonized Fulcrum
thing.
I'm hoping Fulcrum will be able to load a TR.props, however the
devil the configuration stuff works out, and so an addition of:
services.TorqueService.classname = org.apache.torque.Torque(Service?)
Would be all you'd have to do to use the Avalonized/Fulcrumized/
Überized [Henning :-)] Torque.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Martin Poeschl <mp...@marmot.at>.
Stephen Haberman wrote:
>On Mon, Jan 13, 2003 at 12:36:15AM +0000, Henning P. Schmiedehausen wrote:
>
>
>>>Avalon's configuration classes are the only way to go. They
>>>*are* firmly embedded into the API and work very well.
>>>Commons-configuration
>>>
>>>
>>Borg way. As I expected. "Adapt or die".
>>
>>
>
>All development is adaptation. Right now you are adapting turbine-2
>with the service code from your company's repo. We're just
>suggesting we adapt turbine-2 to the nifty lifecycles of the Avalon
>Framework.
>
it would be nice to make torque an avalon component and extend the
ComponentService to enable the configuration and initialisation of
avalon components .. so we can kill stratum
martin
--
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 12:36:15AM +0000, Henning P. Schmiedehausen wrote:
> >Avalon's configuration classes are the only way to go. They
> >*are* firmly embedded into the API and work very well.
> >Commons-configuration
>
> Borg way. As I expected. "Adapt or die".
All development is adaptation. Right now you are adapting turbine-2
with the service code from your company's repo. We're just
suggesting we adapt turbine-2 to the nifty lifecycles of the Avalon
Framework.
A rather minor adaptation is just taking a commons-configuration
object and converting it to an Avalon configuration object. Really
should not be a big deal. And even if that is considered a hack,
Avalon is open source, we can patch it, so the alternative is hardly
death.
> >This is what I thought also... By comitting to avalon, we are
>
> I will not commit to Avalon.
Based on current happenings? Or have you always harbored a
reluctance to Avalon (just curious)?
> >effectively saying that fulcrum is just a step to component
> >repository. The uber-component repository (TM) is coming. :)
>
> We here in germany have a firm aversion to words starting with
> "Über" which most of you americans can't write right (you're
> missing the essential key on your keyboard) :-) .
Hehe.
- 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>.
Dan Diephouse <da...@envoisolutions.com> writes:
>Avalon's configuration classes are the only way to go. They *are*
>firmly embedded into the API and work very well. Commons-configuration
Borg way. As I expected. "Adapt or die".
>This is what I thought also... By comitting to avalon, we are
I will not commit to Avalon.
>effectively saying that fulcrum is just a step to component repository.
> The uber-component repository (TM) is coming. :)
We here in germany have a firm aversion to words starting with "Über" which
most of you americans can't write right (you're missing the essential key
on your keyboard) :-) .
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 Mon, 13 Jan 2003, Dan Diephouse wrote:
> Avalon's configuration classes are the only way to go. They *are* firmly
> embedded into the API and work very well. Commons-configuration is
> comming along nicely from what I can tell, but as of now it doesn't have a
> release and doesn't have a fully working XML configuration part (correct
> me if I'm wrong). I don't see what advantage commons-configuration
> offers. Avalon will do both xml and properties configuration.
>
> In the future, if avalon chooses, it could use commons-configuration -
> which by then could have a 1.0 version as well as be fully up to speed,
> even surpassing avalon's configuration. But, the long and short of is
> that right now we are using avalon 4 and looking to get a nice stable
> development code base. Or maybe commons-configuration goes the way of the
> dogs and people only uses avalon's configuration... the future is later,
> now is now, and avalon should be our comittment for now (for reasons
> below).
A while back Martin pointed me to a DOM4J-based implementation of the
Commons Configuration interface, written by Kelvin Tan. I started reading
this thread, but took a break to refactor and integrate Kelvin's code into
the Configuration package. I have committed the code (untested, new unit
tests welcome ;) to CVS.
Commons Configuration can now read XML configuration files:
http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/configuration/src/java/org/apache/commons/configuration/DOM4JConfiguration.java?rev=1&content-type=text/vnd.viewcvs-markup
I would very much like to see Avalon adopt the Commons Configuration
interface, and am willing to write code to make that happen. In the mean
time, I recommend that Turbine/Fulcrum/Torque/etc. continue to use Commons
Configuration, and that we write a light weight adapter for Avalon's
configuration (as suggested by others as well), which delegates to a Commons
Configuration implementation.
> > But isn't 'jakarta-avalon-services' precisely what
> > 'jakarta-turbine-fulcrum' should become? I was under the impression
> > it was group consensus for this Avalonization to happen as Fulcrum
> > was evolving away from the Turbine core to become an awful lot like
> > Avalon (a server/component/services framework) to the point where
> > the duplication inefficient?
> >
> > The current Avalonization of Fulcrum, to me, is just a step to
> > Fulcrum being integrated into whatever components repository Avalon
> > soon forms for people like Cocoon, James, and Turbine so that
> > everyone can reuse cool stuff like Intake, off the top of my head,
> > in a shared environment.
>
> This is what I thought also... By comitting to avalon, we are
> effectively saying that fulcrum is just a step to component repository.
> The uber-component repository (TM) is coming. :)
I see the near-to-medium future of Fulcrum as Turbine's repository for
Avalonized components. Unfortunately we can't just dump what's there whole
hog, as it does have users (Scarab and SourceCast to name two huge pieces of
software from CollabNet).
- Dan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] fulcrum deprecation
Posted by Dan Diephouse <da...@envoisolutions.com>.
Stephen Haberman wrote:
> On Sun, Jan 12, 2003 at 11:11:46AM +0000, Henning P. Schmiedehausen wrote:
>
>>>>1) Changes to XML-based configuration, but we can probably set up an
>>>>adaptor that reads in the services.xxx.yyy style and converts it to
>>>>an Avalon Configuration object. So this would be transparent to
>>>>users, e.g. TurbineResources.properties will still work just fine,
>>>>but services would be converted completely over to the Avalon
>>>>configuration style.
>>
>>That would be the dumbest decision I've seen in many months.
>>
>>If you want XML based configuration, you should add an adaptor to the
>>commons-configuration and simply use it. That way, people who want to
>>keep their properties files won't get fucked up.
>
>
> The problem with using commons-configuration is that Avalon's
> Framework (which is firmly stable, unlike the container situation
> and they're very touchy about breaking backwards compatibility with
> it, from what I've seen) has it's own Configuration interface that
> everything in Avalon (components, containers, etc.) already uses.
>
> For me, being an Avalon outsider, but (relative) Turbine insider,
> the path of least resistance is to use Avalon's Configuration within
> services/components.
>
> How this Avalon Configuration object gets built (either from
> properties or XML) doesn't matter. For example, if the user is using
> XML-based configuration, we can pipe it right into Avalon's
> Configuration. If the user is using properties-based configuration,
> we could read the properties in via commons-configuration, let it do
> it's fancy interpreting, then convert over to Avalon Configuration.
> With luck, we'll even have test cases to ensure the translation goes
> successfully.
>
> I don't see what difference it makes that the Avalonized components
> use Avalon's Configuration, as it ensures framework/compatibility,
> as long as the old properties files still work.
Avalon's configuration classes are the only way to go. They *are*
firmly embedded into the API and work very well. Commons-configuration
is comming along nicely from what I can tell, but as of now it doesn't
have a release and doesn't have a fully working XML configuration part
(correct me if I'm wrong). I don't see what advantage
commons-configuration offers. Avalon will do both xml and properties
configuration.
In the future, if avalon chooses, it could use commons-configuration -
which by then could have a 1.0 version as well as be fully up to speed,
even surpassing avalon's configuration. But, the long and short of is
that right now we are using avalon 4 and looking to get a nice stable
development code base. Or maybe commons-configuration goes the way of
the dogs and people only uses avalon's configuration... the future is
later, now is now, and avalon should be our comittment for now (for
reasons below).
>>If you really "want to go to Avalon", please take the code, rename it
>>to "jakarta-avalon-services" and keep it out of the
>>jakarta-turbine-fulcrum repository.
>
>
> But isn't 'jakarta-avalon-services' precisely what
> 'jakarta-turbine-fulcrum' should become? I was under the impression
> it was group consensus for this Avalonization to happen as Fulcrum
> was evolving away from the Turbine core to become an awful lot like
> Avalon (a server/component/services framework) to the point where
> the duplication inefficient?
>
> The current Avalonization of Fulcrum, to me, is just a step to
> Fulcrum being integrated into whatever components repository Avalon
> soon forms for people like Cocoon, James, and Turbine so that
> everyone can reuse cool stuff like Intake, off the top of my head,
> in a shared environment.
This is what I thought also... By comitting to avalon, we are
effectively saying that fulcrum is just a step to component repository.
The uber-component repository (TM) is coming. :)
- Dan Diephouse
--
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 Sun, Jan 12, 2003 at 11:11:46AM +0000, Henning P. Schmiedehausen wrote:
> >> 1) Changes to XML-based configuration, but we can probably set up an
> >> adaptor that reads in the services.xxx.yyy style and converts it to
> >> an Avalon Configuration object. So this would be transparent to
> >> users, e.g. TurbineResources.properties will still work just fine,
> >> but services would be converted completely over to the Avalon
> >> configuration style.
>
> That would be the dumbest decision I've seen in many months.
>
> If you want XML based configuration, you should add an adaptor to the
> commons-configuration and simply use it. That way, people who want to
> keep their properties files won't get fucked up.
The problem with using commons-configuration is that Avalon's
Framework (which is firmly stable, unlike the container situation
and they're very touchy about breaking backwards compatibility with
it, from what I've seen) has it's own Configuration interface that
everything in Avalon (components, containers, etc.) already uses.
For me, being an Avalon outsider, but (relative) Turbine insider,
the path of least resistance is to use Avalon's Configuration within
services/components.
How this Avalon Configuration object gets built (either from
properties or XML) doesn't matter. For example, if the user is using
XML-based configuration, we can pipe it right into Avalon's
Configuration. If the user is using properties-based configuration,
we could read the properties in via commons-configuration, let it do
it's fancy interpreting, then convert over to Avalon Configuration.
With luck, we'll even have test cases to ensure the translation goes
successfully.
I don't see what difference it makes that the Avalonized components
use Avalon's Configuration, as it ensures framework/compatibility,
as long as the old properties files still work.
> If you really "want to go to Avalon", please take the code, rename it
> to "jakarta-avalon-services" and keep it out of the
> jakarta-turbine-fulcrum repository.
But isn't 'jakarta-avalon-services' precisely what
'jakarta-turbine-fulcrum' should become? I was under the impression
it was group consensus for this Avalonization to happen as Fulcrum
was evolving away from the Turbine core to become an awful lot like
Avalon (a server/component/services framework) to the point where
the duplication inefficient?
The current Avalonization of Fulcrum, to me, is just a step to
Fulcrum being integrated into whatever components repository Avalon
soon forms for people like Cocoon, James, and Turbine so that
everyone can reuse cool stuff like Intake, off the top of my head,
in a shared environment.
- 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>.
Dan Diephouse <da...@envoisolutions.com> writes:
>> 1) Changes to XML-based configuration, but we can probably set up an
>> adaptor that reads in the services.xxx.yyy style and converts it to
>> an Avalon Configuration object. So this would be transparent to
>> users, e.g. TurbineResources.properties will still work just fine,
>> but services would be converted completely over to the Avalon
>> configuration style.
That would be the dumbest decision I've seen in many months.
If you want XML based configuration, you should add an adaptor to the
commons-configuration and simply use it. That way, people who want to
keep their properties files won't get fucked up.
We painfully converted everything to use commons-configuration and then
someone needing a clue bat comes around and tears everything down again?
Sheesh people, don't you have _any_ taste?
I'm strongly -1 on that.
If you really "want to go to Avalon", please take the code, rename it
to "jakarta-avalon-services" and keep it out of the
jakarta-turbine-fulcrum repository.
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 Dan Diephouse <da...@envoisolutions.com>.
Hi Stephen,
I would just like to say that I think all these things sound great.
These are all issues I've run into when developing the new security
service code (which is coming along great...I'm about 80% of the way to
showing you something. Tomorrow I have a four hour train ride where I
can finish things off). Having an XML and properties file is a PITA.
And, using TurbineServices sucks.
Although I don't have much say (not a comitter), I would say do it in
HEAD. It is the next logical step for fulcrum. I'll help once you get
started and try to submit some patches, time allowing...
- Dan
Stephen Haberman wrote:
> On Thu, Jan 09, 2003 at 01:09:57PM -0800, Daniel Rall wrote:
>
>>I'd also be a fan of seeing the TurbineXxx classes go. I'm +1 on
>>deprecating them today and removing them in a while. I'm unsure
>>about the interface classes -- I suppose that those should
>>probably stay.
>
>
> Given that Fulcrum hasn't had a release and we're abandoning the
> singleton model of TurbineXxx classes, could we bump the version
> number to b3-dev and just remove them (them being the TurbineXxx
> singleton classes, the Service/BaseService and
> ServiceBroker/BaseServiceBroker)?
>
> (Hear me out below...a stark removal of them really does not place
> much burden on clients of Fulcrum)
>
> As I see it, there are three things the user sees when interacting
> with Fulcrum:
>
> 1) Properties-based configuration file
> 2) TurbineServices.getInstance().getService(name) lookup
> 3) Service interfaces
>
> So, when going to Avalon:
>
> 1) Changes to XML-based configuration, but we can probably set up an
> adaptor that reads in the services.xxx.yyy style and converts it to
> an Avalon Configuration object. So this would be transparent to
> users, e.g. TurbineResources.properties will still work just fine,
> but services would be converted completely over to the Avalon
> configuration style.
>
> 2) Changes to something like
> FulcrumContainer.lookup(ServiceInterface.ROLE). This would not be
> transparent, but it is a straight forward conversion.
>
> (Note that FulcrumContainer just composes ECM or Fortress and
> forwards the lookup to it; also note that FulcrumContainer would
> have methods like initialize(String newXmlFile) and
> initializeOldConfiguration(String oldPropertiesFile)).
>
> 3) Stay the same, except NAME is changed to ROLE.
>
> None of the changes involve architectural changes in the clients of
> Fulcrum. And so if these changes are well documented, e.g. on the
> wiki as UpgradingToAvalonizedFulcrum, I think it is safe to do a
> straight conversion instead of worrying about the baggage of
> deprecation and backwards compatibility (which removes a lot of
> the potential elegantness that Avalon promises).
>
> Also as a part of this stark conversion, service implementations
> would no longer have Service/BaseService to implement/inherit, but
> the conversion over to Avalon lifecycles interfaces is
> straightforward and is much easier to do in one step than
> implementing both the Fulcrum lifecycle and Avalon lifecycle
> interfaces.
>
> Alternatively, if this scares people, can I have a branch to do
> exactly this? I've been going through code and the itch to just do
> away with Service/BaseService/ServiceBroker/BaseServiceBroker and
> start with clean Avalon is just killing me.
>
> Thanks,
> 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 12:33:09AM +0000, Henning P. Schmiedehausen wrote:
> Stephen Haberman <st...@beachead.com> writes:
> And we configure 50% of the application (Turbine) in a properties file
> and 50% (the services) in a XML file with completely different
> syntax? But the services themselves are added in the properties
> file. Oh wait, only some services (those from Fulcrum) are configured
> in the XML file, some others (like the ones integrated in Turbine) are
> still configured in the properties file.
No, you configure the entire application from
TurbineResources.properties, just like it is. But within Turbine-2,
when you initialize Fulcrum, you call something like:
Fulcrum.initializeFromOldPropertiesFile("TR.props");
(as compared to Fulcrum.initialize("new-config.xml")
Which then takes all of the services.xxx.yyy stuff, ignores the rest
of the Turbine related settings, dumps the it through
commons-configuration to get the interpreting done correctly, and
spits out an XML string to pass off to Avalon's Configuration object.
Everything is completely transparent to the user.
- 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:
>So a straight forward conversion without the baggage of backwards
>compatibility/deprecation in _only_ the initialization/lookup part
>of it (that is also well documented, e.g. search, ideally
>automatically, your source and replace a with b and x with y) is not
>too much to ask of from users.
And we configure 50% of the application (Turbine) in a properties file
and 50% (the services) in a XML file with completely different
syntax? But the services themselves are added in the properties
file. Oh wait, only some services (those from Fulcrum) are configured
in the XML file, some others (like the ones integrated in Turbine) are
still configured in the properties file.
And of course there is no up-to-date documentation about all this,
because the docs for turbine are already a mess and two releases out
of date.
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 Sun, Jan 12, 2003 at 11:08:11AM +0000, Henning P. Schmiedehausen wrote:
> But: To hell with deprecation. Interface compatibility, backward
> compatibility and everything else. We will have a new code base that
> shares some code with the current turbine. Then we can as well rename
> it (just as Jason did with Plexus).
Just to clarify (you probably already understand, if anything, I'm
justifying this to myself), we're not changing the interfaces of the
services themselves, just how you initialize Fulcrum and then lookup
services. My feeling is that these two steps, initialization and
lookup, take up a small percentage of the code that uses Fulcrum or
even the Turbine-2 services.
So a straight forward conversion without the baggage of backwards
compatibility/deprecation in _only_ the initialization/lookup part
of it (that is also well documented, e.g. search, ideally
automatically, your source and replace a with b and x with y) is not
too much to ask of from users.
- 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:
>So besides forgetting my initial +1, there is another alternative
>where we keep the TurbineXxx classes, and the Service interface, but
>still (preferably) kill BaseService/ServiceBroker/BaseServiceBroker
>and instead add a AvalonToServiceAdaptor class that implements
>Service.
Ok, here comes my vote.
It is +0
And I will tell you, why:
Basically I've been persuaded over the last few weeks that going with
the Avalon lifecycle is a good thing. So I will want to get the
Services both from Turbine and Fulcrum put together in a "best of both
worlds" scenario and then converted to the lifecycle. At the same time
we will have turbine-2.4-dev which will be ready to use these
services. By going so we will transition smooth from our current
Turbine to a Turbine + Container + Avalonized Services.
If we pull the plug right now and do a massive "this is now Avalonized
and we pull the plug on the stuff being usable with Turbine 2.2 and
2.3-dev" then at least for me there is not much sense to continue
developing on Turbine 2.3-dev. I would put a branch tag into the
turbine-2 repository and start working on a massively changed Turbine
code which is able to use a (any?) avalon container to start up
services, change the integrated services (as long as they're not
already in Fulcrum, because Turbine + Fulcrum will be my code
base. Just as it is internal to INTERMETA since many months).
I will have such a bugger running in a few weeks, mainly because I
already have much of that code in place in our internal CVS. This code
base is already quite diverted from the jakarta CVS which is why it
takes me much more time to back port things like the
TorqueSecurityService to the jakarta turbine-2.
But: To hell with deprecation. Interface compatibility, backward
compatibility and everything else. We will have a new code base that
shares some code with the current turbine. Then we can as well rename
it (just as Jason did with Plexus).
And the "to hell with deprecation" is what makes my vote +0.
And the fact that for 2.3-dev from the already thinned out developers
base (In fact, at the moment it's Martin, Quinton and me) at least me
will no longer work on the turbine-2 HEAD. Then we can abandon it as
well. And kiss our current user base finally goodbye.
At least I have only two hands, have a daytime job which is
turbine-related (ATM) but keeps my time to work on currently two code
bases short. I will not work on three code bases.
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>.
So besides forgetting my initial +1, there is another alternative
where we keep the TurbineXxx classes, and the Service interface, but
still (preferably) kill BaseService/ServiceBroker/BaseServiceBroker
and instead add a AvalonToServiceAdaptor class that implements
Service.
So all of the services are pure Avalon with no Fulcrum cruft, but
then the TurbineXxx classes could do:
public class TurbineXxx {
public static Service getService() {
return
new AvalonToServiceAdaptor(
FulcrumContainer.lookup(XxxService.ROLE));
}
-- all of the old static helper methods that just do:
-- getService().getXxx()
}
This keeps Service around and would let old applications still use
TurbineXxx while letting the services themselves be pure Avalon.
- Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>