Hi Filip,

it is not exactly clear to me what you're trying to do, but I might be of assistance anyway :D

Filip Defoort wrote:
Examples:
- add components:
  Consider the provider stuff we've been talking about.
  I have a custom container inside of the main container with
  the standard providers. Now I would like to add additional providers
  into that container from the extension library.
  The problem is that the extension libraries are not loaded
  in the same class loader as the main components (I'm using
  a URL classloader to load all jars in a lib/ext/ directory
  and execute a main class in them -- that's what I would like
  to change to have a .xconf in each library and load that one
  to add the different components of the jar).

uhm, so you basically want to load lots of jars, merge all component declarations in all those jars, and put all those into fortress? You can merge those configurations using


http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/configuration/src/java/org/apache/excalibur/configuration/merged/ConfigurationMerger.java

- extend components:
  Consider e.g. a component that maintains a list of available mime
  types. There's some
  basic mime types in the main configuration and the extension
  library wants to add mime types. How do I go about that?
  I could add a method addMimetype() to the main component,
  and look up that component when loading the library, and add
  the mime types, but isn't that circumventing the configure()
  lifecycle methods?

nope. IIUC you're providing a MimetypeInformationService in the base container, and passing that on to "children" (using service()). Nothing wrong with that.


class MimetypeInformationServiceImpl
{
        HashMap m_types;

        configure( Configuration c )
        {
                // read base mimetype info
        }

        Mimetype get( String name )
        {
                // read from m_types
        }
        put( Mimetype type)
        {
                // write to m_types
        }

}

class MyClassInSomeExtensionJarWhichMayGetLoadedAtRuntimeALotLater
{
        service( ServiceManager sm )
        {
                m_sm = sm;
        }
        initialize()
        {
MimetypeInformationService mis =
(MimetypeInformationService) mis.lookup(MimetypeInformationService.ROLE);

mis.put( MY_ADDITIONAL_TYPE );
        }
}

I'm not seeing the use case, but I'm not seeing a problem either :D

I was thinking about creating a ExtensionContainer which I pass
a list of .xconf files of the various extension libraries to load that would then load the various jars
and create subcontainers for each of the configurations that it would
find. That seems the cleanest solution, but then I have the problem
that I can't add components to e.g. provider container from the first
example above nor e.g. the list of mime types (I would then have two
different mime type components, one in the main container, one in the
extension container).
Also, components from the main container wouldn't be able to transparently access components from the sub container

and you probably want it that way --> http://avalon.apache.org/framework/guide-patterns-ioc.html


Anyways, I'm a little bit at a loss here, so if any of you guru's has
any insights that may push me a step in the right direction, that
will be very much appreciated !!

make sure you don't build more features than you need. If what you want to do is run many applications in a single appserver, you should be looking at phoenix. If all you're doing is really loading components from multiple jars, just extend the default container to understand which config files it must merge together.


If you are looking at advanced dynamic deployment scenarios, you may want to take a look at the assembly/merlin work Steve's been doing over in the avalon-sandbox.

cheers,

- Leo



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to