[jboss-dev-forums] [Design of POJO Server] - Re: Hot deploying deployers - deployer chains

[scott.stark@jboss.org]

"adrian at jboss.org" wrote : "scott.stark at jboss.org" wrote : 
  |   | The logging really needs to be part of the core bootstrap. Enabling trace level logging of the kernel using -Dlog4j.configuration=log4j-trace.properties currently is not working as expected,
  |   | .
  | 
  | That's because 
  | 1) -D against run.sh doesn't happen until the parsing of the main() arguments
  | 2) It should be a url
  | 
But the kernel logging starts after the ServerImpl is loaded so this should not matter. I'll drill into this latter.

"adrian at jboss.org" wrote : 
  | anonymous wrote : 
  |   | I'm not clear on why we need a distinction between 1/2, especially in terms of loading the legacy mbean service descriptor. Why not just have:
  |   | 
  |   | 1. A boostrap-beans.xml to define the kernel and profile service implementation.
  |   | 2. A server/config/deployers to define the deployer packages.
  |   | 
  | 
  | This is because I want to seperate the core configuration
  | file from the user configurable options.
  | The core configuration is implementation detail that we are likely
  | going to want to change. Mixing it with user options make this hard.
  | 
  | This is certainly a short coming of the current conf/jboss-service.xml
  | You can't create one and use it from release to release because it
  | changes.
  | 
Ok, but this is mixing sever configuration files with user configuration files that really should be an implementation detail of the profile service. boostrap-beans.xml is what I'm defining as the core configuration that user's do not touch. It defines the profile service which is what reads in user configuration files and overrides. Without speaking of a particular profile service impl, I don't know where the user configuration lives.

"adrian at jboss.org" wrote : 
  | anonymous wrote : 
  |   | If we want a shared class loader used by the deployers the server/config/deployers can include a classloader-beans.xml descriptor pointing to the lib directory and the deployers can declare a dependency on it.
  |   | 
  | 
  | The problem with a classloader-beans.xml is there
  | is no working classloader implementation besides the UCL classloader
  | at the moment.
  | It is something that should be looked at, since there is also
  | currently no way for a -beans.xml to identify itself as scoped.

This is just an issue of having sufficient support for specifying class loader metadata at the kernel config level, and a class loading deployer to support it. As long as we have a ucl bean factory and class loading deployer I don't see why we can't support the existing scoped ucl model. If I want a scoped bean deployment, I define a LoaderRepositoryConfig bean and reference it, or include a ucl-loader-config.xml descriptor in the deployment.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972667#3972667

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972667