Peter Donald wrote:
> At 10:30 AM 7/2/2002 +0200, you wrote:
>
>>> Example services that only container can provide;
>>> * Modification/Saving of Configuration object
>>> * Access to ClassLoader hierarchy of app
>>> * Access to ThreadGroup hierarchy of app
>>> * Access to various code-based Security policys
>>> * name of component
>>> etc
>>
>>
>> It seems that this is the issue.
>> If we want to be portable between containers, this just won't work.
>>
>> IMO *no* container should *ever* be the only one capable of giving
>> that service.
>
>
> Thats where individual containers differentiate. ie Some applications
> will require these extra services.
>
> Some real examples from Phoenix;
> * MBeanServer should be server wide and managed by kernel. Thus in some
> cases kernel needs to expose MBeanServer to components so they can do magic
It's a service, so it can easily be given via Serviceable.
The fact that it's tied to a specific container is not a problem, since
with the three container approach we are effectively making three
component profiles, ie with increasing demands on the container.
MBeanServer service would simply require Phoenix.
> * ClassLoader needs to be exposed to components like ServletEngines. ie
> You want to know exact hierarchy from Common to shared to other
> ClassLoaders. In some cases you want this to be pluggable. ie Embedding
> Tomcat/Jo/Jetty into an EJB server requires that the ClassLoader
> hierarchy be re-arranged but the different components still access
> ClassLoaders via symbolic names
Still another possible service.
> In the future (JDK1.5 time), most servers will need to be able handle
> Isolates and that will usually be managed by container etc.
They are still exposable as services.
I understand your POV, but by making them services, we are being more
consistent (ie a service is a Service is a service) and paving the way
for a possible future indipendence from the container (ie the kernel
would expose itself as a service to these services).
> There are some commonalities that could be homogenized. ie Phoenix,
> myrmidon (and cocoon?) all provide a base directory from which component
> can operate. Phoenix and myrmidon also provide the component with its
> own name. The keys for these values could definetly be standardized
> across the board.
Yes, this is something that could/should? be done.
Context is something like XML: without a schema it's just making
documents unportable.
> List of common data values;
>
> * Container version/build number
> * component name
> * base directory
+1+1+1
> * common/shared ClassLoaders (at least common to 2 containers anyways).
Not as a service?
>> Context is a very delicate point in the context ;-) of component
>> portability.
>
> Mostly if you use it you become unportable ;)
Yeah, I like this explanation :-)
>> Personally I tend to think (sensation) that the whole concept of
>> Context is flawed, because it is usually used in the wrong way.
>
> It is a bit icky which is why it is probably the most rarely used part
> of the framework.
By good developers, that is ;-)
> But is necessary at times - pretty much anytime the
> container is the only provider of service/data or that data is generated
> at runtime by container.
I would just say "data that is generated at runtime by container or
other services".
As for services, I would simply tend to use Serviceable.
Cocoon enhances lifecycle with SitemapModelComponent.
public interface SitemapModelComponent extends Component {
/**
* Set the <code>SourceResolver</code>, objectModel<code>Map</code>,
* the source and sitemap <code>Parameters</code> used to
*process the request.
*/
void setup(SourceResolver resolver,
Map objectModel,
String src,
Parameters par) throws ProcessingException,
SAXException, IOException;
}
If we analize it in the light of my previous suggestions, we could
simply use Parametrizable for Parameters, Serviceable for SourceResolver
and Contextializable for objectModel and src.
No?
>> What cases can *only* be /reasonably/ solved by a Context?
>>
>> How can we try to enforce good use of it?
>
> Impossible ;)
;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
