October 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: DeploymentContext needs attachments

by adrian＠jboss.org

Can't you add that to the deployment context of the war? i.e. if (moduleTypeIsWar) { DeploymentContext warDeploymentContext = ... if (contextRoot != null) { ContextRootMetaData crmd = ... warDeploymentContext.addTransientManagementObjects().addAttachment(crmd); } earDeploymentContext.addChild(warDeploymentContext); } Then it is just a case of getting the war deployer to check it. It must already check it now from the DeploymentInfo in JBoss4? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977295#3977295 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977295

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: DeploymentContext needs attachments

by bill.burke＠jboss.com

anonymous wrote : Has there been any thought around how the EAR deployer (structure or whatever) passes metadata to subdeployments? i.e. context-root? I can figure something out, but it would be cool to have input. I guess the way it would work would be add a WarEarIntegrationDeployer? 1. WarParsingDeployer runs first 2. WarEarIntegrationDeployer looks at deployment structure and modifies context-root metadata deployed by WarParsingDeployer. (same with other metadata). Sound right? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977292#3977292 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977292

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - DeploymentContext needs attachments

by bill.burke＠jboss.com

In the EAR deployer, I'm finding that a DeploymentContext needs attachment. Why? * So that I don't have to parse application.xml twice * So that I can associate EAR module metadata to the DeploymentContext. Has there been any thought around how the EAR deployer (structure or whatever) passes metadata to subdeployments? i.e. context-root? I can figure something out, but it would be cool to have input. Thanks View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977289#3977289 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977289

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by timfox

Another thing we could do is to provide duplicate message detection only for the lifetime of a particular session. The user could create a session with a special parameter, and then the server would ensure no duplicates were sent by consulting a cache of ids in memory. Since it's in memory no persistence would be required, basically it would just be an extra hashmap lookup. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977286#3977286 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977286

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Ordering of nested deployments

by adrian＠jboss.org

The ordering is determined by the getRelativeOrder() defined on the Deployer interface. If you extend the standard deployer, e.g. AbstractParsingDeployer you get a default ordering based on the type which are defined on the interface: | public interface Deployer | { | /** The parser order */ | public static final int PARSER_DEPLOYER = 2000; | | /** The class loader order */ | public static final int CLASSLOADER_DEPLOYER = 4000; | | /** The component order */ | public static final int COMPONENT_DEPLOYER = 4000; | | /** The real order */ | public static final int REAL_DEPLOYER = 10000; | Feel free to add new ones, e.g. AspectManager population something like? | /** The preprocess classloader order */ | public static final int PREPROCESS_CLASSLOADING_DEPLOYER = 3900; | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977284#3977284 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977284

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by timfox

"adrian(a)jboss.org" wrote : | Also, this is an additional overhead for people that deliberately | didn't select this QoS because they don't need it.. As I mentioned earlier in the thread, this would be off by default. It would certainly be madness to have this as the default behaviour :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977281#3977281 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977281

19 years, 6 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Once and only once delivery?

by adrian＠jboss.org

"timfox" wrote : | I think this is less intensive than tx logging since we only have to log the id rather than the entire tx state, also we don't have the extra client->server call for the prepare. | Are you sure? Writing a custom garbage collector sounds a lot more complicated than using an already written and optimized transaction log in the transaction manager. Also, this is an additional overhead for people that deliberately didn't select this QoS because they don't need it. e.g. The body of the message already contains a unique id that they need to check anyway because of the potential of a redelivery after a failure. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977279#3977279 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977279

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Ordering of nested deployments

by kabir.khan＠jboss.com

Aaaah, that actually makes a lot of sense now - thanks guys :-) If I have understood correctly the ordering of the aspect deployers is what is important. I need to make the AOP deployer be one of the first aspect deployers in the chain. Is there a way to configure the order of the aspect deployers in the MainDeployer? I need the AOP metadata to be deployed before it attempts to load any of the classes, but it should happen after any classloaders have been created since that information is used for AOP scoped by classloader. The easiest way to achieve this would be to hardocde the aspect stuff into the conf/deployer-beans.xml, but I am not sure if this is the way to go? I've commited a first packaging of the AOP deployer (without annotation support). For now I have put the AOP jars in the lib/ directory, the aspect-deployer-beans.xml in the deployers/ directory and the base-aop.xml in the conf/ directory. I was going to keep the jboss-aop-jdk50.deployer, but doing it that way meant that the ejb3-interceptors-aop.xml file was not getting deployed since that got deployed before the AOP deployer itself (there is a TODO in MainDeployerImpl to process existing deployments) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977277#3977277 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977277

19 years, 6 months

1
0
0 / 0

[Design of JBossXB] - Re: SundayContentHandler: Don't add collections into collect

by alex.loubyansky＠jboss.com

Ok, thanks for the info. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977276#3977276 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977276

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - Re: Ordering of nested deployments

by bill.burke＠jboss.com

Kabir, Conceptually, I had a lot of the same questions and issues that you are raising until I got used to the idea of breaking up a single deployer into multiple deployers that handle their specific narrowed task. It actually turns out to be much much cleaner. Bill View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977263#3977263 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977263

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 October 2006