You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/07/23 15:39:16 UTC
[RT] Distant Future...
With the new JDK 1.4.2 available, and Sun generating hype about JDK 1.5
already, I have a proposed plan for the future.
I think we should carry Avalon 4 for Java 1.2 - Java 1.4.x. The reason
for this is that JDK 1.5 has some serious features that will make our
jobs a heck of a lot easier to develop the containers. Our Avalon 5
container should take advantage of those features. As a result, it will
be easier to identify a set of tools and utilities and common meta info
if we can guarantee a full featured JDK.
That means we will plan to support two different Avalons for a while.
The Avalon 4 will be for all the users that are slow to upgrade, but
need a robust management solution. Avalon 5 will be the "best of breed"
approach, and will learn from our Avalon 4 experience. It should be
considered an improvement project. I.e. how do we correct our mistakes
without worrying about backwards compatibility, and how do we improve
on our current model?
The support for Avalon 4 will not die out for a number of reasons. We
should still push forward with a common Avalon container--slowly making
changes and moving functionality out to container extensions (when we
cross that bridge) to the point where the core is really not important.
In that case we just decide which core is easiest to maintain and/or
provides the best interface for users.
By the time Avalon 5 does come around we will have so much understanding
on the subject of components you could call us domain experts ;P. It also
means that we have a while before we can even think of starting Avalon 5.
By defining Avalon 5 as Java 1.5 compliant or above we draw a line in the
sand where both component writers and container writers can confidently
incorporate language features to the best of our abilities.
Does this plan sound good?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distant Future...
Posted by Robert McIntosh <ro...@bull-enterprises.com>.
Speaking as a user and not a developer of Avalon, I too looked at Pico a
day or so ago when the subject of Fractal came up. About the only thing
I didn't like is the configuration as I really like the configuration
ability of the framework. One thing I did do when I moved to Fortress
was borrow what the Keel folks did and allow separate config files for
each component and when the container starts up build one big file.
I also had to do some hacking of my own that would probably make you
guys puke with disgust :-). Basically I have dependencies between a
couple of components and if one of these components does not configure
or startup correctly, I needed that component to tell the container to
not service anything, and on top of that I needed the container to
provide the 'user' with a message as to why it cannot service anything.
For example, if the JDBC pool component cannot establish a connection,
then my persistence component certainly won't work. So instead of
throwing null pointer or 'cannot locate component' or some such message
that requires a lot of digging in a log file, the container just says
'could not get a connection to DB', or something like that. I understand
that Merlin and Phoenix have dependency capabilities, but I just didn't
like the deployment aspect of them. Too 'ejb' like, i.e. separate jars,
sars, blocks or whatever.
Someone mentioned the roles file as well. My only real beef with that is
that I never found any real good docs on how to use it. An example here
or there, none of which worked for me because they were out of date or
whatever. But, once I got it working, i've never had to mess with it again.
Anyway, my .02.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distant Future...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Sutic wrote, On 23/07/2003 16.09:
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>how do we improve on our current model?
...
> I want simplification, and I think PicoContainer does that.
I want simplification too, but IMHO PicoContainer, although interesting,
still doesn's cut it.
...
> + How do we provide components?
> PicoContainer passes them in the constructor. A4 requires a
> lookup()/release(). I'd like to just mark a public field with
> the dependency info and have that field set by reflection to
> a reference. Like this:
>
> class MyComponent {
> /**
> * @avalon.dependency version="1.0"
> */
> public QueueManager queueManager = null;
>
> ...
> }
>
> This would have the queueManager field set by the container to
> a QueueManager with version 1.0. Yes, this means exposing public
> fields, but seriously, how many check that compose() isn't called
> more than once? It is the responsibility of the container to
> proxy components and protect them.
Hey, I had the same idea! Cool!
Probably we could also be able to set private fields (IIUC BCEL can do
it), and that would be the best.
But this is only part of the equation, that of servicing a component. It
seems that the lifecycle is not taken into account.
That is what extensions can be for: imagine that we don't have mandatory
(although we can still keep suggested ones) interfaces for the
lifecycle. And that we can plug in extensions that can run in particular
stages. We don't need coupling anymore, as these extensions can run on
complete reflection and external definitions.
For example, I can instruct my container to add a lifecycle extension
that is called in the components that have an init method. The extension
would simply call that method.
Or I can instruct my container to add a lifecycle extension that is
called in the components that have a service(ServiceManager) method. The
extension would that method and give the ServiceManager.
As you see, we can run *any* component in the container, even ones that
were not made for Avalon and that have particular lifecycle stages to be
done.
Why are you so against extensions?
>>Does this plan sound good?
>
> If it means that all the meta info generators can finally be
> dumped on the world's biggest scrap heap then I'm all for it.
+1 Definately.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distant Future...
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>how do we improve on our current model?
>
>
> I have been meaning to write an [RT] about this, but the
> approach taken in PicoContainer, is, I believe, the future.
>
> 1. To clarify that a bit - lifecycle extensions and all are good,
> but ***my God do they add complexity***. Anything that requires
> documentation to use phrases like "establishing a deployment
> context" is in dire need of simplification.
They can be simplified. Don't worry, we can add features without
adding too much complexity.
>
> I still use the ECM, because, frankly, I don't "get" the other
> containers. I understand them but it's just too much to
> comfortably keep inside my head.
That's because you haven't used them enough to appreciate what the
features do for you. Once you start taking advantage of it, you get
hooked.
>
> I want simplification, and I think PicoContainer does that.
I want simplification too, however, I need a pointer to PicoContainer
because I am not aware of it being in Avalon's CVS. We can find the balance
when it is time though. For now, let us just say that much of the need for our
fancy libraries will most likely be removed by the official language features of
Java 1.5. Not to mention our need for other external libraries will be reduced
as well.
>
> 2. I think there are some lingering issues with A4 that we should
> revisit, for example:
>
> + Poolable components
> This is the whole reason for the lookup()/release() in ECM and
> Fortress. I think we can come up with some other idiom, maybe
>
> component.beginTransaction ();
> try {
> ... do stuff ...
> } finally {
> component.endTransaction ().
> }
>
> That will allow us to actually do all the lookup() in the
> equivalent
> of compose()/service(), instead of limiting that method to a
> single
> this.myServiceManager = manager; line.
I agree that we should look at them. However, I think we are kind of
stuck with our interface for the time being. I would prefer something
that didn't require a try/finally approach because we are imposing too
much on the developer. Remember simplicity--and the question becomes
for who are things simplified?
> + How do we provide components?
> PicoContainer passes them in the constructor. A4 requires a
> lookup()/release(). I'd like to just mark a public field with
> the dependency info and have that field set by reflection to
> a reference. Like this:
>
> class MyComponent {
> /**
> * @avalon.dependency version="1.0"
> */
> public QueueManager queueManager = null;
>
> ...
> }
>
> This would have the queueManager field set by the container to
> a QueueManager with version 1.0. Yes, this means exposing public
> fields, but seriously, how many check that compose() isn't called
> more than once? It is the responsibility of the container to
> proxy components and protect them.
There are other ways of doing the same thing. My version of simplicity
will allow the container to adapt so that there are very little real
requirements on the component writer. I.e. the container would be able
to work with Avalon components, Pico style components, etc. etc.
>>Does this plan sound good?
>
>
> If it means that all the meta info generators can finally be
> dumped on the world's biggest scrap heap then I'm all for it.
>
Language features take care of this function. Unless you *use* the
meta info, the simplicity that it offers the component writer is
lost on you. It truly is vastly more convenient to manage your component
directly in the source code than it is to have to edit a roles file and
a config file.
Again, simplicity should be one of the major themes of Avalon 5--but we
aren't anywhere near there yet. For the time being, let us focus on Avalon 4
and make it better.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Distant Future...
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> how do we improve on our current model?
I have been meaning to write an [RT] about this, but the
approach taken in PicoContainer, is, I believe, the future.
1. To clarify that a bit - lifecycle extensions and all are good,
but ***my God do they add complexity***. Anything that requires
documentation to use phrases like "establishing a deployment
context" is in dire need of simplification.
I still use the ECM, because, frankly, I don't "get" the other
containers. I understand them but it's just too much to
comfortably keep inside my head.
I want simplification, and I think PicoContainer does that.
2. I think there are some lingering issues with A4 that we should
revisit, for example:
+ Poolable components
This is the whole reason for the lookup()/release() in ECM and
Fortress. I think we can come up with some other idiom, maybe
component.beginTransaction ();
try {
... do stuff ...
} finally {
component.endTransaction ().
}
That will allow us to actually do all the lookup() in the
equivalent
of compose()/service(), instead of limiting that method to a
single
this.myServiceManager = manager; line.
+ How do we provide components?
PicoContainer passes them in the constructor. A4 requires a
lookup()/release(). I'd like to just mark a public field with
the dependency info and have that field set by reflection to
a reference. Like this:
class MyComponent {
/**
* @avalon.dependency version="1.0"
*/
public QueueManager queueManager = null;
...
}
This would have the queueManager field set by the container to
a QueueManager with version 1.0. Yes, this means exposing public
fields, but seriously, how many check that compose() isn't called
more than once? It is the responsibility of the container to
proxy components and protect them.
> Does this plan sound good?
If it means that all the meta info generators can finally be
dumped on the world's biggest scrap heap then I'm all for it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org