[JBoss JIRA] Created: (WELDX-74) Support use of decorator of Callable<T>
by Elias Ross (JIRA)
Support use of decorator of Callable<T>
---------------------------------------
Key: WELDX-74
URL: https://jira.jboss.org/jira/browse/WELDX-74
Project: Weld Extensions
Issue Type: Feature Request
Components: Java SE
Reporter: Elias Ross
Decorator exists for Runnable. Should allow for Callable<T> to be used as well.
This is actually pretty useful, for example if you want to execute under a temporary new scope in the same thread, e.g.
@Inject Instance<PaymentProcessor> paymentProcessorSource; // which implements Callable<Result>
Result result = paymentProcessorSource.get().call();
Or, in the case of a thread pool, you can use Future<T> etc.
/**
* Decorator for all beans which implements Callable. It intercepts the call
* to the call() method to set up the ThreadContext for the new thread so that
* instances of @ThreadScoped beans can be correctly resolved.
*/
@Decorator
public class CallableDecorator<T> implements Callable<T> {
@Inject @Delegate Callable<T> callable;
/**
* Set up the ThreadContet and delegate.
*/
public T call()
{
// set up context for this thread
final ThreadContext threadContext = WeldSEBeanRegistrant.THREAD_CONTEXT;
threadContext.setBeanStore(new HashMapBeanStore());
threadContext.setActive(true);
// run the original thread
try {
return callable.call();
} finally {
threadContext.destroy();
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (WELD-832) Remote EJBs can be resolved by name
by Aslak Knutsen (JIRA)
Remote EJBs can be resolved by name
-----------------------------------
Key: WELD-832
URL: https://issues.jboss.org/browse/WELD-832
Project: Weld
Issue Type: Bug
Components: Resolution (Typesafe and by Name)
Affects Versions: 1.1.0.Final
Reporter: Aslak Knutsen
You can lookup Remote EJBs via BeanManager based on name. Remote EJBs should not be registered as Beans.
Failed tests:
runTest(org.opentck.javaee.cdi_ejb.deployments.stateful.remoteview.WarDeployedNamedAccessTest)
runTest(org.opentck.javaee.cdi_ejb.deployments.singleton.remoteview.WarDeployedNamedAccessTest)
runTest(org.opentck.javaee.cdi_ejb.deployments.stateless.remoteview.WarDeployedNamedAccessTest)
tests: https://github.com/opentck/javaee_cdi_ejb
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (WELD-863) Replication of EJB Session Beans does not work in cluster
by Martin Gencur (JIRA)
Replication of EJB Session Beans does not work in cluster
---------------------------------------------------------
Key: WELD-863
URL: https://issues.jboss.org/browse/WELD-863
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.0.Final
Environment: JBossAS 6 SNAPSHOT (from 2011-03-02) - built in hudson
Reporter: Martin Gencur
Assignee: Ales Justin
Fix For: TBC
Attachments: weld-translator.ear
I tested this feature with JSF/Translator example and I needed to do a few changes to test this feature. My fork of weld-core with the changes can be found at: https://github.com/mgencur/core/tree/cluster-test. I'll also attach a packaged ear of the app which I used.
Steps to reproduce the bug:
1) deploy the attached weld-translator.ear file or checkout my changes from github and build the application
2) start first and second instance of the JBossAS to create a cluster (can be found at https://github.com/weld/core/blob/master/examples/README.md)
3) deploy the app
4) go to your web browser and disable cookies
5) go to http://localhost:8080/weld-translator, enter some text and click "Translate"
6) now change the port number in the address to 8180 and refresh (note that there should be also jsessionid included in the URL)
7) now the text you entered into the text area should be still there (since the value is stored in a field of SFSB which is clustered, but instead, you get the following exception at the slave JBossAS instance:
12:00:16,662 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [hz****59+A__]: org.jboss.weld.exceptions.WeldException: WELD-001500 Failed to deserialize proxy object
Note that if you then go to the first address (with port 8080) and then again to 8180 - from now the replication works fine. But IMHO this is not desired behaviour, the second (backup) JBoss instance should be ready immediately
The question is if the changes of the application are the right ones. There is nobody here who could confirm this. Please pay attention to it and comment this issue if it's not correct.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (WELD-1032) Lifecycle stacktrace in the exception message: What's causing is my bean being created too early?
by Geoffrey De Smet (Created) (JIRA)
Lifecycle stacktrace in the exception message: What's causing is my bean being created too early?
-------------------------------------------------------------------------------------------------
Key: WELD-1032
URL: https://issues.jboss.org/browse/WELD-1032
Project: Weld
Issue Type: Feature Request
Reporter: Geoffrey De Smet
When not using (C)DI, you can easily see when a component is created too early by looking at the stacktrace:
{code}
"database username is null"
at ConnectionManager.createConnection()
at DogDao.createInstance()
at DogDao.getInstance()
at PersonDao.createInstance()
at PersonDao.getInstance()
at PersonService.createInstance()
at PersonService.getInstance()
at Main.beforeDatabaseUsernameIsAsked()
{code}
Clearly, beforeDatabaseUsernameIsAsked() has the problem: it shouldn't call PersonService.getInstance().
However, turn this code into (C)DI and you get something like this stacktrace:
{code}
"database username is null"
at ConnectionManager.createConnection()
at java.reflect....
at org.jboss.weld...
at org.jboss.arquillian...
{code}
Now, it's not clear any more that Main.beforeDatabaseUsernameIsAsked() is the problem, isn't it?
There is absolutely no mention of Main.
And then it is a challenge to find out what's causing the lifecycle to behave differently that you expected
and how the lifecycle is actually behaving now.
It would be nice if the exception message contains something like
{code}
"database username is null"
during creation of ConnectionManager
for DogDao
for PersonDao
for PersonService
for Main
at ConnectionManager.createConnection()
....
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] Created: (WELDX-38) ConversationScoped not working on Tomcat
by Fabio Wang (JIRA)
ConversationScoped not working on Tomcat
----------------------------------------
Key: WELDX-38
URL: https://jira.jboss.org/jira/browse/WELDX-38
Project: Weld Extensions
Issue Type: Bug
Components: Servlet Containers
Affects Versions: Servlet Containers 1.0.0.CR1
Environment: Apache Tomcat 6.0.20
Reporter: Fabio Wang
Trying to mark a conversation as long-running causes an exception (java.lang.NoClassDefFoundError: javassist/util/proxy/ProxyObject) when the ServletConversationManager tries to get a proxy for the httpSession.
The ProxyFactory.classLoaderProvider ends up resolving the classloader to an instance of org.apache.catalina.loader.StandardClassLoader (which doesn't know the javassist lib, since it's only in the app classloader).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months