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

[Design of POJO Server] - MetaData hierarchy, a problem with annotations

by adrian＠jboss.org

I found a problem with using annotations in a hierarchy (or any "collection" metadata for that matter). Let's suppose you have an EJB annotated with @Resources(@Resource(name="jms/Queue", type=Queue.class mappedName="queue/SomeQueue"); Then at the deployment level you've specified your datasource: @Resources(@Resource(name="jdbc/DataSoure", type=DataSource.class mappedName="java:/DefaultDS"); Then the EJB (class level) annotation hides the deployment level annotation. Resources resources = MetaData.getAnnotation(Resources.class); What is really required is for this data to merged. But obviously, it is only these collection type annotations that should be merged to get the final result. And even then not all of them. e.g. a hypothetical @Descriptions annotation on the deployment and an ejb's resource ref should not be merged. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977319#3977319 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977319

19 years, 6 months

1
0
0 / 0

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

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : Can't you add that to the deployment context of the war? | | i.e. | | | if (moduleTypeIsWar) | | { | | DeploymentContext warDeploymentContext = ... | | if (contextRoot != null) | | { | | ContextRootMetaData crmd = ... | | warDeploymentContext.getTransientManagementObjects().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? Currently the war deployer looks to the DeploymentInfo.webContext for an ear level override. while the web context-root could be pushed to the associated war context, other info like security roles apply to every component, and potentially needs to be merged. Same situation exists for standardjboss.xml/jboss.xml. To me this is getting more to needing the metadata repository to be able to access scope based overrides. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977318#3977318 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977318

19 years, 6 months

1
0
0 / 0

[Design of POJO Server] - To merge or not to merge?

by adrian＠jboss.org

I've been thinking about this merging of metadata between ejb-jar.xml and jboss.xml and I'm not sure we actually want to do this? The main reason is that doing so, loses the information on where the metadata came from. 1) You cannot take the metadata and turn it back into the xml files. 2) You don't know where to direct the user about where to fix something A simple example is jndi-name in jboss.xml which now has a corresponding mapped-name in ejb-jar.xml for EJB3 Making these the same property would lose which file it came from. Given that I want to extend jboss.xml so you can override "everything" this doesn't look like a good solution. A better solution would be to make it delegate, like the following pseudo code. | class DelegateBeanMetaData | { | String getJndiName() | { | String result = jbossXML.getJndiName(); | if (result == null) | return ejbJarXML.getMappedName(); | } | } | In fact, with the org.jboss.metaData stuff it would be trivial to implement this provided the metadata is split up enough. You just need two MetaDataContexts one for jboss.xml and one for ejb-jar.xml Then the query becomes: JndiBinding binding = MetaData.getMetaData(JndiBinding.class); View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977313#3977313 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977313

19 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

The component deployers split up a deployment into components so the real deployers are easier to write (they just deal with one component). It should probably be around 7000 e.g. -serivce.xml (ServiceDeploymentMetaData) is split into mbeans (ServiceMetaData) -beans.xml (KernelDeployment) is split into pojos (BeanMetaData) etc. Also other deployers can target your real deployer at the atomic level. e.g. the RARDeployer creates a ServiceMetaData (mbean for the rar) without having to go through the full ServiceDeployment stuff. I'd imagine you could do something similar with AOP if you had a custom deployer that wanted to create a simple aspect not the full -aop.xml It makes it possible to write simple deployers that can do things at the most atomic level with the metadata without having to understand how to iterate. Finally, it makes the real deployers less error prone since the MainDeployer knows how to correctly unwind a failed deployment if one of the components fails. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977309#3977309 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977309

19 years, 6 months

1
0
0 / 0

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

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : Ok, thanks. | | Why do CLASSLOADER_DEPLOYER and COMPONENT_DEPLOYER have the same value? I need something greater than 4000 since I need the classloader to have been created, but I am not sure what the component deployers do? | I didn't notice. It's obviously wrong and a cut and paster error. :-) Should anything apart from the real deployers actually instantiate deployment classes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977306#3977306 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977306

19 years, 6 months

1
0
0 / 0

[Design of JBossCache] - Issues with shunned node rejoining a cluster

by bstansberry＠jboss.com

