[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote : "scott.stark(a)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(a)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(a)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
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote : "scott.stark(a)jboss.org" wrote :
| | Second, explain how the tree is used given a DeploymentContext representing an ear with the full contigent of javaee components, and customized aspects like security and logging.
| |
|
| But to answer your question (in brief), the Deployment(Context)
| is structurally analyzed (I assume no predetermined managed objects)
| into its javaee components which determines the metadata location.
|
| This metadata location identifes a list of configuration files
| -security.xml, -logging.xml (besides the javaee files).
|
| These are matched to the deployer chains.
|
| e.g. The -security.xml might create an application policy that is
| added to the metadata repository
|
| Input=-security.xml
| Output=real
| When=some ordering after the metadata repository context is constructed
|
| e.g. A log4j.xml might create a scoped (based on classloader)
| logging configuration
|
| Input=log4j.xml
| Output=real
| When=some ordering after the classloader
|
| The chains are more important when you have flows like the
| rar deployer:
|
| ra.xml -> rar metadata -> servicemetadata -> mbean
| rar parser -> rar deployer -> servicedeployer -> real
|
| The reason to split the rar parser from the rar deployer is
| that:
| 1) The rar parser is not required for predetermined metadata
| 2) Some other parser/deployer earlier in the list can construct
| the rar metadata for deployment from some other mechanism
| and use the later rar deployer to do the real work
I agree that structure mapping and even metadata parsing need to be distinct phases of the deployment model. These are needed for the profile service behavior that maps to the jsr88 function, as well as supporting the introduction of aspects that can affect the metadata.
I'm not clear on exactly how the input is described and utilized as a key one can use to obtain the correct starting point for a query to the MainDeployer. Input can be anything from vfs path patterns to concrete metadata classes.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972662#3972662
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972662
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by adrian＠jboss.org
"scott.stark(a)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
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.
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972661#3972661
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972661
19 years, 6 months
[Design of POJO Server] - Re: Updating docs
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : My only question is whether there are distinct outputs for the runtime metadata and management interface. Having to create management views from the raw deployer metadata is too cumbersome and does not lend itself to introduction of higher level notions like extracting server wide views like all network ports in use. So an explicit management view like the ManagedObject notion that existed previously is something that should show up in a Deployer contract.
|
Yes, but in principle the ManagedObject can be constructed from
the raw metadata/real object by correctly annotating it
either in the metadata or on the object.
This is a similar mechanism to how the OpenMBean stuff works
(or at least will work in JMX2.0) except we will likely need a
richer annotation set and some conventions:
e.g.
| public class MyClass
| {
| // Annotated valid values and the config impact
| @ValidValues(min=1, max=100)
| @ConfigImpact(Impact.RUNTIME_CONFIGURABLE)
| public int setPercentage() {}
|
| // Effectively inject the port configuration
| public void setServerSocket(ServerSocket socket) {}
|
| @Statistics // or with MyStats suitably annotated
| public MyStats getStats() {};
| }
|
>From this kind of thing, a ManagedObject can be constructed that is
easier to handle by the management layer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972658#3972658
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972658
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| So how do you want to structure this?
|
| For now, I'd suggest:
|
| 1) Using the conf/jboss-service.xml
| as the "core configuration"
| which would contain:
| * The static jars to deploy as now
| * The core logging
| * The remaining legacy bits
|
| We should aim to remove most of this over time,
| either althogether or into their own deployments.
|
| 2) Create a server/config/deployers
| which serves to idenitfy the deployer packages
|
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, and if we want to use jdk logger we need to install a LogManager early on.
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.
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.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972655#3972655
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972655
19 years, 6 months
[Design of POJO Server] - Re: Updating docs
by scott.stark＠jboss.org
"adrian(a)jboss.org" wrote :
| In fact, I'm aiming for an api where the deployers don't
| really deal with the lifecycle directly and instead provide
| metadata on which parts of the deployment they want
| to do work on and "when".
|
| e.g.
| SARDeployer
| I create a ServiceDeployment and LoaderRepositoryConfig from -service.xml
|
| ServiceDeploymentDeployer
| I split a ServiceDeployment into its component ServiceMetaData
|
| ServiceClassLoaderDeployer
| I create classloaders from LoaderRepositoryConfig
|
| ServiceDeployer
| I'm the real deployer of ServiceMetaData
|
| etc.
This makes more sense. My only question is whether there are distinct outputs for the runtime metadata and management interface. Having to create management views from the raw deployer metadata is too cumbersome and does not lend itself to introduction of higher level notions like extracting server wide views like all network ports in use. So an explicit management view like the ManagedObject notion that existed previously is something that should show up in a Deployer contract.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972652#3972652
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972652
19 years, 6 months
[Design of POJO Server] - Re: Hot deploying deployers - deployer chains
by adrian＠jboss.org
"scott.stark(a)jboss.org" wrote : "adrian(a)jboss.org" wrote :
| | So basically, I don't believe the MainDeployer/deployers
| | should be a part of the bootstrap configuration and that
| | there will be some form of "hotdeployment" even if it
| | is the initial step that creates a fixed list
| | before the real deployments are done.
|
| Ok, I'm fine for delaying the loading of the deployers as component of the profile after the bootstrap, but I'm not really interesting in addressing arbitrary hotdeployment of everything outside of the bootstrap kernel as that really is not the primary focus of the deployer redesign.
|
So how do you want to structure this?
For now, I'd suggest:
1) Using the conf/jboss-service.xml
as the "core configuration"
which would contain:
* The static jars to deploy as now
* The core logging
* The remaining legacy bits
We should aim to remove most of this over time,
either althogether or into their own deployments.
2) Create a server/config/deployers
which serves to idenitfy the deployer packages
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972650#3972650
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972650
19 years, 6 months