[EJB 3.0 Development] New message: "Source Location for EJB3 Components"
by Andrew Rubinger
User development,
A new message was posted in the thread "Source Location for EJB3 Components":
http://community.jboss.org/message/520181#520181
Author : Andrew Rubinger
Profile : http://community.jboss.org/people/ALRubinger
Message:
--------------------------------------------------------------
Persuant to discussions Carlo, Jaikiran and I have been having lately, I've extracted the component charged with bringing @Asynchronous support to EJB into its own space:
http://anonsvn.jboss.org/repos/jbossas/projects/ejb3/components/
Under this alignment "org.jboss.ejb3.async" is a component with "spi", "build", and "impl" *modules*. Each module shares a release cycle with the component as a whole.
Criteria:
1) Each component has an SPI upon which other components can depend
2) In compile scope, no component may depend on anything aside from the designated SPI. In runtime/test scope the doors are open to use impl classes (I *really* wish Maven provided a scope for "test runtime only, but not test compilation".
How do we feel about using this setup as a template for further breaking apart EJB3 pieces under trunk?
S,
ALR
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520181#520181
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Activating OnDemand beans from child controller"
by Kabir Khan
User development,
A new message was posted in the thread "Activating OnDemand beans from child controller":
http://community.jboss.org/message/520168#520168
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
The messages you added to avoid the errors shown in the dev list post now get triggered for contexts that have been uninstalled. As you can see I modified them a bit. If I have an OnDemand bean called Bean1 and Bean2 and Bean3 depend on it, then if I
-uninstall Bean2
-when uninstalling Bean3 I get an error message when checking Bean3's dependencies. It finds Bean1 and then checks Bean1's DependsOnMe. The message I get is "Could not find reverse dependency 'Name2' while uninstalling on demand contexts for AbstractDependencyItem@6c3c9c31{name=Name3 dependsOn=Name1 whenRequired=Configured resolved=true}"
protected void uninstallUnusedOnDemandContexts(ControllerContext context, boolean trace)
{
lockWrite();
try
{
DependencyInfo dependencies = context.getDependencyInfo();
if (dependencies != null)
{
Set<DependencyItem> iDependOn = dependencies.getIDependOn(null);
if (iDependOn.isEmpty() == false)
{
for (DependencyItem item : iDependOn)
{
if (item.isResolved()) //TODO Is this check necessary
{
Object name = item.getIDependOn();
if (name == null)
continue;
ControllerContext other = getContext(name, null);
if (other == null)
{
log.warn("Could not find dependency '" + name + "' while uninstalling on demand contexts for " + item);
continue;
}
if (other.getMode() != ControllerMode.ON_DEMAND)
continue;
DependencyInfo otherDependencies = other.getDependencyInfo();
if (otherDependencies == null)
continue;
Set<DependencyItem> dependsOnOther = otherDependencies.getDependsOnMe(null);
boolean isRequired = false;
for (DependencyItem dependsOnOtherItem : dependsOnOther)
{
ControllerContext dependsContext = getContext(dependsOnOtherItem.getName(), null);
if (dependsContext == null)
{
log.warn("Could not find reverse dependency '" + dependsOnOtherItem.getName() + "' while uninstalling on demand contexts for " + item);
continue;
}
ControllerState requiredState = item.getWhenRequired();
ControllerState actualState = dependsContext.getState();
if (requiredState.equals(actualState) || stateModel.isBeforeState(requiredState, actualState))
{
isRequired = true;
break;
}
}
if (!isRequired)
{
//For some reason uninstallContext() uninstalls to the state below the passed in one, add one
ControllerState state = stateModel.getNextState(ControllerMode.ON_DEMAND.getRequiredState());
uninstallContext(other, state, trace);
}
}
}
}
}
}
finally
{
unlockWrite();
}
}
This simple test shows that DependsOnMe never gets cleared:
public class DependsOnMeTestCase extends AbstractDependencyTest
{
public DependsOnMeTestCase(String name)
{
super(name);
}
public void testDependsOnMeCorrectOrder() throws Throwable
{
ControllerContext context1 = assertInstall(getDelegate1());
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEmpty(context1.getDependencyInfo().getDependsOnMe(null));
ControllerContext context2 = assertInstall(getDelegate2());
assertEmpty(context2.getDependencyInfo().getDependsOnMe(null));
assertEquals(1, context2.getDependencyInfo().getIDependOn(null).size());
assertEquals("Name1", context2.getDependencyInfo().getIDependOn(null).iterator().next().getIDependOn());
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEquals(1, context1.getDependencyInfo().getDependsOnMe(null).size());
assertEquals("Name1", context1.getDependencyInfo().getDependsOnMe(null).iterator().next().getIDependOn());
}
public void testDependsOnMeWrongOrder() throws Throwable
{
ControllerContext context2 = assertInstall(getDelegate2(), ControllerState.PRE_INSTALL);
assertEmpty(context2.getDependencyInfo().getDependsOnMe(null));
assertEquals(1, context2.getDependencyInfo().getIDependOn(null).size());
assertEquals("Name1", context2.getDependencyInfo().getIDependOn(null).iterator().next().getIDependOn());
ControllerContext context1 = assertInstall(getDelegate1());
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEquals(1, context1.getDependencyInfo().getDependsOnMe(null).size());
assertEquals("Name1", context1.getDependencyInfo().getDependsOnMe(null).iterator().next().getIDependOn());
assertEmpty(context2.getDependencyInfo().getDependsOnMe(null));
assertEquals(1, context2.getDependencyInfo().getIDependOn(null).size());
assertEquals("Name1", context2.getDependencyInfo().getIDependOn(null).iterator().next().getIDependOn());
}
public void testDependsOnMeUninstallRightOrder() throws Throwable
{
ControllerContext context1 = assertInstall(getDelegate1());
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEmpty(context1.getDependencyInfo().getDependsOnMe(null));
ControllerContext context2 = assertInstall(getDelegate2());
assertEmpty(context2.getDependencyInfo().getDependsOnMe(null));
assertEquals(1, context2.getDependencyInfo().getIDependOn(null).size());
assertEquals("Name1", context2.getDependencyInfo().getIDependOn(null).iterator().next().getIDependOn());
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEquals(1, context1.getDependencyInfo().getDependsOnMe(null).size());
assertEquals("Name1", context1.getDependencyInfo().getDependsOnMe(null).iterator().next().getIDependOn());
assertUninstall(context2);
assertEmpty(context2.getDependencyInfo().getDependsOnMe(null));
assertEquals(1, context2.getDependencyInfo().getIDependOn(null).size());
assertEquals("Name1", context2.getDependencyInfo().getIDependOn(null).iterator().next().getIDependOn());
context1 = assertContext("Name1", ControllerState.INSTALLED);
assertEmpty(context1.getDependencyInfo().getIDependOn(null));
assertEmpty(context1.getDependencyInfo().getDependsOnMe(null)); // FAILS - dependsOnMe still contains Name2
}
protected TestDelegate getDelegate1()
{
return new TestDelegate("Name1");
}
protected TestDelegate getDelegate2()
{
TestDelegate result = new TestDelegate("Name2");
result.addDependency(new AbstractDependencyItem("Name2", "Name1", ControllerState.DESCRIBED, ControllerState.INSTALLED));
return result;
}
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520168#520168
16 years, 3 months
[jBPM] New message: "Re: TaskService issue"
by Santanu Saraswati
User development,
A new message was posted in the thread "TaskService issue":
http://community.jboss.org/message/520165#520165
Author : Santanu Saraswati
Profile : http://community.jboss.org/people/saraswati.santanu
Message:
--------------------------------------------------------------
Its not the responsibility of JBPM to manage connections. It must be hibernate which is opening the connection.
You need to explicitly close a connection if you are not using transaction manager, otherwise transaction manager pretty much does it for you.
If you are using a transaction manager then you might need to check why this particular task service call is executed outside a transaction.
If you are developing a JEE app and not using a transaction manager, then... best of luck
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520165#520165
16 years, 3 months
[JBoss Tools] New message: "Duplicate component name validation error"
by David Hibbs
User development,
A new message was posted in the thread "Duplicate component name validation error":
http://community.jboss.org/message/520156#520156
Author : David Hibbs
Profile : http://community.jboss.org/people/sage.sam
Message:
--------------------------------------------------------------
This looks like a bug to me, but thought I should post it.
I'm working from the Seam In Action examples, but now with SEAM 2.2 and tools 3.1 CR1.
RegisterAction uses some additional configuration from components.xml, defined by a component element without a class specified i.e.;
<component name="registerAction">
<property name="pro-status-types">amateur pro semi-pro</property>
<property name="specialtyTypes">
<value>#{messages['specialty.drive']}</value>
<value>#{messages['specialty.chip']}</value>
<value>#{messages['specialty.putt']}</value>
<value>#{messages['specialty.iron']}</value>
<value>#{messages['specialty.looks']}</value>
</property>
</component>
The RegisterAction java source is annotated with an @Name header:
package org.open18.action;
...
@Name("registerAction")
public class RegisterAction {
During project build, and validation, these both get flagged as "Duplicate component name: "registerAction".
This does not prevent the project from building or deploying to JBoss AS 5.1, which in fact operates correctly. The validation simply flags it as an error.
This same validation works properly in Seam 2.1 and tools 3.0.1.GA-R2.
I updated to the latest nightly build (JBossTools-Update-3.1.0.v201001140301N-H131-CR2.zip) and the problem still exists.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520156#520156
16 years, 3 months
[JBoss Messaging] New message: "Re: Slow dequeue for singleton MDB"
by Adrian Brock
User development,
A new message was posted in the thread "Slow dequeue for singleton MDB":
http://community.jboss.org/message/520147#520147
Author : Adrian Brock
Profile : http://community.jboss.org/people/adrian@jboss.org
Message:
--------------------------------------------------------------
This isn't really a JBoss Messaging question, if you're using Tibco EMS.
Anyway, the short answer is that we can't really answer your question, you'll have to ask Tibco.
The longer answer is that the delivery and prefetching of messages to an MDB is controlled by the ConnectionConsumer
which is implemented by Tibco (which is why only they can answer the question).
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/ConnectionConsumer.html
The only thing we control is the ServerSessionPool which you've set to one Session if you
are using a Singleton MDB.
Their ConnectionConsumer will have some code that does something like the following:
while (notClosed)
{
Message m = getNextMessageFromServer(); // A
ServerSession s = jbossServerSessionPool.getServerSession(); // B
addMessageToSession(s, m);
s.start(); // C
}
Now at point (C) above we offload the work to a different thread so it ought to be able to get the next message from (A)
while it is processing the previous message.
But until that previous message completes, point (B) will block - that is the purpose of the singleton - no concurrent invocation.
Once the previous work has finished, point (B) will unblock and it should immediately process the next message.
Whether that is true, depends upon how Tibco implement the above method. e.g. if they have (A) and (B) the other way around, it
isn't going to get the next message until a session is available, which means you will see a latency.
NOTE: You can't just time your MDB's onMessage() method. There's work than that (assuming you are using JTA transactions).
We wrap your onMessage() method with something like:
Transasction tx = startTransaction();
tx.enlistResource(tibcoXAResource);
try
{
yourMDB.onMessage(message);
}
finally
{
tx.commit/rollback();
}
If you are doing work in a database in your MDB, the commit() at the end will have to do a 2 phase commit,
one branch for the DB and for one the Tibco message acknowledgement.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/520147#520147
16 years, 3 months