Schaible, J�rg wrote:
The overall plan is to provide the ability to request of service from a block. As an interim measure I've added appliance and block accessors to the Block interface which return explicitly registered appliance and block instances. This should provide some immediate help - but keep in mind that this may/will change as the service resolution side gets in place.Hi Steve,All dressed up and nowhere to go!
Sounds to me like we need to publish the root block into a JNDI context, have this picked up by the servlet, update plock to provide access to appliances (and through appliance acess to services). I think I mentioned in an earlier eemail that the is a JNDI API that is being seperated out of the Tomcat project. Noel (James project) ws discussing this a few weeks ago - he probably has more details. This is probably the fastrack solution and gets us som useful content in the process. If you or someone else can take this on I can sort out the block expose of appice references and/or services.
We also have in our app some lightweight JNDI ... <g>is createdIf you running one thread per request you may want to look at the per-thread lifecycle policy. This policy ensures that a new component instance
The servlet container is free to create any number of instances of my servlet calling the same servlet instance concurrently. The servlet instances itself will normally not be destroyed until the servlet container terminates, but even this is part of the vender's implementation strategy. So, normally I would define a singleton as a class with exaclty one instance independent of any thread - which might not be true in this context here. I assume this means one instance per servlet instance, which suits perfectly.once per-thread. There is an example of the per-thread componet in the playground. Default lifestyle behaviour is singleton (i.e. thread safe componet).Hmmm. What means "singleton" in the context of a servlet.
You can achieve instance-per-servlet instance by using the transient policy. This means that a new instance is created per request - i.e. your servlet is in control - it get the service once, caches it for the duration fo the servlet lifetime and releases it on servlet disposal.
OK. This is what I want most of the time.Wow - that so close to volunteering .... :-)Not yet. :)Yes and no. I will have one single servlet at all working as controller and currently as kernel loader.Hmm. Is there any way to read directly from the file system?The block.xml gives me the class names of the services. The files are already in the classpath and all I would need is to load the .xinfo using getClass().getClassLoader().getResource(). Because building every time a jar and deploying it to the servlet engine would be much more effort than using code replacement features during debug.
I'm assuming that you will Merlin is one servlet, and from that servlet you will will publish services or blociks or whatever in a name context which will be accessible by other servlets in you application.
Autodiscovery via extension directoriesAs far as the rott/manager environment - there are a couple of mecahnuism for enabling Merlin's access to jars - (a) autodiscovery via classloader scanning, (b) autodiscovery via extension directories, and (c) explicit refernece to the file system - but this can be problamatic if your not in control of the deployment environment.
Can you tell me more about (b) and (c)? During development I will have no jar files for the blocks at all. Hope this clears things up.
---------------------------------------
In your <engine/> declaration you can include a <library/> element. This element tells the classloader that there is a directory or directories from which extension jar files can be loaded. This works in conjunction with extension dependency declarations in the manifest of jar files loaded into Merlin (see Sun standard extensions spec). Before loading jar files, you can tell Merlin to look in particular directories for extensions. When loading jar files declared in the <classpath/>, Merlin will check the manifest and if it finds a jar extension dependency - will look in the extension directories declared in the <library/> tag, directories declared in parent engine <library/> tags, and directories declared under the java.ext.dirs system property.
An engine declaration containing library statements looks like:
<engine>
<library dir=".">
<include name="dist"/>
<include name="lib"/>
</ibrary">
<classpath>
<!-- etc.-->
</classpath>
</engine>
Explicit reference to the file system
-------------------------------------
This is when you include jar files in you classpath descriptor. This approach works fine for application scenarios where the structure of the file system is known and stable. For example, after building Merlin (from current CVS) you will see a subdirectory merlin/merlin. In here you will find the james directory which includes a block.xml file for running james - file references in the classpath descriptor are all relative to the directory containing the block.xml file.
The engine declaration looks like:
<engine>
<classpath>
<fileset dir="../../../../../jakarta-james/phoenix-bin/lib">
<include name="excalibur-io-1.1.jar"/>
</fileset>
<fileset dir="../../../../../jakarta-james/lib/candidates">
<include name="excalibur-pool-1.2.jar"/>
<include name="excalibur-thread-1.1.jar"/>
<include name="commons-collections-2.1.jar"/>
<!-- etc. -->
</fileset>
</classpath>
</engine>
What I don't like about the above is that the declarations break as soon as you move the location of the Merlin installation or the location of the block.xml file. What is really needed here is property expansion - e.g.:
<engine>
<classpath>
<fileset dir="${james.home}/lib">
<!-- etc. -->
</fileset>
</classpath>
</engine>
The property ${james.home} could then be declared in the config.xml file which would decouple reference in the classpath descriptor from the filesystem.
A lot of changes went in over the weekend. The debug stuff went in on Sunday along with some changes to separation between kernel and block files. Part of this simplifies the files needed - kernel is now just about the kernel configuration and blocks.xml is just about a block deployment scenario. This should (a) break you current kernel loader - sorry about that! and (b) make you updated loader a lot smaller.[...] If we do this right - the active servlet will gain access to a service via something explosed in a naming context (you can even stick it into application vairable for testing purposes). All you client needs to do is ask for the service - that it - the rest will just happen (once we have the service publication bit is done).
[...]A grep through the sandbox code did not show any occurence
of "urn:merlin:debug" ... when did you implement this? Last couple of days - - ok, I'm checking.My last refresh was from Friday morning.
After doing a checkout you take a look at the src/repository/README.txt as this describes the enhanced deployment approach and how to run the demos.
I think some additions on the Assembly package will be required here (only jar scanning is supported). Perhaps the best move at this moment is to get in place a servlet demo - this will give things a little more focus and lets us better explore practical issues.[...] Smells like a bug ... I'll dig. As to the exception - is you .xinfo in your jar file?Well, no, I have none! As stated above I tried to get the block loaded from the file system. Therefore I thought about overloading the DefaultXXX classes.
Cheers, Steve.
--
Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
