> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > > > >When we are separating code needed for compilation vs. code needed > >for running a system, it makes sense to separate the implementation > >from the interface definition. For this reason, I would like to set > >up Avalon5 so that the person developing for it will have a jar with > >a set of interfaces only. Not one implementation at all. > > +1 (in principal) > There are a few primative classes that we may want to break this rule > with - things like the Version class as an exmaple - but yes, I agree > with the direction.
Right. The distinction being whether these primitive classes are *part* of the interface. For instance, if we merge the Configuration interface and implementation, we have made the new Configuration class part of the *interface* for Configurable--even though it is a concrete class. It is part of the contract, so to speak. > >In fact, some interfaces in Avalon 4 > >have no real meaning outside of a container such as ServiceManager or > >Context. > > > I'm rephrasing that to "some interfaces in Avalon 4 have no > real meaning > outside of the artificats provides by a container such as > ServiceManager > or Context." and asuming that my rephrasing is you intention. Yes. > >The fact that most of our containers do not use the "default" > >implementation in the JAR leads to support that oppinion. > It also allows > >us to have focused "support" JARs. > > This is a key thing - with the introdcution of a container API - the > client should not being using things like DefaultContext - > instread they > should be wortking with the contaiment API and doing a clean > seperation > of client verus container side coding. Seperation of implementation > from interface (contracts) reinforces the focus on using contains > instead of coding your own interim solution. Exactly. > >== Focusing Support == > > > >We might consider leaving the "braindead" versions of the loggers > >for debug purposes (i.e. NullLogger and ConsoleLogger). They can > >be placed in a subpackage called debug or something. > > > > > > I think this is an area that needs more work. As you know - > the work in > Merlin has created another approach to logging configuration > - and the > reson why ios that the existing models don't play well with an > heirachical containement models - and they don't provide and formal > metadata - both of which can be addressed but the place to > address this > is inside o.a.e.logger - not in Merlin or other container > level packages. Right. However if we define the areas in which the contract needs refining, we can come up with a solution that works most of the time. If there are any alternatives, most of the time they will be modeled after the solution that is in place. > >It will also allow us to add support for certain environments. > >For example, we might want a specific contract for containers > >embedded in a Servlet context--i.e. where the values come from > >for standard entries and accessing configuration values from > >the ServletContext, etc. By providing a "ServletSupport" JAR, > >we can have the proper Logging formatters to glue into a Servlet > >environment as well as provide proper context support for that > >environment. > > > > I would also like to see some migration toward > "business-level" logging > - notions of logging levels such as ALERT, NOTIFICATION, etc. Things > that are more tangible to suits that what the framework > currently provides. I'd like to mention that most logging toolkits are meant for developers/administrators to determine what is going on. For business level things (like ALERT, NOTIFICATION), we either need a different tool, or a different channel. For instance, if we have a Notifier component, it will disperse messages at a business level. It is a different tool so that the process of business events is handled differently than the general debug logs. Currently, we can easily add a business specific channel. Something like "process.notification" and map logging levels to that channel. The logging mechanism would handle that channel differently than the rest. I prefer the Notifier component because it is both business level, and it can be customized to provide escalated notifications if need be. I think that it is a *component*, and not necessarily something that the container itself needs to supply. > >== Pluggable Contracts == > > > >The concept of "pluggable contracts" is the process of having > >a well defined <i>set</i> of contracts that we can use in a > >given environment. We always need the <i>constant</i> or > ><i>guaranteed</i> contracts to act as a base. The contract > >sets that get superimposed on the base contracts are constant > >for the environment. If you change the environment, you get > >a new set of contracts. > > > > I'm reading the words and assuming that this is beasically > the same as > the notion of "strategy" that I've been dropping on this list > from time > to time. I'm thinking about a container that is hard coded > at the level > of strategies - and examples of strategies include A4 deployment, A5 > deployemnt, etc. Inside a particular strategy you may find subsidary > strategies - e.g. a strategy enabling lifecycle extensions or other > concepts such a A4.1 lifestyle strategy (based on marker interfaces) > versus a 4.2 strategy (mased on meta) - as examples. uh, yeah. Different words I guess. But yes, it is the strategy for mapping an applications environment to the component/container contracts. > >it helps containers provide a consistent environment to the > >component regardless of the environment. > > > > Refreasing this to - "it helps containers provide a > consistent solution > to the component adapter to its environment" - which is not what your > said - are we thinking about the same thing ? Essentially, but the phrase "to the component adaptor to its environment" is very clumsily worded. Could you clarify what you mean? > >By standardizing component contracts strictly from the > >viewpoint of the component (i.e. interfaces) we provide a > >standard in which the component author can feel confident that > >their component can work anywhere. > > Yep. > > But possible (more concretely) - we will be able to provide to the > client developer the means throughwhich they can express > constrains as > to the environment thair component is applicable within. Yes, through metadata. In fact the same component can take on new features depending on the environment. The important thing is to provide the base contracts to which it needs to be developed. Not all components can or should be distributed. The ones marked with a "remotable" attribute would be exposed by a container that supports that action. Again, it is a strategy that is implemented by the container--which in turn is affected by the environment. A container that would otherwise be able to make components remotely accessible to other VMs might be restricted by the security settings. All the code is there, but the container wasn't given the priveledges to expose the components on the wire. Such a failure shouldn't cause the system to cease to function, but merely reduce the functionality. <off-topic constraint="important to consider"> One problem with very modular systems is security. If a container allows a high level of runtime resolution of features, there is the ever present risk of a "rogue" JAR being put in the classpath somewhere and performing a "Trojan" attack. We need ways of testing these modules/strategies and validating them--even if the JAR was placed in the $JAVA_HOME/jre/lib/ext/ directory. It can be accomplished, but we need to provide extensions to the normal JAR spec to allow us to validate them. Failing securely is very important. </off-topic> > >By standardizing component contracts strictly from the > >viewpoint of the environment to the container, we provide > >a standard mechanism that any Avalon user will be able to > >use to customize the environment. No extra coding is necessary, > >the container can simply use the JAR that provides support > >to the environment and everything is happy. > >those defined by the interfaces. > > > > > > There are couple of different things here: > > * the computation environment > * the contutation model Is that "computation model" or "continuation model" ? However, you are correct. There two different levels to consider. The component/container relationship would be described as the "Computation Model", while the container/environment relationship would be described as the "Computation Environment" > The environment is talking about constraints wheras the model > is talking > about the vehicle through which solutions are delivered (e.g. A4.1 > version A5) - but this is very esserteric so I'm going to sign-off! Talk to ya later. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
