Stephen McConnell wrote: <snip/>
The repository package lets you create an object using a common factory pattern. It hides the problems related to building the object that is returned including the implementation classloader with the related implementation classes).
that sounds an awful lot like a description of a container. Confused over here :/
The avalon-repository-main package is a kind of very limited micro container. What is does it provide a framework for the following:
1. creation of a factory from an artifact reference 2. factory provides default instance creation criteria 3. client customizes criteria 2. client requests new instance creation relative to criteria
And in the background the repository impl is handling all of the stuff to do with jar dependencies, classloader construction, etc. The client does not see any of this.
So for example, let say you wanted a LogKit logging solution - you would use the repo to create this based on an artifact url (e.g. "artifact:avalon-logging/logkit/logkit-impl").
how different is this from sourceresolve (for example)?
The repository stuff enables construction of the micro-system for the creation of a new instance (a.k.a. classloader and default creation criteria). Any retrieval aspects are only related to classic artifact retrieval using the repository (cache and remote hosts). This is quite different to sourceresolve - which (based on limited experience) handles the mapping of urls to drivers.
The repo will construct the classloader with all of the stuff needed for a logkit logging strategy together with a logging system configuration.
so it sorta handles the ClassWorlds job as well, configuring things avalon-style. Right?
Yes - ish - sort of. The avalon-repository stuff is like classworlds backed by a resource cache and remote resource retrieval.
The factory implementation would read the configuration and identify the target factories that required. For each target factory (e.g. File, JDBC, JMS, LF5, Servlet, whatever, the factory implementation would use the repository facility to load each target factory.
so basically you want to add an alternative logger factory implementation that delegates a lot of functionality to a repository implementation. Right? Why is that backwards-incompatible?
Excalibur Logging makes a lot of assumptions about the environment it is running in. For example it assumes that the classes that are needed will be available in the current classloader. So if I (administrator) declare that I want to create a target to handle SMS log events then I also have to update the classloader definition with the correct versions of jars and their dependencies. This forces a sub-optimal solution because I've now polluted a kernel definition with a classloader definition which is specific to a particular logging target.
Instead of this - if I declare a logging target, I can leave the system to resolve automatically the related dependencies for that particular concern with the keno ledge that this implementation specific are nicely isolated away. If, via JMX for example - I change the target definition, then the classloader that was used to establish a now-redundant target can be garbage collected.
This means that any implementation resources (e.g. servlet stuff, or JMS stuff gets pushed into its own classloader - and that dependencies for the respective solutions are handled automatically by the repository).
My gut feeling persists.....it seems to me that a logger service should not be aware of classloader issues or anything like that, but rather, the active thing inside the repository (I'd call it kernel but that doesn't really apply with merlin...more like one of the appliance bits I think) sets that up and just puts the log management facility in there. Inversion of Control, I guess....
We agree - "logger service should not be aware of classloader issues".
If I have a logging system - and that logging system provides plugin-in solutions for custom target implementations - e.g. SteveTarget and LeoTarget - what I'm describing means that the logging implementation does *not* need to worry about the jar files needed to establish a classloader to establish SteveTarget, or the equivalent when establish LeoTarget.
The alternative (Excalibur Logging approach) is that the generic logging system implementation needs to have SteveTarget and LeoTarget in its classloader at the same time. This means that the classloader is not recoverable unless both SteveTarget and LeoTarget and not longer referenced, and that your fair game for class version conflicts (or at least your pushing this overhead onto the administrator).
The logger service is just a passive component that knows how to construct loggers based on its configuration and some simple parameters.
The logging service - yes - but the process of establishment of the logging service implementation is not a passive process.
Containers (appliances, repositories) use it to do just that. It sounds like you are introducing a sort-of-container-dependency (the repository package filling a container-side role in a container-component relationship, and the logger factory using it) in a component. Which sounds bad.
Can you explain the "sounds-bad" bit. From my point of view the logging service implementation is using a micro-container to build resources (targets) that are *part-of* the logging system implementation.
I hope I still don't get it 8-)
:-)
Cheers, Stephen.
Oh well, I used to be unhappy about the logger package anyway...I've learned to ignore that feeling over time :D
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
