avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: [proposal] avalon 5 ComponentManager interface
Date Thu, 13 Jun 2002 12:07:25 GMT
> Any reasonable container needs to be able to establish the following 
> information:
>   1.  the class of the component
>   2.  the service interface class names and lookup keys
>   3.  a configuration / parameter description
>   4.  a context declaration
>  From here is just plan lifecycle management.  So lets try to pull 
> together a summary of how each container handles resolution of the above 
> information.
> These are the two containers I know "intimately".

that's a me-too there.

> Could we get a similar summary for the other two containers?

and here I can't really help :/

> >nope. As container behaviour is undefined in the framework, you cannot
> >be sure whether it does any interpretation. 
> >
> On this I agree.  
> >You'd have to check with the container.
> >
> Which is where we are getting into trouble.  Nothing at the level of the 
> component runtime should need to be aware of a container approach. In 
> principal, one component implementation should be able to be deployed 
> with multiple meta-data sets.  And in principal, if the component 
> respects the Avalon interfaces and lifecycle semantics it should operate 
> successfully.

uhm, you'd have to check with the container at deployment time, in the
sense that if the container enforces constraints over and above avalon
framework (which isn't necessarily bad), you need to figure out whether
your component works within those constraints.

I didn't mean "you have to check in some programmatic manner".

> >there is no "should", except it is a convention already in place (like
> >our coding conventions, or the javabeans naming scheme), and it is a
> >convention that allows some clever stuff to happen inside ECM and
> >phoenix when a correct meta information definition is missing.
> >
> So we are talking about semantics implied by ECM over and above the 
> framework.

not only ECM. Also a lot documentation, which has done so for a long
time. And allmost all current components in avalon CVS.

>  From your comment I'm assuming that ECM is using a service class name 
> as a lookup key. Given that ECM is hadling the instantiation of my 
> component, would it not possible for ECM to check for role-to-service 
> mappings during the composition cycle? Or am I getting this all wrong?

I wouldn't know; never wrote a line of code for ECM (I think). Berin
implied a link though.

> Here is the URL for the javadoc of what is currently in place on the 
> association graph component.
> http://home.osm.net/assembly/index.html

keep it up...

> >>A third concern is 
> >>more of fear that "we" simply slide from "recommending" an approach of 
> >>"applying restrictions" - which is already been suggested.
> >
> >we already apply restrictions in practice. The only container with a
> >formal release, known to be in broad use (anyone knows how many results
> >google gives for "cocoon hosting"?) is ECM, which applies these
> >restrictions.
> I understand that Fortress shares several characteristics with ECM.  Do 
> the restrictions we are talking about apply equally to Fortress and ECM 
> or is this an ECM specific issue? I would be really interested in 
> hearing from anyone involved deeply in Fortress about this.

"me too" again =)

> Yes - because the meta-model I'm working with has an explicit attribute 
> detailing the role name and I very much want to apply that model to more 
> that just the deployment of a component by a container.  That attribute 
> should not be polluted due to the requirements of one container type. 
> The important point is that we don't hide from this under a 
> "recommendation" but instead - deal with issue - figure out and 
> understand what is possible now and in the future.

agreed. We could now more formally define the role than we have done,
then deprecate that when we figure out how to do backwards
compatibility. Something like that.

> >it *is* a slippery slope, but we're already on it and climbing back to
> >higher ground will mean we'll have to sever the chain binding us to some
> >of our friends, meaning that they will tumble down the hill.
> >
> I'm not convinced of that at this time.  I would really like to hear 
> from ECM and Fortress people about options.  If I understand correctly, 
> Leo/2 thinks the dependency/role question can be handled within Fortress 
> - if that correct, this is at least lets us address ECM and consider the 
> possibility of enhancing ECM to provide something equivalent without 
> breaking anything that exists.  This would be better for Avalon, and 
> better for the Cocoon community too.

yes. I'd like to see that =)

I personally don't care that much -- I have no problem using the
"recommendations" -- as long as we're in agreement and get it all

Since phoenix does (I think) some handy stuff with the role mapping (if
there is none, use the interface name), I'd say that should be possible.

> >In how many of the existing containers do you want your components to
> >work? 
> >
> Today - 2.
> Merlin and Phonix.

for me: Phoenix and ECM. One for standalone, one for servlet-embedded.

> >How many of the existing components written for those containers
> >that make the same slippery assumption as those containers do you want
> >to work in future containers?
> All of them (but I'm limiting by immediate scope to components that are 
> agnostic).  But seriously - yes there are issues - and those issue need 
> to be treated as such, not pushed under the carpet with sweeping 
> "best-practice" statements.  The issues are totally reasonable - the 
> whole notion of container interoperability is a new thing and we should 
> confront it honestly.

well put. I think everyone now at least understands that there really is
an issue.


- Leo

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message