You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Siegfried Goeschl <si...@it20one.at> on 2005/02/14 11:09:14 UTC
Plans for Fulcrum release ....
Hi folks,
within the next 4 weeks I want to cut a new release of Fulcrum for
Turbine 2.4.x
RECENT FULCRUM CHANGES
===========================================================
1) there is a new Avalon container called YAAFI (Yet Another Avalon
Framework Implementation) to run the existing Fulcrum services. YAAFI is
light-weight Avalon container to be embedded in other applications and
comes with litte baggage in terms of dependencies. It is intended as
replacement for the depecated ECM and Merlin Container.
2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
3) Fulcrum ResouceManager Service - a facade for accessing resources
currently file system
4) Fulcrum Groovy Service - allows execution of Groovy scripts with
access to the Avalon infrastructure
PENDING FULCRUM CHANGES (NOT COMMITTED YET)
===========================================================
1) YAAFI improvements
1.1) improved bootstrapping of YAAFI
1.2) transparent decryption of configuration files based on JCA/JCE
1.3) support for <component-type> to specify the container type to be
expected by the component. This allows for reuse of existing services
written for Excalibur, Phoenix or Fortress
1.4) support for <container-type> to allow YAAFI to be embedded in a
Fortress or Phoenix container, e.g. JAMES
2) Fulcrum PBE Service provides a service for Password Based Encryption
based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
ResouceManager Service. This improved service will not be backward
compatible
4) I'm tinkering with automatic reconfiguration of YAAFI using a
dedicated Fulcrum Reconfiguration Service. This service would monitor
the componentConfiguration.xml and reconfigure YAAFI if the file has
changed. This allows automatic reconfiguration without any client/server
communication
5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
application
6) Fulcrum ResourceManager Service provides transparent
encryption/decryption of resources.
REQUEST FOR HELP
===========================================================
1) Help from the Excalibur community would be greatly appreciated to
kickstart component compatibilty testing
2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
Thanks in advance
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
I'm not a Turbine comitter, but. Fulcrum shouldn't be tied to any particular framework or even the servlet api.
There are no advantages doing otherwise !
-- you can stop reading this message here --
On Xingu I have glue code called Esqueleto (skeleton in english) wich is responsible for joining the components (Xingu, Fulcrum, etc) to the framework you want. Only Turbine is working at the moment.
So, one could make something like this :
1) Install your favorite framework (Turbine in this case)
2) cd $ESQUELETO_HOME ; make turbine-base-app (or something else)
3) Edit the configuration files to include/exclude the components you want (Xingu, Fulcrum, etc)
Done. There are a set of actions/screens/templates/tools to handle common tasks such as user administration, security, etc !
OBS: CSS and a skin tool plays a central role here !
That's what I'd like to achieve !
Cheers !
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e
Serviços (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sf.net
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr <ja...@gmail.com> escreveu:
> De: J Aaron Farr <ja...@gmail.com>
> Data: Thu, 17 Feb 2005 18:52:04 -0500
> Para: Excalibur Developers List <de...@excalibur.apache.org>
> Assunto: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
>
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
I'm not a Turbine comitter, but. Fulcrum shouldn't be tied to any particular framework or even the servlet api.
There are no advantages doing otherwise !
-- you can stop reading this message here --
On Xingu I have glue code called Esqueleto (skeleton in english) wich is responsible for joining the components (Xingu, Fulcrum, etc) to the framework you want. Only Turbine is working at the moment.
So, one could make something like this :
1) Install your favorite framework (Turbine in this case)
2) cd $ESQUELETO_HOME ; make turbine-base-app (or something else)
3) Edit the configuration files to include/exclude the components you want (Xingu, Fulcrum, etc)
Done. There are a set of actions/screens/templates/tools to handle common tasks such as user administration, security, etc !
OBS: CSS and a skin tool plays a central role here !
That's what I'd like to achieve !
Cheers !
--
Leandro Rodrigo Saad Cruz
IT - Inter Business Tecnologia e
Serviços (IB)
http://www.ibnetwork.com.br
http://db.apache.org/ojb
http://xingu.sf.net
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr <ja...@gmail.com> escreveu:
> De: J Aaron Farr <ja...@gmail.com>
> Data: Thu, 17 Feb 2005 18:52:04 -0500
> Para: Excalibur Developers List <de...@excalibur.apache.org>
> Assunto: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
>
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 February 2005 18:01, Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
A previous discussion led to the conclusion that all configuration and
deployment files must be interpreted as they are now, which leads to an
immense compatibility issue, since you effectively need to be Phoenix/Loom
compatible in every respect.
Now, perhaps such ambitions drop over time, but if not, then I think that
either James resurrects Phoenix as their own internal container (much like
Cocoon now have their own ECM+) or a migration to Loom are the only
reasonable paths forward.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 18 February 2005 18:01, Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
A previous discussion led to the conclusion that all configuration and
deployment files must be interpreted as they are now, which leads to an
immense compatibility issue, since you effectively need to be Phoenix/Loom
compatible in every respect.
Now, perhaps such ambitions drop over time, but if not, then I think that
either James resurrects Phoenix as their own internal container (much like
Cocoon now have their own ECM+) or a migration to Loom are the only
reasonable paths forward.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Ahmed Mohombe <am...@yahoo.com>.
> I am currently working on removing avalon dependence from current v2x
> source of james and making james a set of POJOs
> And I guess by the end of the following week it will be ready to be
> testable by other developers
Glad to hear that :).
We can't wait to test it :).
>> *) stick with Phoenix or migrate to Loom
>> *) make a transition to Fortress to stay under an ASF umbrella
>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>> there choice for the migration process
>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
>
> I vote for the last one
> + reuse components already written by making them POJOs
Sometimes extreme measures are the best to clean something. Maybe if
other software projects would follow your pattern, it wouldn't be so
much "bloatware" out there :).
Ahmed.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Siegfried Goeschl wrote:
> Hi Alexander,
>
> it is none of my business but it means that you have to migrate the
> cornerstone and excalibur-datasource stuff as well?! I also assume that
> you are using a IOC container such as Hivemind or Pico/Nano Container?!
Well my goal is to make james a set of CDI style POJOs
As for datasource stuff i just leave interface dependency
"public MyPOJO(DataSourceStuffInterface ds, OtherDepsHere ...)"
and write dummy implementation of that interface ready to be
junit-tested, launched by developer to test the idea of CDI IoC applied
to james current code.
Same applies to other non-jdbc related interfaces.
If someone wants he can use cornerstone/excalibur implementations of
those interfaces.
My point is to remove ugly configuration code from james and make POJOs
not search its configuration itself but accept dependent components as
parameters in constructor.
Injection of dependent components (the process of configuring) is a
concern of any light-weight container, the exact container (whether it
is hivemind/picocontainer) does not matter for me.
As an example I wrote dumb container (one class few K of code) which is
configured by standard james-config.xml familiar to james users and
developers.
Executive summary: make james a set of POJOs, container does not matter
if you have a set of POJOs
>
> Cheers,
>
> Siegfried Goeschl
>
> Siegfried Goeschl
>
> Alexander Zhukov wrote:
>
>> Siegfried Goeschl wrote:
>>
>>> Hi Aron,
>>>
>>> I would like to point out that there is the James project suffering
>>> badly from the Avalonic wars (hence the cross-posting to the James
>>> Developer List). They recently had a long discussion to make an
>>> Avalon-free JamesNG
>>> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
>>> feeling is that it won't be an easy task.
>>
>>
>> I am currently working on removing avalon dependence from current v2x
>> source of james and making james a set of POJOs
>> And I guess by the end of the following week it will be ready to be
>> testable by other developers
>> Yes you are right the task of throwing out avalon is not easy but its
>> worth the trouble.
>> It took me about two weeks already - I have pop3 and smtp servers
>> running, but not clean enough to show others.
>>
>>
>>> As a casual James user and non-contributor I could imagine a few
>>> ways to go
>>>
>>> *) stick with Phoenix or migrate to Loom
>>> *) make a transition to Fortress to stay under an ASF umbrella
>>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>>> there choice for the migration process
>>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big
>>> Bang
>>
>>
>> I vote for the last one
>> + reuse components already written by making them POJOs
>>
>>
>>> I'm not sure what the current mood is - well, my first impression is
>>> that removing Avalon make them very happy :-) - but we have to keep
>>> the James community informed on our on-going work regarding Fortress
>>> and Fulcrum YAAFI.
>>>
>>> Cheers,
>>>
>>> Siegfried Goeschl
>>>
>>>
>>> Maybe the James folks might be interested to hear that
>>>
>>> J Aaron Farr wrote:
>>>
>>>> Thanks for the clarifications. I'm very interested in seeing what
>>>> Excalibur can do to make things easier for the Turbine folks.
>>>>
>>>>
>>>>
>>>>> I agree. You should be able to setup a container in a matter of
>>>>> minutes.
>>>>> It should be simple to make simple things.
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Exactly.
>>>>
>>>> IMHO Fortress is pretty simply already, but we need better
>>>> documentation and we can definitely make it more simple. The goal of
>>>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>>>
>>>> So, if I'm reading this correctly, Fulcrum will become a more generic
>>>> component library not necessarily tied to Turbine, right?
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum
release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Alexander,
it is none of my business but it means that you have to migrate the
cornerstone and excalibur-datasource stuff as well?! I also assume that
you are using a IOC container such as Hivemind or Pico/Nano Container?!
Cheers,
Siegfried Goeschl
Siegfried Goeschl
Alexander Zhukov wrote:
> Siegfried Goeschl wrote:
>
>> Hi Aron,
>>
>> I would like to point out that there is the James project suffering
>> badly from the Avalonic wars (hence the cross-posting to the James
>> Developer List). They recently had a long discussion to make an
>> Avalon-free JamesNG
>> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
>> feeling is that it won't be an easy task.
>
> I am currently working on removing avalon dependence from current v2x
> source of james and making james a set of POJOs
> And I guess by the end of the following week it will be ready to be
> testable by other developers
> Yes you are right the task of throwing out avalon is not easy but its
> worth the trouble.
> It took me about two weeks already - I have pop3 and smtp servers
> running, but not clean enough to show others.
>
>
>> As a casual James user and non-contributor I could imagine a few
>> ways to go
>>
>> *) stick with Phoenix or migrate to Loom
>> *) make a transition to Fortress to stay under an ASF umbrella
>> *) jump-start an Avalon-free JamesNG and use an Avalon container of
>> there choice for the migration process
>> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big
>> Bang
>
> I vote for the last one
> + reuse components already written by making them POJOs
>
>
>> I'm not sure what the current mood is - well, my first impression is
>> that removing Avalon make them very happy :-) - but we have to keep
>> the James community informed on our on-going work regarding Fortress
>> and Fulcrum YAAFI.
>>
>> Cheers,
>>
>> Siegfried Goeschl
>>
>>
>> Maybe the James folks might be interested to hear that
>>
>> J Aaron Farr wrote:
>>
>>> Thanks for the clarifications. I'm very interested in seeing what
>>> Excalibur can do to make things easier for the Turbine folks.
>>>
>>>
>>>
>>>> I agree. You should be able to setup a container in a matter of
>>>> minutes.
>>>> It should be simple to make simple things.
>>>>
>>>
>>>
>>>
>>> Exactly.
>>>
>>> IMHO Fortress is pretty simply already, but we need better
>>> documentation and we can definitely make it more simple. The goal of
>>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>>
>>> So, if I'm reading this correctly, Fulcrum will become a more generic
>>> component library not necessarily tied to Turbine, right?
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
[jamesng] Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
Posted by Alexander Zhukov <zh...@ukrpost.net>.
Siegfried Goeschl wrote:
> Hi Aron,
>
> I would like to point out that there is the James project suffering
> badly from the Avalonic wars (hence the cross-posting to the James
> Developer List). They recently had a long discussion to make an
> Avalon-free JamesNG
> (http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
> feeling is that it won't be an easy task.
I am currently working on removing avalon dependence from current v2x
source of james and making james a set of POJOs
And I guess by the end of the following week it will be ready to be
testable by other developers
Yes you are right the task of throwing out avalon is not easy but its
worth the trouble.
It took me about two weeks already - I have pop3 and smtp servers
running, but not clean enough to show others.
> As a casual James user and non-contributor I could imagine a few ways
> to go
>
> *) stick with Phoenix or migrate to Loom
> *) make a transition to Fortress to stay under an ASF umbrella
> *) jump-start an Avalon-free JamesNG and use an Avalon container of
> there choice for the migration process
> *) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I vote for the last one
+ reuse components already written by making them POJOs
> I'm not sure what the current mood is - well, my first impression is
> that removing Avalon make them very happy :-) - but we have to keep the
> James community informed on our on-going work regarding Fortress and
> Fulcrum YAAFI.
>
> Cheers,
>
> Siegfried Goeschl
>
>
> Maybe the James folks might be interested to hear that
>
> J Aaron Farr wrote:
>
>> Thanks for the clarifications. I'm very interested in seeing what
>> Excalibur can do to make things easier for the Turbine folks.
>>
>>
>>
>>> I agree. You should be able to setup a container in a matter of minutes.
>>> It should be simple to make simple things.
>>>
>>
>>
>> Exactly.
>>
>> IMHO Fortress is pretty simply already, but we need better
>> documentation and we can definitely make it more simple. The goal of
>> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>>
>> So, if I'm reading this correctly, Fulcrum will become a more generic
>> component library not necessarily tied to Turbine, right?
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Fri, 18 Feb 2005 00:54:54 +0100, Eric Pugh
<ep...@www.opensourceconnections.com> wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
Unless I'm completely out of the loop, there is no release plan for
Fortress 2.0 yet. Heck, we barely have a set of requirements. :)
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Fri, 18 Feb 2005 00:54:54 +0100, Eric Pugh
<ep...@www.opensourceconnections.com> wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
Unless I'm completely out of the loop, there is no release plan for
Fortress 2.0 yet. Heck, we barely have a set of requirements. :)
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leo Simons <ma...@leosimons.com>.
Hi everyone,
On 18-02-2005 00:54, "Eric Pugh" <ep...@www.opensourceconnections.com>
wrote:
> I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
> it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
> and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
> swapping to that.
"Fortress 2" is more the general idea that exists around here that we have
some stuff to document, some things to clean up, some features to implement.
Or maybe that should read "a lot of stuff". It's clear that there's work to
be done.
None of that is written down anywhere central, there's no roadmap or
development plan, or anything like that. You know what these things are
like. If someone gets an itch and gets to work, there /could/ be a
revolutionised release in a few months. It might also be years. But I
wouldn't wait for it.
I suggest you don't actually shoot ECM (it's almost dead already, save the
iron). I haven't looked at Yaafi, but if that is what works for you now, I'd
suggest moving forward with it. As long as your aware of what things to be
weary of (and that seems to be the case), phasing Yaafi out later should be
doable, if you want to.
Best regards,
- Leo Simons
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@www.opensourceconnections.com>.
You are correct about Fulcrum will become a more generic component library.
Although actually, at this time, I would be quite happy in declaring that it
IS a component library not tied to Turbine.
None of the released components depend on Turbine at all, though of course,
due to their heritage, they are primarily used with Turbine. Some of the
unreleased components are somewhat Turbine specific, such as template, and may
have limited utility. They may end up moving to the jakarta-turbine-2 code
base.
The idea is that any component that needs turbine should be IN the Turbine
codebase, with an org.apache.turbine package. Org.apache.fulcrum really
should be completely reusable outside of Turbine.
I hate to ask the "When is Fortress 2 Done" question, b/c I know how bad form
it is. But I'll have to ask, as it may make sense for us to just shoot ECM,
and use Yaafi, with the idea of waiting till Fortress 2 comes out, and
swapping to that.
Eric
On Thu, 17 Feb 2005 18:52:04 -0500, J Aaron Farr wrote
> Thanks for the clarifications. I'm very interested in seeing what
> Excalibur can do to make things easier for the Turbine folks.
>
> > I agree. You should be able to setup a container in a matter of minutes.
> > It should be simple to make simple things.
>
> Exactly.
>
> IMHO Fortress is pretty simply already, but we need better
> documentation and we can definitely make it more simple. The goal of
> Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
> So, if I'm reading this correctly, Fulcrum will become a more generic
> component library not necessarily tied to Turbine, right?
>
> --
> jaaron
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
--
OpenSource Connections (http://www.opensourceconnections.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aron,
I would like to point out that there is the James project suffering
badly from the Avalonic wars (hence the cross-posting to the James
Developer List). They recently had a long discussion to make an
Avalon-free JamesNG
(http://www.mail-archive.com/server-dev@james.apache.org/) but my gut
feeling is that it won't be an easy task.
As a casual James user and non-contributor I could imagine a few ways to go
*) stick with Phoenix or migrate to Loom
*) make a transition to Fortress to stay under an ASF umbrella
*) jump-start an Avalon-free JamesNG and use an Avalon container of
there choice for the migration process
*) kick out Avalon, jump-start an Avalon-free JamesNG and go for Big Bang
I'm not sure what the current mood is - well, my first impression is
that removing Avalon make them very happy :-) - but we have to keep the
James community informed on our on-going work regarding Fortress and
Fulcrum YAAFI.
Cheers,
Siegfried Goeschl
Maybe the James folks might be interested to hear that
J Aaron Farr wrote:
>Thanks for the clarifications. I'm very interested in seeing what
>Excalibur can do to make things easier for the Turbine folks.
>
>
>
>>I agree. You should be able to setup a container in a matter of minutes.
>>It should be simple to make simple things.
>>
>>
>
>Exactly.
>
>IMHO Fortress is pretty simply already, but we need better
>documentation and we can definitely make it more simple. The goal of
>Fortress 2.0 should be to make implementations like yaafi unnecessary.
>
>So, if I'm reading this correctly, Fulcrum will become a more generic
>component library not necessarily tied to Turbine, right?
>
>
>
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
Thanks for the clarifications. I'm very interested in seeing what
Excalibur can do to make things easier for the Turbine folks.
> I agree. You should be able to setup a container in a matter of minutes.
> It should be simple to make simple things.
Exactly.
IMHO Fortress is pretty simply already, but we need better
documentation and we can definitely make it more simple. The goal of
Fortress 2.0 should be to make implementations like yaafi unnecessary.
So, if I'm reading this correctly, Fulcrum will become a more generic
component library not necessarily tied to Turbine, right?
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
Thanks for the clarifications. I'm very interested in seeing what
Excalibur can do to make things easier for the Turbine folks.
> I agree. You should be able to setup a container in a matter of minutes.
> It should be simple to make simple things.
Exactly.
IMHO Fortress is pretty simply already, but we need better
documentation and we can definitely make it more simple. The goal of
Fortress 2.0 should be to make implementations like yaafi unnecessary.
So, if I'm reading this correctly, Fulcrum will become a more generic
component library not necessarily tied to Turbine, right?
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
RE: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Leandro's vision of the future for Turbine is very much in line with
what the committers would like to see happen to Turbine. Turbine 2.3
was the beginning of cleaning up the massive mess of code by introducing
the first Avalon container based on ECM and moving Torque to it's own
project. Turbine 2.4 (stil in development) has continued that process.
We continue to use ECM primarily in Turbine, have deprecated many of the
old Turbine services in favor of released components from the Fulcrum
project. Turbine 2.5 (somewhere down the road) will have a very minimal
set of dependencies, and you add the ones you require.
Part of the interest in using Yaafi was that we needed an easy to setup
container for running unit tests. And I liked the idea of having two
containers, Yaafi and ECM, to validate that the Fulcrum components are
really portable.
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Thursday, February 17, 2005 5:35 AM
To: siegfried.goeschl@it20one.at
Cc: Turbine Developers List; Excalibur Developers List
Subject: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded
a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few
> services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of
Turbine
> - well, not a big deal but we would have to migrate our own services.
Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to
> achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum,
> +Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
RE: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@opensourceconnections.com>.
Leandro's vision of the future for Turbine is very much in line with
what the committers would like to see happen to Turbine. Turbine 2.3
was the beginning of cleaning up the massive mess of code by introducing
the first Avalon container based on ECM and moving Torque to it's own
project. Turbine 2.4 (stil in development) has continued that process.
We continue to use ECM primarily in Turbine, have deprecated many of the
old Turbine services in favor of released components from the Fulcrum
project. Turbine 2.5 (somewhere down the road) will have a very minimal
set of dependencies, and you add the ones you require.
Part of the interest in using Yaafi was that we needed an easy to setup
container for running unit tests. And I liked the idea of having two
containers, Yaafi and ECM, to validate that the Fulcrum components are
really portable.
Eric
-----Original Message-----
From: Leandro Rodrigo Saad Cruz [mailto:leandro@ibnetwork.com.br]
Sent: Thursday, February 17, 2005 5:35 AM
To: siegfried.goeschl@it20one.at
Cc: Turbine Developers List; Excalibur Developers List
Subject: Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release
....
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded
a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few
> services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of
Turbine
> - well, not a big deal but we would have to migrate our own services.
Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to
> achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum,
> +Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of Turbine
> - well, not a big deal but we would have to migrate our own services. Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Leandro Rodrigo Saad Cruz <le...@ibnetwork.com.br>.
On Thu, 2005-02-17 at 11:33 +0100, Siegfried Goeschl wrote:
> Hi Aaron,
>
> 1) Original Motivation for YAAFI
>
> 1.1) A few months ago I worked on a JSP/Struts web application for a
> customer and they needed to integrate a few external services over the
> time. I decided to go with Avalon components but I got frustrated with
> the various containers (Excalibur, Merlin), my inability to get them
> running and the amount of additional dependencies. The problem was not
> my frustration as external consultant (I get paid for that) but my
> customer would have plainly recjected the Avalon approach if adds too
> much complexity (they devil you don't know). To cover my a** I coded a
> minimal Avalon container over night.
I agree. You should be able to setup a container in a matter of minutes.
It should be simple to make simple things.
>
> 1.2) In my own company we have a Turbine application and a few services
> which could have been contributed years ago but the Turbine Service
> Framework is convoluted due to the monolithic approach of Turbine. We
> found out that the only stuff we used from Turbine were a few services
> and our own stuff. And we are sort of stuck to an old version of Turbine
> - well, not a big deal but we would have to migrate our own services. Or
> we take the Fulcrum approach which would fit nicely ....
Turbine evolved into a huge mass of code with no defined role or
objective. In my opinion Turbine should be a minimal framework with :
- A pipeline
- Security an error handling
That's it. We use Turbine on my company too. but all services are
disable (except the core). What I really like about turbine is the way
you can organize your page with screens, layouts and navigations !
> And I would appreciate some sort of cross-project cooperation to achieve
> the following long-term goals
>
> +) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
> run with Fortress and YAAFI
I can setup Xingu to use YAAFI. right now we are using Fortress.
>
> Cheers,
>
> Siegfried Goeschl
Cheers !
--
Leandro Rodrigo Saad Cruz
CTO - InterBusiness Tecnologia e Serviços
SiteDaFesta : www.sitedafesta.com.br
OJB : db.apache.org/ojb
XINGU : xingu.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aaron,
1) Original Motivation for YAAFI
1.1) A few months ago I worked on a JSP/Struts web application for a
customer and they needed to integrate a few external services over the
time. I decided to go with Avalon components but I got frustrated with
the various containers (Excalibur, Merlin), my inability to get them
running and the amount of additional dependencies. The problem was not
my frustration as external consultant (I get paid for that) but my
customer would have plainly recjected the Avalon approach if adds too
much complexity (they devil you don't know). To cover my a** I coded a
minimal Avalon container over night.
1.2) In my own company we have a Turbine application and a few services
which could have been contributed years ago but the Turbine Service
Framework is convoluted due to the monolithic approach of Turbine. We
found out that the only stuff we used from Turbine were a few services
and our own stuff. And we are sort of stuck to an old version of Turbine
- well, not a big deal but we would have to migrate our own services. Or
we take the Fulcrum approach which would fit nicely ....
1.3) After another failure with Merlin I decided to go with Avalon
services and my minimal Avalon container. I contacted Eric Pugh if my
quick-and-dirty implementation would be of interest. And I was plainly
astonished that he said "yes"?!!
2) The Role of an Avalon Container
In my opinion the various Avalon projects were mainly focused on the
container implementation. We all love the toys were are implementing but
for the rest of the world an Avalon container is a commodity. Nothing
else - a tool to get a job done. An added value are the available
services with test cases, documentation and automatic build. An Avalon
container with a bunch of good services is a much better tool to get a
job done ... :-)
There is no "container to rule them all" - therefore YAAFI is per
definition a plain and simple AvalonContainer. Writing YAAFI initially
was a sort of personal requirement (to put it politely) but extending
YAAFI to compete with Fortress or Phoenix is a no-brainer. This will not
happen.
3) The Current State of YAAFI
I will finish the contract context thingie tommorrow - then it should be
possible to run any Avalon component with YAAFI. And yes, YAAFI is used
in production environment at least in our company. I think Eric Pugh
tinkered with Scarab - anyone else out there?!
And after proper integration with Turbine there will be more production
environments.
4) The Future of Jakarta Avalon Containers
I see YAAFI as an approiate choice for command-line applications, small
server applications and embedded Avalon container for Turbine and if you
need more bells and whistle you still have other choices - you name them.
And I would appreciate some sort of cross-project cooperation to achieve
the following long-term goals
+) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
run with Fortress and YAAFI
+) promote Fulcrum as an Avalon Service project out of obscurity
+) convince the Excalibur community that YAAFI is not an odd project of
a lone hacker (which it is) to be ignored but as starting point to
migrate over to Fortress
5) The Usual Disclaimer
This is strictly my personal opinion since I have no idea what the rest
of the community is thinking ( "They smoked and did inhale", "Avalon is
dead", "Lets get rid of IOC Type 1 containers", "That was good book",
...) and I'm only a small committer. Maybe the Turbine/Fulcrum PMCs can
shed some light on plans for the future .... hint, hint.
Cheers,
Siegfried Goeschl
J Aaron Farr wrote:
>On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl
><si...@it20one.at> wrote:
>
>
>
>>The usage szenario would be : you find a few funky Fulcrum services but
>>they depend on a Merlin Avalon contract regarding the Context. If I
>>understand it correctly you can't use the components directly since the
>>blow up during contextialize() trying to access "urn:avalon:home" and
>>"urn:avalon:temp".
>>
>>
>
>First off, we (Excalibur) need to fix up the context contracts. It
>should be much easier now that Avalon has disolved. If nothing else,
>we could look at having Fortress handle all previous context
>"standards".
>
>
>
>>We have the same requirement for Turbine - if the Turbine service
>>framework does not find a service it should ask all its children
>>implementing ServiceManager. In this case it is not a big deal since
>>this is the only sensible solution to provide container-transparent
>>access to components. But in Excalibur land it has a rather akward semantic.
>>
>>
>
>Sounds like it would involve a change to the default ServiceManager or
>a new ServiceManager implementation.
>
>Siegfried, what was the original motivation for YAAFI? Was it the
>existance of multiple Avalon containers? Was it the number of jar
>dependencies? Is YAAFI intended to be used in a production
>environment?
>
>I'd like to see Fortress evolve to be simple enough that there
>wouldn't be a need for Yet Another Avalon Framework Implementation.
>Maybe Turbine's needs can help drive that.
>
>
>
The YAAFI Manifesto - WAS Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Aaron,
1) Original Motivation for YAAFI
1.1) A few months ago I worked on a JSP/Struts web application for a
customer and they needed to integrate a few external services over the
time. I decided to go with Avalon components but I got frustrated with
the various containers (Excalibur, Merlin), my inability to get them
running and the amount of additional dependencies. The problem was not
my frustration as external consultant (I get paid for that) but my
customer would have plainly recjected the Avalon approach if adds too
much complexity (they devil you don't know). To cover my a** I coded a
minimal Avalon container over night.
1.2) In my own company we have a Turbine application and a few services
which could have been contributed years ago but the Turbine Service
Framework is convoluted due to the monolithic approach of Turbine. We
found out that the only stuff we used from Turbine were a few services
and our own stuff. And we are sort of stuck to an old version of Turbine
- well, not a big deal but we would have to migrate our own services. Or
we take the Fulcrum approach which would fit nicely ....
1.3) After another failure with Merlin I decided to go with Avalon
services and my minimal Avalon container. I contacted Eric Pugh if my
quick-and-dirty implementation would be of interest. And I was plainly
astonished that he said "yes"?!!
2) The Role of an Avalon Container
In my opinion the various Avalon projects were mainly focused on the
container implementation. We all love the toys were are implementing but
for the rest of the world an Avalon container is a commodity. Nothing
else - a tool to get a job done. An added value are the available
services with test cases, documentation and automatic build. An Avalon
container with a bunch of good services is a much better tool to get a
job done ... :-)
There is no "container to rule them all" - therefore YAAFI is per
definition a plain and simple AvalonContainer. Writing YAAFI initially
was a sort of personal requirement (to put it politely) but extending
YAAFI to compete with Fortress or Phoenix is a no-brainer. This will not
happen.
3) The Current State of YAAFI
I will finish the contract context thingie tommorrow - then it should be
possible to run any Avalon component with YAAFI. And yes, YAAFI is used
in production environment at least in our company. I think Eric Pugh
tinkered with Scarab - anyone else out there?!
And after proper integration with Turbine there will be more production
environments.
4) The Future of Jakarta Avalon Containers
I see YAAFI as an approiate choice for command-line applications, small
server applications and embedded Avalon container for Turbine and if you
need more bells and whistle you still have other choices - you name them.
And I would appreciate some sort of cross-project cooperation to achieve
the following long-term goals
+) ensure that the available Avalon services (Excalibur, Fulcrum, Xingu)
run with Fortress and YAAFI
+) promote Fulcrum as an Avalon Service project out of obscurity
+) convince the Excalibur community that YAAFI is not an odd project of
a lone hacker (which it is) to be ignored but as starting point to
migrate over to Fortress
5) The Usual Disclaimer
This is strictly my personal opinion since I have no idea what the rest
of the community is thinking ( "They smoked and did inhale", "Avalon is
dead", "Lets get rid of IOC Type 1 containers", "That was good book",
...) and I'm only a small committer. Maybe the Turbine/Fulcrum PMCs can
shed some light on plans for the future .... hint, hint.
Cheers,
Siegfried Goeschl
J Aaron Farr wrote:
>On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl
><si...@it20one.at> wrote:
>
>
>
>>The usage szenario would be : you find a few funky Fulcrum services but
>>they depend on a Merlin Avalon contract regarding the Context. If I
>>understand it correctly you can't use the components directly since the
>>blow up during contextialize() trying to access "urn:avalon:home" and
>>"urn:avalon:temp".
>>
>>
>
>First off, we (Excalibur) need to fix up the context contracts. It
>should be much easier now that Avalon has disolved. If nothing else,
>we could look at having Fortress handle all previous context
>"standards".
>
>
>
>>We have the same requirement for Turbine - if the Turbine service
>>framework does not find a service it should ask all its children
>>implementing ServiceManager. In this case it is not a big deal since
>>this is the only sensible solution to provide container-transparent
>>access to components. But in Excalibur land it has a rather akward semantic.
>>
>>
>
>Sounds like it would involve a change to the default ServiceManager or
>a new ServiceManager implementation.
>
>Siegfried, what was the original motivation for YAAFI? Was it the
>existance of multiple Avalon containers? Was it the number of jar
>dependencies? Is YAAFI intended to be used in a production
>environment?
>
>I'd like to see Fortress evolve to be simple enough that there
>wouldn't be a need for Yet Another Avalon Framework Implementation.
>Maybe Turbine's needs can help drive that.
>
>
>
Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl
<si...@it20one.at> wrote:
> The usage szenario would be : you find a few funky Fulcrum services but
> they depend on a Merlin Avalon contract regarding the Context. If I
> understand it correctly you can't use the components directly since the
> blow up during contextialize() trying to access "urn:avalon:home" and
> "urn:avalon:temp".
First off, we (Excalibur) need to fix up the context contracts. It
should be much easier now that Avalon has disolved. If nothing else,
we could look at having Fortress handle all previous context
"standards".
> We have the same requirement for Turbine - if the Turbine service
> framework does not find a service it should ask all its children
> implementing ServiceManager. In this case it is not a big deal since
> this is the only sensible solution to provide container-transparent
> access to components. But in Excalibur land it has a rather akward semantic.
Sounds like it would involve a change to the default ServiceManager or
a new ServiceManager implementation.
Siegfried, what was the original motivation for YAAFI? Was it the
existance of multiple Avalon containers? Was it the number of jar
dependencies? Is YAAFI intended to be used in a production
environment?
I'd like to see Fortress evolve to be simple enough that there
wouldn't be a need for Yet Another Avalon Framework Implementation.
Maybe Turbine's needs can help drive that.
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Plans for Fulcrum release ....
Posted by J Aaron Farr <ja...@gmail.com>.
On Wed, 16 Feb 2005 09:44:18 +0100, Siegfried Goeschl
<si...@it20one.at> wrote:
> The usage szenario would be : you find a few funky Fulcrum services but
> they depend on a Merlin Avalon contract regarding the Context. If I
> understand it correctly you can't use the components directly since the
> blow up during contextialize() trying to access "urn:avalon:home" and
> "urn:avalon:temp".
First off, we (Excalibur) need to fix up the context contracts. It
should be much easier now that Avalon has disolved. If nothing else,
we could look at having Fortress handle all previous context
"standards".
> We have the same requirement for Turbine - if the Turbine service
> framework does not find a service it should ask all its children
> implementing ServiceManager. In this case it is not a big deal since
> this is the only sensible solution to provide container-transparent
> access to components. But in Excalibur land it has a rather akward semantic.
Sounds like it would involve a change to the default ServiceManager or
a new ServiceManager implementation.
Siegfried, what was the original motivation for YAAFI? Was it the
existance of multiple Avalon containers? Was it the number of jar
dependencies? Is YAAFI intended to be used in a production
environment?
I'd like to see Fortress evolve to be simple enough that there
wouldn't be a need for Yet Another Avalon Framework Implementation.
Maybe Turbine's needs can help drive that.
--
jaaron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
it's the other way around - assume that a component is instantiated as a
child but implements ServiceManager, Would Excalibur ever invoke lookup()?!
The usage szenario would be : you find a few funky Fulcrum services but
they depend on a Merlin Avalon contract regarding the Context. If I
understand it correctly you can't use the components directly since the
blow up during contextialize() trying to access "urn:avalon:home" and
"urn:avalon:temp". In this case you can instantiate YAAFI as Excalibur
component whereas YAAFI takes care of loading the Fulcrum components.
But the YAAFI instance would be a child component and the available
service would be never found during the cascading lookup going up the
parent hierarchy. Do I miss something here)
We have the same requirement for Turbine - if the Turbine service
framework does not find a service it should ask all its children
implementing ServiceManager. In this case it is not a big deal since
this is the only sensible solution to provide container-transparent
access to components. But in Excalibur land it has a rather akward semantic.
Cheers,
Siegfried Goeschl
peter royal wrote:
> On Feb 15, 2005, at 12:48 PM, Siegfried Goeschl wrote:
>
>> The only remaining issue is that I don't know if there is cascading
>> lookup() implemented in Excalibur. E.g. if a component implements a
>> ServiceManager interface you could delegate the search if you own
>> container hasn't found anything and a proper sematic ... any comments
>> from the Excalibur community?!
>
>
> Not sure what you mean.. The DefaultServiceManager implementation has
> a cascading behavior, it will search in a parent SM if a component is
> not contained within itself..
> -pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Peter,
it's the other way around - assume that a component is instantiated as a
child but implements ServiceManager, Would Excalibur ever invoke lookup()?!
The usage szenario would be : you find a few funky Fulcrum services but
they depend on a Merlin Avalon contract regarding the Context. If I
understand it correctly you can't use the components directly since the
blow up during contextialize() trying to access "urn:avalon:home" and
"urn:avalon:temp". In this case you can instantiate YAAFI as Excalibur
component whereas YAAFI takes care of loading the Fulcrum components.
But the YAAFI instance would be a child component and the available
service would be never found during the cascading lookup going up the
parent hierarchy. Do I miss something here)
We have the same requirement for Turbine - if the Turbine service
framework does not find a service it should ask all its children
implementing ServiceManager. In this case it is not a big deal since
this is the only sensible solution to provide container-transparent
access to components. But in Excalibur land it has a rather akward semantic.
Cheers,
Siegfried Goeschl
peter royal wrote:
> On Feb 15, 2005, at 12:48 PM, Siegfried Goeschl wrote:
>
>> The only remaining issue is that I don't know if there is cascading
>> lookup() implemented in Excalibur. E.g. if a component implements a
>> ServiceManager interface you could delegate the search if you own
>> container hasn't found anything and a proper sematic ... any comments
>> from the Excalibur community?!
>
>
> Not sure what you mean.. The DefaultServiceManager implementation has
> a cascading behavior, it will search in a parent SM if a component is
> not contained within itself..
> -pete
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
> For additional commands, e-mail: dev-help@excalibur.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Plans for Fulcrum release ....
Posted by peter royal <pr...@apache.org>.
On Feb 15, 2005, at 12:48 PM, Siegfried Goeschl wrote:
> The only remaining issue is that I don't know if there is cascading
> lookup() implemented in Excalibur. E.g. if a component implements a
> ServiceManager interface you could delegate the search if you own
> container hasn't found anything and a proper sematic ... any comments
> from the Excalibur community?!
Not sure what you mean.. The DefaultServiceManager implementation has a
cascading behavior, it will search in a parent SM if a component is not
contained within itself..
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
the troubles with adding Excalibur and Phoenix is the library avalanche
and the existing Fulcrum services will never ever run within a Excalibur
and Phoenix container. It sounds like a no-brainer but the Avalon folks
never agreed on what to put into the Avalon Context - the Fulcrum
services will simply blow up when they access the context to find
"urn:avalon:home" since this Merlin specific.
On the positive side I just hacked together YAAFI bootstrapping with
Avalon Context mapping - this theoretically allows YAAFI to be embedded
into a Phoenix and Fortress container and running any Fulcrum or Merlin
services. I have a JAMES installation (=Phoenix container) with embedded
YAAFI for digitial signatures to play around .....
The only remaining issue is that I don't know if there is cascading
lookup() implemented in Excalibur. E.g. if a component implements a
ServiceManager interface you could delegate the search if you own
container hasn't found anything and a proper sematic ... any comments
from the Excalibur community?!
Tommorrow I code
+) the Avalon Context Mapping for service components - this allows
running a cornerstone and excalibur components within YAAFI - at least
in theory ... :-)
+) the Fulcrum Reconfiguration Service - I think the easy way to go is
to monitor the componentConfiguration.xml and trigger a reconfiguration
when the timestamp has changed. It is not a universial solution but
solves at least my reconfiguration needs - better than nothing.
BTW - any objections to replace JCoverage with Clover reports?!
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
>Sounds great!
>
>I won't be able to help too much on the coding side, but I am definitly
>able to help on the integration side of things using Gump! I am going
>through and debugging the current set of Fulcrum errors.. :-)
>
>If the Excaliber folks can lend a hand, we may want to think of setting
>up two gump projects, one running under Excaliber, the other under
>Yaafi. Or, look at how our unit tests can be smart and run twice, once
>under each container. Maybe look at adding phoenix as well?
>
>Eric
>
>-----Original Message-----
>From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
>Sent: Monday, February 14, 2005 2:09 AM
>To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
>dev@excalibur.apache.org
>Subject: Plans for Fulcrum release ....
>
>
>Hi folks,
>
>within the next 4 weeks I want to cut a new release of Fulcrum for
>Turbine 2.4.x
>
>RECENT FULCRUM CHANGES
>===========================================================
>
>1) there is a new Avalon container called YAAFI (Yet Another Avalon
>Framework Implementation) to run the existing Fulcrum services. YAAFI is
>
>light-weight Avalon container to be embedded in other applications and
>comes with litte baggage in terms of dependencies. It is intended as
>replacement for the depecated ECM and Merlin Container.
>
>2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
>
>3) Fulcrum ResouceManager Service - a facade for accessing resources
>currently file system
>
>4) Fulcrum Groovy Service - allows execution of Groovy scripts with
>access to the Avalon infrastructure
>
>
>PENDING FULCRUM CHANGES (NOT COMMITTED YET)
>===========================================================
>
>1) YAAFI improvements
>1.1) improved bootstrapping of YAAFI
>1.2) transparent decryption of configuration files based on JCA/JCE
>1.3) support for <component-type> to specify the container type to be
>expected by the component. This allows for reuse of existing services
>written for Excalibur, Phoenix or Fortress
>1.4) support for <container-type> to allow YAAFI to be embedded in a
>Fortress or Phoenix container, e.g. JAMES
>
>2) Fulcrum PBE Service provides a service for Password Based Encryption
>based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
>
>3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
>ResouceManager Service. This improved service will not be backward
>compatible
>
>4) I'm tinkering with automatic reconfiguration of YAAFI using a
>dedicated Fulcrum Reconfiguration Service. This service would monitor
>the componentConfiguration.xml and reconfigure YAAFI if the file has
>changed. This allows automatic reconfiguration without any client/server
>
>communication
>
>5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
>
>application
>
>6) Fulcrum ResourceManager Service provides transparent
>encryption/decryption of resources.
>
>
>REQUEST FOR HELP
>===========================================================
>
>1) Help from the Excalibur community would be greatly appreciated to
>kickstart component compatibilty testing
>
>2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
>
>
>
>Thanks in advance
>
>Siegfried Goeschl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
the troubles with adding Excalibur and Phoenix is the library avalanche
and the existing Fulcrum services will never ever run within a Excalibur
and Phoenix container. It sounds like a no-brainer but the Avalon folks
never agreed on what to put into the Avalon Context - the Fulcrum
services will simply blow up when they access the context to find
"urn:avalon:home" since this Merlin specific.
On the positive side I just hacked together YAAFI bootstrapping with
Avalon Context mapping - this theoretically allows YAAFI to be embedded
into a Phoenix and Fortress container and running any Fulcrum or Merlin
services. I have a JAMES installation (=Phoenix container) with embedded
YAAFI for digitial signatures to play around .....
The only remaining issue is that I don't know if there is cascading
lookup() implemented in Excalibur. E.g. if a component implements a
ServiceManager interface you could delegate the search if you own
container hasn't found anything and a proper sematic ... any comments
from the Excalibur community?!
Tommorrow I code
+) the Avalon Context Mapping for service components - this allows
running a cornerstone and excalibur components within YAAFI - at least
in theory ... :-)
+) the Fulcrum Reconfiguration Service - I think the easy way to go is
to monitor the componentConfiguration.xml and trigger a reconfiguration
when the timestamp has changed. It is not a universial solution but
solves at least my reconfiguration needs - better than nothing.
BTW - any objections to replace JCoverage with Clover reports?!
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
>Sounds great!
>
>I won't be able to help too much on the coding side, but I am definitly
>able to help on the integration side of things using Gump! I am going
>through and debugging the current set of Fulcrum errors.. :-)
>
>If the Excaliber folks can lend a hand, we may want to think of setting
>up two gump projects, one running under Excaliber, the other under
>Yaafi. Or, look at how our unit tests can be smart and run twice, once
>under each container. Maybe look at adding phoenix as well?
>
>Eric
>
>-----Original Message-----
>From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
>Sent: Monday, February 14, 2005 2:09 AM
>To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
>dev@excalibur.apache.org
>Subject: Plans for Fulcrum release ....
>
>
>Hi folks,
>
>within the next 4 weeks I want to cut a new release of Fulcrum for
>Turbine 2.4.x
>
>RECENT FULCRUM CHANGES
>===========================================================
>
>1) there is a new Avalon container called YAAFI (Yet Another Avalon
>Framework Implementation) to run the existing Fulcrum services. YAAFI is
>
>light-weight Avalon container to be embedded in other applications and
>comes with litte baggage in terms of dependencies. It is intended as
>replacement for the depecated ECM and Merlin Container.
>
>2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
>
>3) Fulcrum ResouceManager Service - a facade for accessing resources
>currently file system
>
>4) Fulcrum Groovy Service - allows execution of Groovy scripts with
>access to the Avalon infrastructure
>
>
>PENDING FULCRUM CHANGES (NOT COMMITTED YET)
>===========================================================
>
>1) YAAFI improvements
>1.1) improved bootstrapping of YAAFI
>1.2) transparent decryption of configuration files based on JCA/JCE
>1.3) support for <component-type> to specify the container type to be
>expected by the component. This allows for reuse of existing services
>written for Excalibur, Phoenix or Fortress
>1.4) support for <container-type> to allow YAAFI to be embedded in a
>Fortress or Phoenix container, e.g. JAMES
>
>2) Fulcrum PBE Service provides a service for Password Based Encryption
>based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
>
>3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
>ResouceManager Service. This improved service will not be backward
>compatible
>
>4) I'm tinkering with automatic reconfiguration of YAAFI using a
>dedicated Fulcrum Reconfiguration Service. This service would monitor
>the componentConfiguration.xml and reconfigure YAAFI if the file has
>changed. This allows automatic reconfiguration without any client/server
>
>communication
>
>5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
>
>application
>
>6) Fulcrum ResourceManager Service provides transparent
>encryption/decryption of resources.
>
>
>REQUEST FOR HELP
>===========================================================
>
>1) Help from the Excalibur community would be greatly appreciated to
>kickstart component compatibilty testing
>
>2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
>
>
>
>Thanks in advance
>
>Siegfried Goeschl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Plans for Fulcrum release ....
Posted by Siegfried Goeschl <si...@it20one.at>.
Hi Eric,
the troubles with adding Excalibur and Phoenix is the library avalanche
and the existing Fulcrum services will never ever run within a Excalibur
and Phoenix container. It sounds like a no-brainer but the Avalon folks
never agreed on what to put into the Avalon Context - the Fulcrum
services will simply blow up when they access the context to find
"urn:avalon:home" since this Merlin specific.
On the positive side I just hacked together YAAFI bootstrapping with
Avalon Context mapping - this theoretically allows YAAFI to be embedded
into a Phoenix and Fortress container and running any Fulcrum or Merlin
services. I have a JAMES installation (=Phoenix container) with embedded
YAAFI for digitial signatures to play around .....
The only remaining issue is that I don't know if there is cascading
lookup() implemented in Excalibur. E.g. if a component implements a
ServiceManager interface you could delegate the search if you own
container hasn't found anything and a proper sematic ... any comments
from the Excalibur community?!
Tommorrow I code
+) the Avalon Context Mapping for service components - this allows
running a cornerstone and excalibur components within YAAFI - at least
in theory ... :-)
+) the Fulcrum Reconfiguration Service - I think the easy way to go is
to monitor the componentConfiguration.xml and trigger a reconfiguration
when the timestamp has changed. It is not a universial solution but
solves at least my reconfiguration needs - better than nothing.
BTW - any objections to replace JCoverage with Clover reports?!
Cheers,
Siegfried Goeschl
Eric Pugh wrote:
>Sounds great!
>
>I won't be able to help too much on the coding side, but I am definitly
>able to help on the integration side of things using Gump! I am going
>through and debugging the current set of Fulcrum errors.. :-)
>
>If the Excaliber folks can lend a hand, we may want to think of setting
>up two gump projects, one running under Excaliber, the other under
>Yaafi. Or, look at how our unit tests can be smart and run twice, once
>under each container. Maybe look at adding phoenix as well?
>
>Eric
>
>-----Original Message-----
>From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
>Sent: Monday, February 14, 2005 2:09 AM
>To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
>dev@excalibur.apache.org
>Subject: Plans for Fulcrum release ....
>
>
>Hi folks,
>
>within the next 4 weeks I want to cut a new release of Fulcrum for
>Turbine 2.4.x
>
>RECENT FULCRUM CHANGES
>===========================================================
>
>1) there is a new Avalon container called YAAFI (Yet Another Avalon
>Framework Implementation) to run the existing Fulcrum services. YAAFI is
>
>light-weight Avalon container to be embedded in other applications and
>comes with litte baggage in terms of dependencies. It is intended as
>replacement for the depecated ECM and Merlin Container.
>
>2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
>
>3) Fulcrum ResouceManager Service - a facade for accessing resources
>currently file system
>
>4) Fulcrum Groovy Service - allows execution of Groovy scripts with
>access to the Avalon infrastructure
>
>
>PENDING FULCRUM CHANGES (NOT COMMITTED YET)
>===========================================================
>
>1) YAAFI improvements
>1.1) improved bootstrapping of YAAFI
>1.2) transparent decryption of configuration files based on JCA/JCE
>1.3) support for <component-type> to specify the container type to be
>expected by the component. This allows for reuse of existing services
>written for Excalibur, Phoenix or Fortress
>1.4) support for <container-type> to allow YAAFI to be embedded in a
>Fortress or Phoenix container, e.g. JAMES
>
>2) Fulcrum PBE Service provides a service for Password Based Encryption
>based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
>
>3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
>ResouceManager Service. This improved service will not be backward
>compatible
>
>4) I'm tinkering with automatic reconfiguration of YAAFI using a
>dedicated Fulcrum Reconfiguration Service. This service would monitor
>the componentConfiguration.xml and reconfigure YAAFI if the file has
>changed. This allows automatic reconfiguration without any client/server
>
>communication
>
>5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
>
>application
>
>6) Fulcrum ResourceManager Service provides transparent
>encryption/decryption of resources.
>
>
>REQUEST FOR HELP
>===========================================================
>
>1) Help from the Excalibur community would be greatly appreciated to
>kickstart component compatibilty testing
>
>2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
>
>
>
>Thanks in advance
>
>Siegfried Goeschl
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-user-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@upstate.com>.
Sounds great!
I won't be able to help too much on the coding side, but I am definitly
able to help on the integration side of things using Gump! I am going
through and debugging the current set of Fulcrum errors.. :-)
If the Excaliber folks can lend a hand, we may want to think of setting
up two gump projects, one running under Excaliber, the other under
Yaafi. Or, look at how our unit tests can be smart and run twice, once
under each container. Maybe look at adding phoenix as well?
Eric
-----Original Message-----
From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
Sent: Monday, February 14, 2005 2:09 AM
To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
dev@excalibur.apache.org
Subject: Plans for Fulcrum release ....
Hi folks,
within the next 4 weeks I want to cut a new release of Fulcrum for
Turbine 2.4.x
RECENT FULCRUM CHANGES
===========================================================
1) there is a new Avalon container called YAAFI (Yet Another Avalon
Framework Implementation) to run the existing Fulcrum services. YAAFI is
light-weight Avalon container to be embedded in other applications and
comes with litte baggage in terms of dependencies. It is intended as
replacement for the depecated ECM and Merlin Container.
2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
3) Fulcrum ResouceManager Service - a facade for accessing resources
currently file system
4) Fulcrum Groovy Service - allows execution of Groovy scripts with
access to the Avalon infrastructure
PENDING FULCRUM CHANGES (NOT COMMITTED YET)
===========================================================
1) YAAFI improvements
1.1) improved bootstrapping of YAAFI
1.2) transparent decryption of configuration files based on JCA/JCE
1.3) support for <component-type> to specify the container type to be
expected by the component. This allows for reuse of existing services
written for Excalibur, Phoenix or Fortress
1.4) support for <container-type> to allow YAAFI to be embedded in a
Fortress or Phoenix container, e.g. JAMES
2) Fulcrum PBE Service provides a service for Password Based Encryption
based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
ResouceManager Service. This improved service will not be backward
compatible
4) I'm tinkering with automatic reconfiguration of YAAFI using a
dedicated Fulcrum Reconfiguration Service. This service would monitor
the componentConfiguration.xml and reconfigure YAAFI if the file has
changed. This allows automatic reconfiguration without any client/server
communication
5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
application
6) Fulcrum ResourceManager Service provides transparent
encryption/decryption of resources.
REQUEST FOR HELP
===========================================================
1) Help from the Excalibur community would be greatly appreciated to
kickstart component compatibilty testing
2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
Thanks in advance
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
RE: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@upstate.com>.
Sounds great!
I won't be able to help too much on the coding side, but I am definitly
able to help on the integration side of things using Gump! I am going
through and debugging the current set of Fulcrum errors.. :-)
If the Excaliber folks can lend a hand, we may want to think of setting
up two gump projects, one running under Excaliber, the other under
Yaafi. Or, look at how our unit tests can be smart and run twice, once
under each container. Maybe look at adding phoenix as well?
Eric
-----Original Message-----
From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
Sent: Monday, February 14, 2005 2:09 AM
To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
dev@excalibur.apache.org
Subject: Plans for Fulcrum release ....
Hi folks,
within the next 4 weeks I want to cut a new release of Fulcrum for
Turbine 2.4.x
RECENT FULCRUM CHANGES
===========================================================
1) there is a new Avalon container called YAAFI (Yet Another Avalon
Framework Implementation) to run the existing Fulcrum services. YAAFI is
light-weight Avalon container to be embedded in other applications and
comes with litte baggage in terms of dependencies. It is intended as
replacement for the depecated ECM and Merlin Container.
2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
3) Fulcrum ResouceManager Service - a facade for accessing resources
currently file system
4) Fulcrum Groovy Service - allows execution of Groovy scripts with
access to the Avalon infrastructure
PENDING FULCRUM CHANGES (NOT COMMITTED YET)
===========================================================
1) YAAFI improvements
1.1) improved bootstrapping of YAAFI
1.2) transparent decryption of configuration files based on JCA/JCE
1.3) support for <component-type> to specify the container type to be
expected by the component. This allows for reuse of existing services
written for Excalibur, Phoenix or Fortress
1.4) support for <container-type> to allow YAAFI to be embedded in a
Fortress or Phoenix container, e.g. JAMES
2) Fulcrum PBE Service provides a service for Password Based Encryption
based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
ResouceManager Service. This improved service will not be backward
compatible
4) I'm tinkering with automatic reconfiguration of YAAFI using a
dedicated Fulcrum Reconfiguration Service. This service would monitor
the componentConfiguration.xml and reconfigure YAAFI if the file has
changed. This allows automatic reconfiguration without any client/server
communication
5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
application
6) Fulcrum ResourceManager Service provides transparent
encryption/decryption of resources.
REQUEST FOR HELP
===========================================================
1) Help from the Excalibur community would be greatly appreciated to
kickstart component compatibilty testing
2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
Thanks in advance
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
RE: Plans for Fulcrum release ....
Posted by Eric Pugh <ep...@upstate.com>.
Sounds great!
I won't be able to help too much on the coding side, but I am definitly
able to help on the integration side of things using Gump! I am going
through and debugging the current set of Fulcrum errors.. :-)
If the Excaliber folks can lend a hand, we may want to think of setting
up two gump projects, one running under Excaliber, the other under
Yaafi. Or, look at how our unit tests can be smart and run twice, once
under each container. Maybe look at adding phoenix as well?
Eric
-----Original Message-----
From: Siegfried Goeschl [mailto:siegfried.goeschl@it20one.at]
Sent: Monday, February 14, 2005 2:09 AM
To: turbine-user@jakarta.apache.org; turbine-dev@jakarta.apache.org;
dev@excalibur.apache.org
Subject: Plans for Fulcrum release ....
Hi folks,
within the next 4 weeks I want to cut a new release of Fulcrum for
Turbine 2.4.x
RECENT FULCRUM CHANGES
===========================================================
1) there is a new Avalon container called YAAFI (Yet Another Avalon
Framework Implementation) to run the existing Fulcrum services. YAAFI is
light-weight Avalon container to be embedded in other applications and
comes with litte baggage in terms of dependencies. It is intended as
replacement for the depecated ECM and Merlin Container.
2) Fulcrum HsqlDB Service to embed a HQSLDB server in your application
3) Fulcrum ResouceManager Service - a facade for accessing resources
currently file system
4) Fulcrum Groovy Service - allows execution of Groovy scripts with
access to the Avalon infrastructure
PENDING FULCRUM CHANGES (NOT COMMITTED YET)
===========================================================
1) YAAFI improvements
1.1) improved bootstrapping of YAAFI
1.2) transparent decryption of configuration files based on JCA/JCE
1.3) support for <component-type> to specify the container type to be
expected by the component. This allows for reuse of existing services
written for Excalibur, Phoenix or Fortress
1.4) support for <container-type> to allow YAAFI to be embedded in a
Fortress or Phoenix container, e.g. JAMES
2) Fulcrum PBE Service provides a service for Password Based Encryption
based on PBEWithMD5AndDES/PBEWithMD5AndTripleDES.
3) Fulcrum XSLT Service - intgration with DOM4J and Fulcrum
ResouceManager Service. This improved service will not be backward
compatible
4) I'm tinkering with automatic reconfiguration of YAAFI using a
dedicated Fulcrum Reconfiguration Service. This service would monitor
the componentConfiguration.xml and reconfigure YAAFI if the file has
changed. This allows automatic reconfiguration without any client/server
communication
5) a Turbine YAFFI Component Service to bootstrap YAAFI within a Turbine
application
6) Fulcrum ResourceManager Service provides transparent
encryption/decryption of resources.
REQUEST FOR HELP
===========================================================
1) Help from the Excalibur community would be greatly appreciated to
kickstart component compatibilty testing
2) Any who would like to work on bleeding-edge Fulcrum/Turbine?!
Thanks in advance
Siegfried Goeschl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org