[JBoss Microcontainer] New message: "Re: VDF doesn't do component composition"
by Adrian Brock
User development,
A new message was posted in the thread "VDF doesn't do component composition":
http://community.jboss.org/message/519411#519411
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
You've missed one of design assumptions of components.
The original idea of components is that they are 1-1 mapping with the ControllerContexts inside the MC.
There are a number of places that use that assumption, i.e. that the component unit's name is the same as what the ControllerContext is
going to be.
The two most obvious ones are:
1) get*Scope() and get*MetaData()
which will return the same MDR context that will be used by the MC for that instance.
Of course in your example you are using the BeanMetaDataBuilder.addAnnotation() so the fact that your
deployment component has a different ScopeKey and hence a different MDR context to what the MC will use is a hidden problem,
you don't use it in the deployment layer - but somebody else might?
You could in fact fix this with a setScope() call, but you couldn't if there was more than one bean instance in the component.
2) IncompleteDeploymentException (IDE)
In order for the IDE to print out what dependencies are missing for a deployment, it needs to know the ControllerContext names.
It does this by collecting the Component DeploymentUnit's names in Component Deployers that specify this, e.g. BeanMetaDataDeployer
or see setUseUnitName() in AbstractRealDeployer.
I guess this could be changed such that instead of setUseUnitName(), the BeanMetaDataDeployer could directly invoke
DeploymentUnit.addControllerContextName() using the ControllerContext.getName() it just created.
There could be other places that use this assumption?
CONCLUSION
You can see from the above, that the assumption could be removed and you get what you want.
But it would only apply to a limited number of cases. e.g. where your component doesn't already have a BeanMetaData attachment.
If two independent people wanted to augment a component with different BeanMetaDatas there's simply no way of doing that without
stepping on each other toes.
So creating a new component makes more sense, if you don't want strange things to happen when users write their own deployers that
try to do similar things - especially if they copy your deployer as an example. :-)
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519411#519411
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Adrian Brock
User development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519398#519398
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
I think Carlo has a better understanding of what Bill is talking about - terminology problem again. :-)
He is talking about Components rather than SubDeployments.
But that doesn't sound like the right thing to order after?
Ordering after the ComponentDeployer for EJBs would work since it controls the ordering in which the deployers are invoked
(for the whole deployment - parent/child/components).
It's only the mandatory input - setInput() or passed to the constructor - that decides whether to ignore your deployer if it doesn't have it.
The problem with ordering after the ComponentDeployer would be that it is very late. It is when you start doing stuff to the runtime.
Typically you want to get your metadata all sorted out before that, otherwise different parts of the runtime would see different config.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519398#519398
16 years, 3 months
[JBoss Web Services] New message: "Re: Failures in some of the Jboss WS test cases"
by Greg Swanson
User development,
A new message was posted in the thread "Failures in some of the Jboss WS test cases":
http://community.jboss.org/message/519397#519397
Author : Greg Swanson
Profile : http://community.jboss.org/people/swag01
Message:
--------------------------------------------------------------
Further investigation in the logs gives me this error:
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(56)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-swaref'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(6)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-samples-retail'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(12)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-samples-context'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(16)-127.0.0.1) Unable to process deployment descriptor for context '/earejb3'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(18)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-samples-exception'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(28)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-samples-jaxbintros'
WARNING [javax.enterprise.resource.webcontainer.jsf.config] (RMI TCP Connection(48)-127.0.0.1) Unable to process deployment descriptor for context '/jaxws-securityDomain'
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519397#519397
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Ales Justin
User development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519395#519395
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
I think we have a misunderstanding here. :-)
Bill is asking about EjbMetaData, where Carlo is already talking about its components - JBossEnterpriseBeanMetaData.
As I don't understand what exactly are you interested in, I'll answer in a more generic way.
By default we handle parent deployments first.
But there is a flag that you can set on the deployer to handle children first.
By simply stating inputs you only affect the order. There are required inputs which also affect the actual usage of the deployer.
I know we should handle ejbs in .wars, but I have no clue on how we actually do that. Carlo?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519395#519395
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Deployer ordering issue for EJB/JAX-RS/WAR?"
by Adrian Brock
User development,
A new message was posted in the thread "Deployer ordering issue for EJB/JAX-RS/WAR?":
http://community.jboss.org/message/519394#519394
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
> mailto:bill.burke@jboss.com wrote:
>
> JAX-RS needs to scan for EJBs within a WAR that might expose JAX-RS endpoints. Right now, EJBs are in the same DU as the WAR. The question I have is, what happens when EJBs become a child DU of the WAR? I need to scan EJB metadata and then, if it has JAX-RS metadata, modify JBossWebMetaData.
>
> Are DUs deployed inner-most first?
Why would the EJBs be in a child DU? WARs don't have child DUs. See WARStructure.
WEB-INF/lib/*.jar are not subdeployments they are just part of the WAR's classpath.
To answer your last quest (probably redundant?), you can decide what order the DUs are passed to your deployer, see
Deployer::isParentFirst() which returns true by default from AbstractDeployer.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519394#519394
16 years, 3 months
[JBoss Messaging] New message: "Problem: JBoss Messaging XA Recovery Configuration"
by Rene Felder
User development,
A new message was posted in the thread "Problem: JBoss Messaging XA Recovery Configuration":
http://community.jboss.org/message/519392#519392
Author : Rene Felder
Profile : http://community.jboss.org/people/FelderR
Message:
--------------------------------------------------------------
The Problem is that the XARecoveryModule tries to start recovering although the Messaging Factories are not yet set up. The ConnectionFactory is set up 3 seconds after the errors occur.
2010-01-11 19:05:40,707 DEBUG [org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper] (main) Server[1].ConnFactoryJNDIMapper registering connection factory 'jboss.messaging.connectionfactory:service=ClusteredConnectionFactory', bindings: /ClusteredConnectionFactory, /ClusteredXAConnectionFactory, java:/ClusteredConnectionFactory, java:/ClusteredXAConnectionFactory
Beside the fact that the documentation is not up to date (as it refers to the wrong file in JBoss 5) it does also not cover the problem with the loading of the modules and how to work around this severe problem in production! Any ideas?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519392#519392
16 years, 3 months
[jBPM] New message: "Re: How to terminate a forked process"
by Jas Lam
User development,
A new message was posted in the thread "How to terminate a forked process":
http://community.jboss.org/message/519387#519387
Author : Jas Lam
Profile : http://community.jboss.org/people/lamj1
Message:
--------------------------------------------------------------
These two files below are also attached
*Summarize Objective:*
1) Terminate a parent process that has forked child processes while it is still active
2) Ensure all child execution are also gracefully ended.
3) Any related tasks, and all executions are cleared out from JBPM4_TASK and JPBM4_EXECUTION tables
*JPDL*
<?xml version="1.0" encoding="UTF-8"?>
<process name="ForkProcess" xmlns="http://jbpm.org/4.0/jpdl">
<start g="22,69,80,40">
<transition to="fork"/>
</start>
<fork g="99,68,80,40" name="fork">
<on continue="exclusive" event="end"/>
<transition g="123,45:" to="Processing"/>
<transition g="124,163:" to="PublishDocument"/>
</fork>
<task assignee="testUser" g="215,18,121,58" name="Processing">
<transition g="440,105:-54,-53" name="to join" to="join"/>
</task>
<state g="204,138,121,58" name="PublishDocument">
<transition g="373,162:-53,-21" name="to join" to="join"/>
</state>
<join g="443,124,80,40" name="join">
<transition to="wait"/>
</join>
<state g="575,137,80,40" name="wait">
<transition to="end"/>
</state>
<end g="725,131,48,48" name="end"/>
</process>
*UnitTest code*
package test.ssoa.jbpm.manager;
import org.jbpm.api.Execution;
import org.jbpm.api.ProcessInstance;
import org.jbpm.pvm.internal.model.ExecutionImpl;
import org.jbpm.test.JbpmTestCase;
public class ForkTest extends JbpmTestCase {
protected String deploymentFork;
protected void setUp() throws Exception {
super.setUp();
//add user to database
identityService.createUser("testUser", "testUser", "testUser", "testUser(a)test.com");
deploymentFork = repositoryService.createDeployment()
.addResourceFromClasspath("test/ssoa/jbpm/manager/ForkProcess.jpdl.xml").deploy();
}
protected void tearDown() throws Exception {
//workflowManager.endAll();
identityService.deleteUser("testUser");
repositoryService.deleteDeploymentCascade(deploymentFork);
super.tearDown();
}
public void testForking()
{
ProcessInstance processInstance = executionService.startProcessInstanceByKey("ForkSubProcess");
String pid = processInstance.getId();
Execution mainExe = executionService.findExecutionById(pid);
((ExecutionImpl)mainExe).end(); //exception here
}
}
Error trace
16:31:14,453 SEV | [BaseJbpmTestCase]
### EXCEPTION ###########################################
16:31:14,454 SEV | [BaseJbpmTestCase] TEST THROWS EXCEPTION: no environment to get org.jbpm.pvm.internal.session.RepositorySession
org.jbpm.api.JbpmException: no environment to get org.jbpm.pvm.internal.session.RepositorySession
at org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:197)
at org.jbpm.pvm.internal.env.EnvironmentImpl.getFromCurrent(EnvironmentImpl.java:190)
at org.jbpm.pvm.internal.model.ExecutionImpl.getProcessDefinition(ExecutionImpl.java:1120)
at org.jbpm.pvm.internal.model.ExecutionImpl.end(ExecutionImpl.java:373)
at org.jbpm.pvm.internal.model.ExecutionImpl.end(ExecutionImpl.java:325)
at test.ssoa.jbpm.manager.ForkTest.testForking(ForkTest.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at junit.framework.TestCase.runTest(TestCase.java:164)
at org.jbpm.test.BaseJbpmTestCase.runTest(BaseJbpmTestCase.java:80)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
### EXCEPTION ###########################################
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/519387#519387
16 years, 3 months