Discussion of conceptual/design issues related to dealing with shunned nodes rejoining a cluster. A fundamental thing to understand is that when your channel is shunned and disconnects, you don't get a new view. Experiments with HAPartition showed me that. You do get one when it reconnects. So, any features whose design depends on gettting views may break. Mainly the issue is to think through the implications of that. Some initial thoughts: 1) While you're disconnected you can't properly replicate. What's the proper behavior -- hold calls in ReplicationInterceptor until you reconnect, which will happen automatically? Or throw exceptions when you try to send messages on the channel (which I'd expect is what happens now)? If the latter, it becomes important to have a way to communicate to the application that the cache is disconnected, so the application can decide whether or not to hold calls. 2) When the new view comes in after reconnect, does the node need to reassign it's buddy and transfer state? During the period of broken communication leading up to the shunning, the buddy probably wasn't getting replication traffic. If REPL_ASYNC, the sender would not know this. If we do need to reassign buddies, when the new view comes in will the BR code recognize it needs to do this? 3) The channel is always AUTO_GET_STATE. So, when it reconnects getState() will be called on the coordinator and setState() will be called on the node. This is inappropriate in many configurations; basically most of those that don't do an initial state transfer. See http://jira.jboss.com/jira/browse/JBCACHE-805. If it is appropriate, do we handle it properly? 3) Non-BR case with region-based marshalling. We definitely don't want a single monolithic state transfer; won't be able to deserialize it. But, we do need to re-transfer the state, as we're now out of sync with the cache. Right now we don't do this. A lot of similar issues apply in the merge case. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977305#3977305 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977305

19 years, 6 months

1
0
0 / 0

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

by bill.burke＠jboss.com

whoops, sorry... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977302#3977302 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977302

19 years, 6 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: MessageService and JMS

by mteira

Hello. 1.-I've found the problem with JSF and jbpm.ear. It was my fault (once again). It seems that the cause was that, perhaps for not running the clean target, the ear customizedwar lib directory was holding both a Sun JSF implementation and a MyFaces apache one. I suppose that the implementation was switched in some moment, and I didn't clean up my target directory as frequently as I should. BTW, deploying the jbpm-console.war and the jbpm.ear (with the 'web' node commented out) at the same time was not a valid workaround, as I run into problems with the ehcache (it looked like an NPE trying to create a second CacheManager). 2.-Before trying to setup a working cactus environment, I just wanted to create an standalone JMS client and just send a message to the JbpmCommandQueue to see how it works. I run into some problems with the MDB CommandListener trying to locate the CommandService Session Bean. I patched as: ### Eclipse Workspace Patch 1.0 | #P jbpm | Index: enterprise/cmdlistener/src/main/java/org/jbpm/ejb/impl/CommandListenerBean.java | =================================================================== | RCS file: /cvsroot/jbpm/jbpm.3/enterprise/cmdlistener/src/main/java/org/jbpm/ejb/impl/CommandListenerBean.java,v | retrieving revision 1.1 | diff -u -r1.1 CommandListenerBean.java | --- enterprise/cmdlistener/src/main/java/org/jbpm/ejb/impl/CommandListenerBean.java 24 Aug 2006 16:03:45 -0000 1.1 | +++ enterprise/cmdlistener/src/main/java/org/jbpm/ejb/impl/CommandListenerBean.java 10 Oct 2006 16:22:29 -0000 | @@ -70,8 +70,8 @@ | try { | log.debug("looking up local command service"); | Context initial = new InitialContext(); | - Context environment = (Context) initial.lookup("java:comp/env/ejb"); | - LocalCommandServiceHome localCommandServiceHome = (LocalCommandServiceHome) environment.lookup("LocalCommandServiceHome"); | + Context environment = (Context) initial.lookup("java:comp/env"); | + LocalCommandServiceHome localCommandServiceHome = (LocalCommandServiceHome) environment.lookup("ejb/LocalCommandServiceBean"); | LocalCommandService localCommandService = localCommandServiceHome.create(); | try { | // TODO add support for sending back the result | | I'm not running into some problems with hibernate that is not able to locate using JNDI the UserTransaction. I will investigate further, to see if it's caused by a missconfiguration. Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977299#3977299 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977299

19 years, 6 months

1
0
0 / 0

[Design of EJB 3.0] - Need to deploy based on a metamodel

by bill.burke＠jboss.com

We need to change our deployment mechanisms to be focused on an object metamodel rather than a mismash of annotations and a metamodel. The idea of using annotations as a metamodel was interesting but a failure. Why do we need to do this? Well, in JBoss 5, different layers will need to be able to override/modify deployment metadata. For example, EAR metadata may introduce security role mappings or a default security domain. Another reason is that the profile service may want to override and serialize an object model so that a management tool can change metadata at runtime. Once we get the current deployers ported and working for the JBoss 5 model, we need to go back and refactor things. Bill View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977298#3977298 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977298

19 years, 6 months

1
0
0 / 0

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

by kabir.khan＠jboss.com

Ok, thanks. Why do CLASSLOADER_DEPLOYER and COMPONENT_DEPLOYER have the same value? I need something greater than 4000 since I need the classloader to have been created, but I am not sure what the component deployers do? Should anything apart from the real deployers actually instantiate deployment classes? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3977297#3977297 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3977297

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