September 2006 - jboss-dev-forums

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : | The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort. | I never suggested full hotdeployment was the solution we should implement now. My suggestion was an intermediate stage between the bootstrap and the deployment where the deployers are added once the server/lib/*.jars classloader is constructed. anonymous wrote : | Where we really want to get to is hot deployment of deployers | which is an issue that I'll deal with on a different thread. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972643#3972643 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972643

19 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972638#3972638 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972638

19 years, 6 months

1
0
0 / 0

[Design of JBoss Collaboration Server] - New timeline for Collaboration server release

by paulkneeland

Is there an updated timeline for the release of JBMS 1.0 final. It has been sitting at milestone 5 for some time and still states June 2006 as the release date. Obviously that date has been pushed. Is there an updated timeline or are there certain needs that are not being met to help get to a final release? What areas can an external developer like myself get involved in to help bring about the final release? Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972637#3972637 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972637

19 years, 6 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972635#3972635 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972635

19 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"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. | Ignore the deployment context. That is just the current iteration's version of the DeploymentInfo. Basically a big horrible map of metadata and state about the deployment. What we are really dealing with is: * managed objects - either predetermined using our metadata formats or the unparsed xml and annotations * structure - where to look for unparsed metadata and what makes up the classpath * transient state - used during the deployment In the full solution, the management component of the profile service should be able to say something like: "change the pool size of this datasource" and it is the MainDeployer's job to say (based on the meta annotations), I can do that (with the help of the relevant deployer) without going through a redeploy. It can't do that with the current MainDeployer api and DeploymentContext. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972634#3972634 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972634

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by scott.stark＠jboss.org

But what really needs to be hotdeployable is the deployment component, not the deployers. We do need to refactor the deployers to support this. Whether or not a deployer supports hot deployment is a function of its current implementation state. The only problem I have with statically defining deployers in the kernel bootstrap descriptor is not being able to refresh deployers. I view this as an issue with bootstrap class loader capabilities. The main issue is we need to get the deployer changes in trunk to get jboss5 moving, and the current suggestion to support full hotdeployment of deployers is a big wrench in this effort. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972629#3972629 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972629

19 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : First, I'm not in agreement that hot deployment of deployers is needed. The only post bootstrap configuration I can see are aspects on the deployers themselves, but this can be a function of an individual deployment, not neccessarily a reconfiguration of the deployer. | I'm not sure I understand this. What we are talking about will end up in the full solution as a profile that looks like: * kernel/profile/bootstrap This will be semi-hardwired and represents a minimal set of features to get the thing working (not what we have now). * core configuration These will be plugins, to the above, that need to be done early. Of course ideally we want as much as possible to be done through deployers. Thing that fall into this category: aop-mc-int profile plugins, e.g. JBoss ON integration legacy jmx kernel core logging (user configurable like conf/log4j.xml) * deployers A set of deployer packages that plugin to the main deployer/profile. * the deployments A fixed list, scanner based, something else or a mixture. 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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972628#3972628 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972628

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | Having something that is closer to JBoss4 as an incremental step | is probably going to help us get things done faster? | It's certainly going to get us to a working server faster than waiting for all deployers to meet the ideal. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972619#3972619 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972619

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Deployers and classloading - stumbling block

by adrian＠jboss.org

That's fine as long as the deployers are playing by the rules and are self-contained or semi-self-contained (only reference other deployers metadata). If they reference the runtime then you are going to leak everything into the bootstrap classloaders. Once one gets in there, the rest will follow like dominos. The ideal should be to have two packages: 1) That is the deployer and its metadata, e.g. the WebDeployer 2) That is the runtime implementation e.g. web deployment and server i.e. The deployer parses the metadata and creates a ServiceMetaData or BeanMetaData with only string references to the runtime classes In practice, our implementations are a long way from this currently. Having something that is closer to JBoss4 as an incremental step is probably going to help us get things done faster? I think some form of hotdeployment of deployers is going to be done at some stage anyway. e.g. to support people playing with profiles where the results are more dynamic than a full reboot. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972618#3972618 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972618

19 years, 6 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Deploying MC 2.0 snapshot in JBoss 4.0x

by kabir.khan＠jboss.com

My problem is that a paying customer has been waiting for an AOP 2.0 alpha for ages and the new tight integration with the container project is holding things up. I will look at making including the container specific stuff in AOP a configuration option so that the alpha release can work in JBoss 4.0 as-is (with no need to update the jboss-beans.deployer) and also work in JBoss 5 with the MC. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3972616#3972616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3972616

19 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums September 2006