Hi Filip,....
it is not exactly clear to me what you're trying to do, but I might be of assistance anyway :D
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
ha, this does exactly what I want.. great!
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
Great. One additional question on this one: does the MyClassInSomeExtensionJarWhichMayGetLoadedAtRuntimeALotLater stay loaded or is
there a way to have a "transient" component: just gets initialized(), and then forgotten
about ? Probably doesn't really matter, the overhead should be small..
More info reg. the use case: consider instead of mimetypes which is kind of a dumb example,
the case of structure/naming conventions for different "entities". What types of entities can exist in the
system depends on what edition(s) of the app is(are) running.. So there's a general registry
that deals with what entities can exists and how they relate to each other, but the actual info about
exactly which entities can exist comes from the edition library. That info exists as simple things
like what entities can be children of what entities, but also has custom classes for each entity that
define what the restrictions on the name of each entity are (all have e.g. isValid(), autoCorrect()
methods). Hope this makes it a little clearer, let me know if not, then I'll try again ;-).
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
yes... there's a whole slew of security implications with that one also..
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.
Well, I'm dealing with an application that is, although it's nicely split in core (common/client) and
extension libraries (different "editions" of the application, with possibility to run different editions
together) is basically a client swing application. This now needs to move towards
1/ being able to run on a server with a thin http client
2/ being able to run on a server with a fat swing client
3/ being able to run standalone, without any server back-end (the cheapo and on the road version).
That's why I've been looking at getting everything redesigned in a more structured manner, with individual
components so that this more will be easier. Phoenix is probably way overkill, definately for now..
Thanks a lot for your help, Leo, it's very much appreciated!
- Filip
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
