You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2002/09/29 21:54:07 UTC
RE: [heads-up] The version of ECM in CVS has a change in JDK
reqs
Leo Simons wrote:
> On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
> > + Avalon 4 contains the ComponentManager interface and thus
> > *all* component that claim to be Avalon 4 compatible MUST
> > support the Component interface.
>
> -1 on defining "avalon compatible component" this way. The whole point
> of service.* is that you can have "avalon compatible components" that do
> not implement Component!
Basic problem I have with your reasoning:
+ It is not OK for a container to not support Composable (i.e. explode when
a composable component is loaded) and call itself 100% A4 compliant. This
is because we may be in a situation when we have a legacy component, and
we want that to work.
But this is only 1/2 of the contract: What are the rules for legacy
*containers*?
In theory, if a container is 100% A4 compliant, it should remain so for all
future
versions of A4, in the same way that a component, once having achieved 100%
A4 status,
will remain so until A5.
The Seviceable interface messes all that up.
It is possible for a container to be Avalon 4.0 compliant, but not Avalon 4.1
compliant.
I consider this a problem.
What to do:
+ All Excalibur components that were released prior to the introduction
of the
Serviceable interface have to implement the Component interface until A5.
+ Any new releases must clearly state that they are targeted at A4.1 unless
they implement Component, or if they use the service package.
+ ECM remains JDK1.2 compatible. Look, the damn thing is legacy legacy
legacy.
It works fine, but I'd rather have it remain A4.0 instead of trying to
mutate
it to A4.1, unless that mutation can be done without JDK1.3. Branching is
another possiblity. Under JDK1.2, the lookup of a non-Component
implementing
component would throw a ComponentException, under 1.3 it would be solved
via the proxy generator.
I think this solves Cocoon's problems.
I also think we can be a bit more bold with A4.2, seeing as the damage is
already
done. Maybe we should take this chance to clean up, or even rename 4.2 to 5?
As for what the Serviceable interface is: I always considered it nothing
more than a
method for Avalon component to access non-Avalon components via a unified
lookup mechanism.
Random thought: With the Proxy generator Berin put in the ECM, doesn't the
whole
need for Serviceable disappear?
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Simons <le...@apache.org>.
On Sun, 2002-09-29 at 21:54, Leo Sutic wrote:
> Leo Simons wrote:
> > On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
> > > + Avalon 4 contains the ComponentManager interface and thus
> > > *all* component that claim to be Avalon 4 compatible MUST
> > > support the Component interface.
> >
> > -1 on defining "avalon compatible component" this way. The whole point
> > of service.* is that you can have "avalon compatible components" that do
> > not implement Component!
>
> Basic problem I have with your reasoning:
>
> + It is not OK for a container to not support Composable (i.e. explode when
> a composable component is loaded) and call itself 100% A4 compliant. This
> is because we may be in a situation when we have a legacy component, and
> we want that to work.
+1
> But this is only 1/2 of the contract: What are the rules for legacy
> *containers*?
>
> In theory, if a container is 100% A4 compliant, it should remain so for all
> future
> versions of A4, in the same way that a component, once having achieved 100%
> A4 status,
> will remain so until A5.
+1
> The Seviceable interface messes all that up.
>
> It is possible for a container to be Avalon 4.0 compliant, but not Avalon 4.1
> compliant.
I disagree....I think you mess up a little of the container/component in
the above?
All 'compatible' *containers* must support components that implement the
Composable interface. All containers from avalon framework 4.1 and
onwards must support components that implement one or more of the
Composable and Servicable interfaces.
Not all avalon framework 4.1 and upwards compatible *components* have to
implement the Component interface.
I think we mean the same thing?
> What to do:
>
> + All Excalibur components that were released prior to the introduction
> of the
> Serviceable interface have to implement the Component interface until A5.
+1
> + Any new releases must clearly state that they are targeted at A4.1 unless
> they implement Component, or if they use the service package.
+1, though I still think they should mention they are targeted for 4.1
and higher even if they use the service package =)
> + ECM remains JDK1.2 compatible. Look, the damn thing is legacy legacy
> legacy.
> It works fine, but I'd rather have it remain A4.0 instead of trying to
> mutate
> it to A4.1, unless that mutation can be done without JDK1.3. Branching is
> another possiblity. Under JDK1.2, the lookup of a non-Component
> implementing
> component would throw a ComponentException, under 1.3 it would be solved
> via the proxy generator.
>
> I think this solves Cocoon's problems.
I hate branching....but....I'm okay with all alternatives wrt ECM for
which broad consensus can be reached.
> I also think we can be a bit more bold with A4.2, seeing as the damage is
> already
> done. Maybe we should take this chance to clean up, or even rename 4.2 to 5?
I don't think that's a very good idea. There's no need to scare
users....
> As for what the Serviceable interface is: I always considered it nothing
> more than a
> method for Avalon component to access non-Avalon components via a unified
> lookup mechanism.
hmm. The definition of 'avalon component' broadens because of service.
You can also do all the cool dependency resolution, meta information,
etc etc, for components not 'native' to avalon (ie CORBA components
running direcly inside merlin).
> Random thought: With the Proxy generator Berin put in the ECM, doesn't the
> whole
> need for Serviceable disappear?
the thought crossed my mind too....
cheers,
- other Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> <snip/>
>
> >>Really. You think Avalon Framework has changed *that* much?
> >>If I am not mistaken, EJB specs have changed a bit
> >>too--probably more so than Avalon 4.x.
> >
> >
> > The difference is that Avalon is the only framework where a user is
> > expected to write a container.
>
> That is rapidly changing. Between ECM, Fortress, Merlin, and
> Phoenix, they user will be able to just choose the container
> they want, and be done with it. With the extensions
> experiment and the work that Peter is doing on something more
> powerful, there will be very little need to even extend a container.
True, but I'm willing to bet that some people have indeed
written their own containers.
> The thing is we cannot police all our users to see what they
> are using. I posted this message to Cocoon-dev (at least I
> think I did) to warn them so that they can make an informed
> decision and increase their JDK pre-reqs for C2.2 or whatever
> version that they are going to release the new ECM with.
Look, the only reason the proxy generator is needed in the Cocoon
is for the Monitor package. Put the Component interface back in
and the problem is solved. The Cocoon people can then remain
JDK 1.2 compliant, or move to JDK 1.3, but that decision is then
independent of Avalon version.
I don't consider this "policing", I consider it taking care of
our user base and doing our best to help them even if they have put
themselves in a tight spot due to their own faults.
> > I don't want us to switch VM version, and only then realize that
> > "Oops, didn't anyone change the sys reqs. to be JVM 1.3+ ?"
> >
> > It would not look good.
>
> Which is why we give advanced notice.
Yes, but in this case we can do one better and remove the need for
notification.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
<snip/>
>>Really. You think Avalon Framework has changed *that* much?
>>If I am not mistaken, EJB specs have changed a bit
>>too--probably more so than Avalon 4.x.
>
>
> The difference is that Avalon is the only framework where a user
> is expected to write a container.
That is rapidly changing. Between ECM, Fortress, Merlin, and
Phoenix, they user will be able to just choose the container they
want, and be done with it. With the extensions experiment and
the work that Peter is doing on something more powerful, there
will be very little need to even extend a container.
However, with Fortress, it should be easy to do.
> EJB specs may change, but the only one that needs to play catch-up
> is the EJB container developer, not the bean developer.
And the tool developer. The change from compiled bean descriptors
and XML descriptors required some retooling. Of course, the cost
of upgrading your EJB container is generally a lot more than
upgrading an Avalon container.
>>>As long as Cocoon promises to run on JDK1.2, we have to support it.
>>
>>Oh, I see. However, you're the only one from Cocoon
>>complaining. In fact, quite a few of the Cocooner's are in
>>favor of upgrading their minimum JDK standard--and they need
>>a good reason to do it. We solved their problem for them.
>
>
> I don't mind going to 1.3. But Cocoon has promised to be 1.2
> compliant. Remove that promise and we're fine. But until that
> is done, I think we at Avalon-land has some responsibilities
> to not switch JDK versions.
The thing is we cannot police all our users to see what they
are using. I posted this message to Cocoon-dev (at least I
think I did) to warn them so that they can make an informed
decision and increase their JDK pre-reqs for C2.2 or whatever
version that they are going to release the new ECM with.
> I'm complaining pre-emptively.
The whole component (aka ECM) package needs real docs--with the
JDK requirements listed.
> I don't want us to switch VM version, and only then realize that
> "Oops, didn't anyone change the sys reqs. to be JVM 1.3+ ?"
>
> It would not look good.
Which is why we give advanced notice.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> >
> >>From: Berin Loritsch [mailto:bloritsch@apache.org]
> >>
> >>Leo Sutic wrote:
> >>
> >>>In theory, if a container is 100% A4 compliant, it should
> >>
> >>remain so for
> >>
> >>>all future
> >>>versions of A4, in the same way that a component, once
> >>
> >>having achieved
> >>
> >>>100% A4 status,
> >>>will remain so until A5.
> >>
> >>
> >>ECM has been made A4.1 compliant. A4.1 is *released*.
> >
> >
> > I'm fully aware of that. But my point is that instead of
> having just
> > Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon 4.2,
> > and the frameworks will be sufficiently different that a container
> > written
> > for Avalon 4.0 will not be completely Avalon 4.1 compliant.
> >
> > That's fine, if you can committ resources to playing
> catch-up with an
> > evolving standard, but the whole point of a framework is that you
> > should not *have* to play catch-up.
>
> If the container is upgraded to be 4.1 compliant, you can
> still use your legacy code. Is that a problem? That way the
> user does not have to play catch-up. They can do it a little
> bit at a time.
>
> > Now I'm all for evolving specifications, but it is a fact that the
> > framework that claims to be most fundamental for everything
> (i.e. you
> > would use Avalon to build an EJB server), is also the
> framework that
> > has changed
> > the most, and that has consumed most of my catch-up resources.
>
> Really. You think Avalon Framework has changed *that* much?
> If I am not mistaken, EJB specs have changed a bit
> too--probably more so than Avalon 4.x.
The difference is that Avalon is the only framework where a user
is expected to write a container.
EJB specs may change, but the only one that needs to play catch-up
is the EJB container developer, not the bean developer.
> > That is my problem and not yours - but to dismiss the
> problem with a
> > "A4.1 is *released*" is just not right. It assumes that
> once the gods
> > at avalon-dev releases a new version, the rest of the world
> had better
> > keep up or they will, can and should be left behind.
>
> No my point is that because Avalon 4.1 is released we need to
> support it.
OK, misunderstood you.
> > As long as Cocoon promises to run on JDK1.2, we have to support it.
>
> Oh, I see. However, you're the only one from Cocoon
> complaining. In fact, quite a few of the Cocooner's are in
> favor of upgrading their minimum JDK standard--and they need
> a good reason to do it. We solved their problem for them.
I don't mind going to 1.3. But Cocoon has promised to be 1.2
compliant. Remove that promise and we're fine. But until that
is done, I think we at Avalon-land has some responsibilities
to not switch JDK versions.
I'm complaining pre-emptively.
I don't want us to switch VM version, and only then realize that
"Oops, didn't anyone change the sys reqs. to be JVM 1.3+ ?"
It would not look good.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Leo Sutic wrote:
>>
>>>In theory, if a container is 100% A4 compliant, it should
>>
>>remain so for
>>
>>>all future
>>>versions of A4, in the same way that a component, once
>>
>>having achieved
>>
>>>100% A4 status,
>>>will remain so until A5.
>>
>>
>>ECM has been made A4.1 compliant. A4.1 is *released*.
>
>
> I'm fully aware of that. But my point is that instead of having
> just Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon
> 4.2,
> and the frameworks will be sufficiently different that a container
> written
> for Avalon 4.0 will not be completely Avalon 4.1 compliant.
>
> That's fine, if you can committ resources to playing catch-up with an
> evolving standard, but the whole point of a framework is that you should
> not *have* to play catch-up.
If the container is upgraded to be 4.1 compliant, you can still use
your legacy code. Is that a problem? That way the user does not have
to play catch-up. They can do it a little bit at a time.
> Now I'm all for evolving specifications, but it is a fact that the
> framework that claims to be most fundamental for everything (i.e. you
> would
> use Avalon to build an EJB server), is also the framework that has
> changed
> the most, and that has consumed most of my catch-up resources.
Really. You think Avalon Framework has changed *that* much? If I am
not mistaken, EJB specs have changed a bit too--probably more so than
Avalon 4.x.
> That is my problem and not yours - but to dismiss the problem with a
> "A4.1 is *released*" is just not right. It assumes that once the gods at
> avalon-dev releases a new version, the rest of the world had better
> keep up or they will, can and should be left behind.
No my point is that because Avalon 4.1 is released we need to support
it.
>>>The Seviceable interface messes all that up.
>>>
>>>It is possible for a container to be Avalon 4.0 compliant, but not
>>>Avalon 4.1
>>>compliant.
>>>
>>>I consider this a problem.
>>>
>>>What to do:
>>>
>>> + ECM remains JDK1.2 compatible. Look, the damn thing is
>>
>>legacy legacy
>>
>>>legacy.
>>> It works fine, but I'd rather have it remain A4.0
>>
>>instead of trying
>>
>>>to mutate
>>> it to A4.1, unless that mutation can be done without JDK1.3.
>>>Branching is
>>> another possiblity. Under JDK1.2, the lookup of a non-Component
>>>implementing
>>> component would throw a ComponentException, under 1.3 it
>>
>>would be solved
>>
>>> via the proxy generator.
>>
>>
>>Why JDK 1.2? When there wasn't a 1.3+ for certain platforms it made
>>sense.
>
>
> As long as Cocoon promises to run on JDK1.2, we have to support it.
Oh, I see. However, you're the only one from Cocoon complaining. In
fact, quite a few of the Cocooner's are in favor of upgrading their
minimum JDK standard--and they need a good reason to do it. We solved
their problem for them.
Also note that it is the ECM in CVS, which means that they would have
to make that change for a *future* version of Cocoon. A JDK change for
Cocoon isn't as harsh as just ripping out the old 4.0 deprecated code.
>>>I think this solves Cocoon's problems.
>>
>>
>>Not everyones.
>
>
> I don't get your point.
There are many Cocooner's who *want* to upgrade the minumum JVM because
they are feeling the restrictions of JDK 1.2--and how 1.3 makes their
lives easier.
>>>Random thought: With the Proxy generator Berin put in the
>>
>>ECM, doesn't
>>
>>>the whole
>>>need for Serviceable disappear?
>>
>>
>>Random thought: If we are trying to divorce ourselves from the need of
>>the Component interface (i.e. migrate to Serviceable) doesn't the need
>>for the ProxyGenerator dissapear? The trend should be simplification,
>>not making things more complex. Any complexity should have a reason.
>
>
> That depends on how you define compatibility between Avalon versions,
> what you prioritize, etc.
>
> *Can* we remove loads and loads of cruft from Avalon? Sure.
>
> *Should* we remove loads and loads of cruft from Avalon? Not so sure,
> since
> we have to consider compatibility.
We are trying to *ease* the transition. In order to do it effectively,
we need to use JDK 1.3--unless you want to write a dynamic proxy
generator using BCEL. That would make ECM able to stay with 1.2--but at
what cost?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Leo Sutic wrote:
> > In theory, if a container is 100% A4 compliant, it should
> remain so for
> > all future
> > versions of A4, in the same way that a component, once
> having achieved
> > 100% A4 status,
> > will remain so until A5.
>
>
> ECM has been made A4.1 compliant. A4.1 is *released*.
I'm fully aware of that. But my point is that instead of having
just Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon
4.2,
and the frameworks will be sufficiently different that a container
written
for Avalon 4.0 will not be completely Avalon 4.1 compliant.
That's fine, if you can committ resources to playing catch-up with an
evolving standard, but the whole point of a framework is that you should
not *have* to play catch-up.
Now I'm all for evolving specifications, but it is a fact that the
framework that claims to be most fundamental for everything (i.e. you
would
use Avalon to build an EJB server), is also the framework that has
changed
the most, and that has consumed most of my catch-up resources.
That is my problem and not yours - but to dismiss the problem with a
"A4.1 is *released*" is just not right. It assumes that once the gods at
avalon-dev releases a new version, the rest of the world had better
keep up or they will, can and should be left behind.
> > The Seviceable interface messes all that up.
> >
> > It is possible for a container to be Avalon 4.0 compliant, but not
> > Avalon 4.1
> > compliant.
> >
> > I consider this a problem.
> >
> > What to do:
> >
> > + ECM remains JDK1.2 compatible. Look, the damn thing is
> legacy legacy
> > legacy.
> > It works fine, but I'd rather have it remain A4.0
> instead of trying
> > to mutate
> > it to A4.1, unless that mutation can be done without JDK1.3.
> > Branching is
> > another possiblity. Under JDK1.2, the lookup of a non-Component
> > implementing
> > component would throw a ComponentException, under 1.3 it
> would be solved
> > via the proxy generator.
>
>
> Why JDK 1.2? When there wasn't a 1.3+ for certain platforms it made
> sense.
As long as Cocoon promises to run on JDK1.2, we have to support it.
> > I think this solves Cocoon's problems.
>
>
> Not everyones.
I don't get your point.
> > Random thought: With the Proxy generator Berin put in the
> ECM, doesn't
> > the whole
> > need for Serviceable disappear?
>
>
> Random thought: If we are trying to divorce ourselves from the need of
> the Component interface (i.e. migrate to Serviceable) doesn't the need
> for the ProxyGenerator dissapear? The trend should be simplification,
> not making things more complex. Any complexity should have a reason.
That depends on how you define compatibility between Avalon versions,
what you prioritize, etc.
*Can* we remove loads and loads of cruft from Avalon? Sure.
*Should* we remove loads and loads of cruft from Avalon? Not so sure,
since
we have to consider compatibility.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> Leo Simons wrote:
> > On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
> > > + Avalon 4 contains the ComponentManager interface and thus
> > > *all* component that claim to be Avalon 4 compatible MUST
> > > support the Component interface.
> >
> > -1 on defining "avalon compatible component" this way. The whole point
> > of service.* is that you can have "avalon compatible components" that do
> > not implement Component!
>
> Basic problem I have with your reasoning:
>
> + It is not OK for a container to not support Composable (i.e. explode
> when
> a composable component is loaded) and call itself 100% A4 compliant.
> This
> is because we may be in a situation when we have a legacy component, and
> we want that to work.
>
> But this is only 1/2 of the contract: What are the rules for legacy
> *containers*?
Calm down. ECM supports Composable. It supports Serviceable (at lower
levels than itself). The problem is that if the component supplied by
ECM does not implement Component, then that component is not accessible
to any Composable. The dynamic proxy fixes that.
> In theory, if a container is 100% A4 compliant, it should remain so for
> all future
> versions of A4, in the same way that a component, once having achieved
> 100% A4 status,
> will remain so until A5.
ECM has been made A4.1 compliant. A4.1 is *released*.
> The Seviceable interface messes all that up.
>
> It is possible for a container to be Avalon 4.0 compliant, but not
> Avalon 4.1
> compliant.
>
> I consider this a problem.
>
> What to do:
>
> + ECM remains JDK1.2 compatible. Look, the damn thing is legacy legacy
> legacy.
> It works fine, but I'd rather have it remain A4.0 instead of trying
> to mutate
> it to A4.1, unless that mutation can be done without JDK1.3.
> Branching is
> another possiblity. Under JDK1.2, the lookup of a non-Component
> implementing
> component would throw a ComponentException, under 1.3 it would be solved
> via the proxy generator.
Why JDK 1.2? When there wasn't a 1.3+ for certain platforms it made
sense.
> I think this solves Cocoon's problems.
Not everyones.
> I also think we can be a bit more bold with A4.2, seeing as the damage
> is already
> done. Maybe we should take this chance to clean up, or even rename 4.2
> to 5?
No. 4.2 is not 5, there is no 4.2.
> As for what the Serviceable interface is: I always considered it nothing
> more than a
> method for Avalon component to access non-Avalon components via a unified
> lookup mechanism.
>
> Random thought: With the Proxy generator Berin put in the ECM, doesn't
> the whole
> need for Serviceable disappear?
Random thought: If we are trying to divorce ourselves from the need of
the Component interface (i.e. migrate to Serviceable) doesn't the need
for the ProxyGenerator dissapear? The trend should be simplification,
not making things more complex. Any complexity should have a reason.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Sep 30, 2002 at 12:08:41AM +0200, Stephen McConnell wrote:
>
> > + ECM remains JDK1.2 compatible. Look, the damn thing is legacy
> >legacy legacy.
> > It works fine, but I'd rather have it remain A4.0 instead of trying
> >to mutate
> > it to A4.1, unless that mutation can be done without JDK1.3.
> >Branching is
> > another possiblity. Under JDK1.2, the lookup of a non-Component
> >implementing
> > component would throw a ComponentException, under 1.3 it would be
> >solved
> > via the proxy generator.
> >
>
> Is the ECM (CVS version) support for Serviceable based on proxying the
> interface? Is so, is there any reason why the ECM cannot simply be
> updated to handle serviceable components the good old fashined way (if x
> instanceof Serviceable ... )?
I think the issue why proxies were used is because Serviceable
components may not necessarily implement Component, so looking them
up in ECM will cause a ClassCastException due to the return type of
lookup().
The proxy adds Component to the list of implemented interfaces so the
return cast succeeds.
It's an interesting situation - but as far as Cocoon is concerned,
they don't have any Servicable (ie. non-Component implementing)
components, so they probably don't need this feature right now.
Maybe in the future, but in the future they'll most likely be looking
to move away from ECM and to the newer Containers anyway.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
>
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>
>>
>>>As for what the Serviceable interface is: I always considered it
>>>nothing more than a
>>>method for Avalon component to access non-Avalon components
>>>
>>via a unified
>>
>>>lookup mechanism.
>>>
>>
>>Nothing less!
>>
>
>OK, so it's, like, x = what I said, y = what it really is,
>lim[E -> 0] ( x - E < y < x + E ), dude? There, set in stone.
>
>
>>>Random thought: With the Proxy generator Berin put in the
>>>
>>ECM, doesn't
>>
>>>the whole
>>>need for Serviceable disappear?
>>>
>>
>>Urggh #&$
>>That's a hack - the approach you outlined above is the right one -
>>recognition of the implications of version and respectin this
>>in terms
>>of the components that have been released, combined with rigerouse
>>documentation of future component releases.
>>
>
>The solution I outlined is also the solution that has the most
>dependencies on:
>
> + People changing their code.
>
> + Us keeping our documentation up to date.
>
> + Us ensuring that 4.0-specific components don't require 4.1,
> due to developer mistakes.
>
>In other words, probably our three weakest points.
>
>The Hack would be a "hack" from the container POV, but would
>eliminate the 4.0/4.1 difference. Of course, the hack only
>works if everything looked up via the CM interface can be
>proxied (that is, it must have a role interface that we can
>use to create a proxy). So you can't lookup an ORB, because
>it is an abstract class, and not an interface. You can code
>around this by defining an ORB interface, but...
>
That's not the case - things like an ORB, transaction server, persistent
state service (PSS), naming service are all example of concrete classes
that represent services in accordance with a standard - the list goes on
and on - coding around these services means that your creating and
exposing non-standard services. The notion that a service provided by
or consumed by a component must implement a interface defined in Avalon
was wrong, is wrong and remains wrong - but that's part of the healthy
process of framework evolution.
Compliance is something rather novel in the Avalon world as and I think
we would have a very difficult time typing to establish a compliance
criteria for 4.1 or 4.0 any time soon. The reason is that the framework
interfaces have some semantic holes - things like the interpritation of
the value passed in the lookup operation (as the most glarring example).
An Avalon Framework 4.2 could attempt to clear these issues up.
Steve.
>
>/LS
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
>
> > As for what the Serviceable interface is: I always considered it
> > nothing more than a
> > method for Avalon component to access non-Avalon components
> via a unified
> > lookup mechanism.
>
>
> Nothing less!
OK, so it's, like, x = what I said, y = what it really is,
lim[E -> 0] ( x - E < y < x + E ), dude? There, set in stone.
> > Random thought: With the Proxy generator Berin put in the
> ECM, doesn't
> > the whole
> > need for Serviceable disappear?
>
>
> Urggh #&$
> That's a hack - the approach you outlined above is the right one -
> recognition of the implications of version and respectin this
> in terms
> of the components that have been released, combined with rigerouse
> documentation of future component releases.
The solution I outlined is also the solution that has the most
dependencies on:
+ People changing their code.
+ Us keeping our documentation up to date.
+ Us ensuring that 4.0-specific components don't require 4.1,
due to developer mistakes.
In other words, probably our three weakest points.
The Hack would be a "hack" from the container POV, but would
eliminate the 4.0/4.1 difference. Of course, the hack only
works if everything looked up via the CM interface can be
proxied (that is, it must have a role interface that we can
use to create a proxy). So you can't lookup an ORB, because
it is an abstract class, and not an interface. You can code
around this by defining an ORB interface, but...
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [heads-up] The version of ECM in CVS has a change in JDK reqs
Posted by Stephen McConnell <mc...@apache.org>.
Leo Sutic wrote:
> Leo Simons wrote:
> > On Sat, 2002-09-28 at 15:26, Leo Sutic wrote:
> > > + Avalon 4 contains the ComponentManager interface and thus
> > > *all* component that claim to be Avalon 4 compatible MUST
> > > support the Component interface.
> >
> > -1 on defining "avalon compatible component" this way. The whole point
> > of service.* is that you can have "avalon compatible components"
> that do
> > not implement Component!
>
> Basic problem I have with your reasoning:
>
> + It is not OK for a container to not support Composable (i.e.
> explode when
> a composable component is loaded) and call itself 100% A4
> compliant. This
> is because we may be in a situation when we have a legacy
> component, and
> we want that to work.
>
> But this is only 1/2 of the contract: What are the rules for legacy
> *containers*?
>
> In theory, if a container is 100% A4 compliant, it should remain so
> for all future
> versions of A4, in the same way that a component, once having achieved
> 100% A4 status,
> will remain so until A5.
Agreed.
>
>
> The Seviceable interface messes all that up.
Disagree.
>
> It is possible for a container to be Avalon 4.0 compliant, but not
> Avalon 4.1
> compliant.
Yep.
>
> I consider this a problem.
>
> What to do:
>
> + All Excalibur components that were released prior to the
> introduction of the
> Serviceable interface have to implement the Component interface
> until A5.
+1
>
>
> + Any new releases must clearly state that they are targeted at A4.1
> unless
> they implement Component, or if they use the service package.
+1
I was thinking about exactly the same thing yesterday in relation to the
Cocoon discussions.
>
>
> + ECM remains JDK1.2 compatible. Look, the damn thing is legacy
> legacy legacy.
> It works fine, but I'd rather have it remain A4.0 instead of trying
> to mutate
> it to A4.1, unless that mutation can be done without JDK1.3.
> Branching is
> another possiblity. Under JDK1.2, the lookup of a non-Component
> implementing
> component would throw a ComponentException, under 1.3 it would be
> solved
> via the proxy generator.
>
> I think this solves Cocoon's problems.
Is the ECM (CVS version) support for Serviceable based on proxying the
interface? Is so, is there any reason why the ECM cannot simply be
updated to handle serviceable components the good old fashined way (if x
instanceof Serviceable ... )?
>
> I also think we can be a bit more bold with A4.2, seeing as the damage
> is already
> done. Maybe we should take this chance to clean up, or even rename 4.2
> to 5?
I think 5 is way too dramatic - but a 4.2 is valid with respect to
deprecation of Component et. al. and makrer interfaces.
>
>
> As for what the Serviceable interface is: I always considered it
> nothing more than a
> method for Avalon component to access non-Avalon components via a unified
> lookup mechanism.
Nothing less!
>
>
> Random thought: With the Proxy generator Berin put in the ECM, doesn't
> the whole
> need for Serviceable disappear?
Urggh #&$
That's a hack - the approach you outlined above is the right one -
recognition of the implications of version and respectin this in terms
of the components that have been released, combined with rigerouse
documentation of future component releases.
Cheers, Steve.
>
> /LS
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>