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> > >>If 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 > is created > >>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. > 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. > > > > > > 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. :) > >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. Yes and no. I will have one single servlet at all working as controller and currently as kernel loader. >As 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. >[...] 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. > [...] > 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. Regards, J�rg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
