[weld-issues] [JBoss JIRA] Commented: (WELDX-92) Port Weld slf4j extensions to Weld Extensions
[ https://jira.jboss.org/browse/WELDX-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12551430#action_12551430 ] John Ament commented on WELDX-92: - Pete, this is a little misleading. The goal is to have this available for Alpha3, correct? The only goal is to support @Inject (@Category - optional) org.slf4j.Logger logger; right? Port Weld slf4j extensions to Weld Extensions - Key: WELDX-92 URL: https://jira.jboss.org/browse/WELDX-92 Project: Weld Extensions Issue Type: Feature Request Reporter: Pete Muir Fix For: 1.0.0.Alpha3 This will be made redundent by JBoss Logging 3 when available -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Created: (WELD-814) Resources injected to producer fields fail to be produced
Resources injected to producer fields fail to be produced - Key: WELD-814 URL: https://issues.jboss.org/browse/WELD-814 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.CR3 Reporter: John Ament When you inject a resource in to a bean (session, managed, cdi, etc), the producer field that can be bound to it fails to deploy, at least under AS 6. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-814) Resources injected to producer fields fail to be produced
[ https://issues.jboss.org/browse/WELD-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572591#comment-12572591 ] John Ament commented on WELD-814: - Note that this is just one example. We first saw this in the seam jms module starting in CR1 of JBoss AS 6. Resources injected to producer fields fail to be produced - Key: WELD-814 URL: https://issues.jboss.org/browse/WELD-814 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.CR3 Reporter: John Ament When you inject a resource in to a bean (session, managed, cdi, etc), the producer field that can be bound to it fails to deploy, at least under AS 6. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-814) Resources injected to producer fields fail to be produced
[ https://issues.jboss.org/browse/WELD-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12572599#comment-12572599 ] John Ament commented on WELD-814: - Ok, but I'm curious as to why it does allow it from a method producer? Or is it simply a case where the container knows that this is a resource because the field has the injection point, but doesn't know about the method? In which case, another bypass would simply be to define the resource injection point on a setter and leave the producer on the field? Resources injected to producer fields fail to be produced - Key: WELD-814 URL: https://issues.jboss.org/browse/WELD-814 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.CR3 Reporter: John Ament Assignee: Pete Muir When you inject a resource in to a bean (session, managed, cdi, etc), the producer field that can be bound to it fails to deploy, at least under AS 6. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Created: (WELD-850) Event to JMS to Event mapping behavior
Event to JMS to Event mapping behavior
--
Key: WELD-850
URL: https://issues.jboss.org/browse/WELD-850
Project: Weld
Issue Type: Bug
Reporter: John Ament
While working on seam jms, I've noted the following behavior.
java.lang.IllegalStateException: Singleton not set for
BaseClassLoader@3479404a{vfs:///apps/jboss/jboss-6.0.0.Final/server/all/conf/jboss-service.xml}
at
org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59)
[:6.0.0.Final]
at org.jboss.weld.Container.instance(Container.java:58) [:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifierIfAbsent(ResolvableBuilder.java:184)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:464)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:604)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:598)
[:6.0.0.Final]
at
org.jboss.seam.jms.bridge.IngressMessageListener.onMessage(IngressMessageListener.java:45)
at
org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940)
[:6.0.0.Final]
at
org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
[:6.0.0.Final]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_22]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
This exception occurs when trying to fire an event with the contents of a JMS
message. The message listener in this case is instantiated from the portable
extension and receives the bean manager as an argument in the constructor. I
am able to get as far as reading the data from JMS, but when firing the second
event the above exception occurs. I'm not certain that this is a Weld problem,
but it seem slike a good place to start based on the packages shown.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-850) Event to JMS to Event mapping behavior
[
https://issues.jboss.org/browse/WELD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580110#comment-12580110
]
John Ament commented on WELD-850:
-
At least in what's currently in there, all components are in the same class
loader/deployment, so a classloader problem would be a really bizarre one.
Event to JMS to Event mapping behavior
--
Key: WELD-850
URL: https://issues.jboss.org/browse/WELD-850
Project: Weld
Issue Type: Bug
Reporter: John Ament
While working on seam jms, I've noted the following behavior.
java.lang.IllegalStateException: Singleton not set for
BaseClassLoader@3479404a{vfs:///apps/jboss/jboss-6.0.0.Final/server/all/conf/jboss-service.xml}
at
org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59)
[:6.0.0.Final]
at org.jboss.weld.Container.instance(Container.java:58) [:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifierIfAbsent(ResolvableBuilder.java:184)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:464)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:604)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:598)
[:6.0.0.Final]
at
org.jboss.seam.jms.bridge.IngressMessageListener.onMessage(IngressMessageListener.java:45)
at
org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940)
[:6.0.0.Final]
at
org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
[:6.0.0.Final]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_22]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
This exception occurs when trying to fire an event with the contents of a JMS
message. The message listener in this case is instantiated from the portable
extension and receives the bean manager as an argument in the constructor. I
am able to get as far as reading the data from JMS, but when firing the
second event the above exception occurs. I'm not certain that this is a Weld
problem, but it seem slike a good place to start based on the packages shown.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-850) Event to JMS to Event mapping behavior
[
https://issues.jboss.org/browse/WELD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580122#comment-12580122
]
John Ament commented on WELD-850:
-
HornetQ's not embedded in my deployment. It's deployed as a war file. These
are my only libraries:
jboss-logging-3.0.0.Beta4.jar seam-solder-api-3.0.0.Beta1.jar
seam-jms-api-3.0.0-SNAPSHOT.jar slf4j-api-1.5.10.jar
seam-jms-impl-3.0.0-SNAPSHOT.jar
Event to JMS to Event mapping behavior
--
Key: WELD-850
URL: https://issues.jboss.org/browse/WELD-850
Project: Weld
Issue Type: Bug
Reporter: John Ament
While working on seam jms, I've noted the following behavior.
java.lang.IllegalStateException: Singleton not set for
BaseClassLoader@3479404a{vfs:///apps/jboss/jboss-6.0.0.Final/server/all/conf/jboss-service.xml}
at
org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59)
[:6.0.0.Final]
at org.jboss.weld.Container.instance(Container.java:58) [:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifierIfAbsent(ResolvableBuilder.java:184)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:464)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:604)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:598)
[:6.0.0.Final]
at
org.jboss.seam.jms.bridge.IngressMessageListener.onMessage(IngressMessageListener.java:45)
at
org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940)
[:6.0.0.Final]
at
org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
[:6.0.0.Final]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_22]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
This exception occurs when trying to fire an event with the contents of a JMS
message. The message listener in this case is instantiated from the portable
extension and receives the bean manager as an argument in the constructor. I
am able to get as far as reading the data from JMS, but when firing the
second event the above exception occurs. I'm not certain that this is a Weld
problem, but it seem slike a good place to start based on the packages shown.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-850) Event to JMS to Event mapping behavior
[
https://issues.jboss.org/browse/WELD-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580124#comment-12580124
]
John Ament commented on WELD-850:
-
in case it helps, this is the code that creates the listener:
private void createListener(final AfterBeanDiscovery abd, final BeanManager
beanManager, final Route route, ConnectionFactory cf) {
for(Destination d : route.getDestinations()) {
try{
Connection conn = cf.createConnection();
Session session = conn.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageConsumer cons = session.createConsumer(d);
cons.setMessageListener(new IngressMessageListener(beanManager,
route));
conn.start();
} catch (JMSException e) {
log.error(Error creating listener,e);
}
}
}
Event to JMS to Event mapping behavior
--
Key: WELD-850
URL: https://issues.jboss.org/browse/WELD-850
Project: Weld
Issue Type: Bug
Reporter: John Ament
While working on seam jms, I've noted the following behavior.
java.lang.IllegalStateException: Singleton not set for
BaseClassLoader@3479404a{vfs:///apps/jboss/jboss-6.0.0.Final/server/all/conf/jboss-service.xml}
at
org.jboss.weld.integration.provider.JBossSingletonProvider$EarSingleton.get(JBossSingletonProvider.java:59)
[:6.0.0.Final]
at org.jboss.weld.Container.instance(Container.java:58) [:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.checkQualifier(ResolvableBuilder.java:209)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifier(ResolvableBuilder.java:174)
[:6.0.0.Final]
at
org.jboss.weld.resolution.ResolvableBuilder.addQualifierIfAbsent(ResolvableBuilder.java:184)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.resolveObserverMethods(BeanManagerImpl.java:464)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:604)
[:6.0.0.Final]
at
org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:598)
[:6.0.0.Final]
at
org.jboss.seam.jms.bridge.IngressMessageListener.onMessage(IngressMessageListener.java:45)
at
org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:822)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:46)
[:6.0.0.Final]
at
org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:940)
[:6.0.0.Final]
at
org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
[:6.0.0.Final]
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_22]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
This exception occurs when trying to fire an event with the contents of a JMS
message. The message listener in this case is instantiated from the portable
extension and receives the bean manager as an argument in the constructor. I
am able to get as far as reading the data from JMS, but when firing the
second event the above exception occurs. I'm not certain that this is a Weld
problem, but it seem slike a good place to start based on the packages shown.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Created: (WELD-860) Fired events are observed by any match.
Fired events are observed by any match. --- Key: WELD-860 URL: https://issues.jboss.org/browse/WELD-860 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.CR3 Environment: JBoss AS 6, Weld 1.1 CR3 Reporter: John Ament Using the gist as an example code base: https://gist.github.com/843239 One expects that when observes are invoked, they match the exact qualifiers of the injected event, however weld is doing any possible match when choosing observer methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-860) Fired events are observed by any match.
[ https://issues.jboss.org/browse/WELD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584644#comment-12584644 ] John Ament commented on WELD-860: - Documentation impact: the behaviour of this code is in direct contradiction of http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#d0e4045 in the weld guide. Fired events are observed by any match. --- Key: WELD-860 URL: https://issues.jboss.org/browse/WELD-860 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.CR3 Environment: JBoss AS 6, Weld 1.1 CR3 Reporter: John Ament Using the gist as an example code base: https://gist.github.com/843239 One expects that when observes are invoked, they match the exact qualifiers of the injected event, however weld is doing any possible match when choosing observer methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-80) Passivation of stateful session beans results in a loss of reference to injected object
[ https://issues.jboss.org/browse/WELD-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589503#comment-12589503 ] John Ament commented on WELD-80: I'll need to review the test a bit more, but I am able to reproduce this in AS 6. In the ejb3 aop xml file, set the timeout low (the default is 5 minutes, that's enough). Set the session timeout in web.xml high (60 minutes). In a session scoped bean, create a reference to a local SFSB. make an initial request, then wait 5-10 minutes. The EJB will passivate, then on next invocation of the session scoped bean attempt to access the SFSB. This may be more of a spec issue though, the more I think about it. CDI scope and EJB passivation need to be linked. Passivation of stateful session beans results in a loss of reference to injected object --- Key: WELD-80 URL: https://issues.jboss.org/browse/WELD-80 Project: Weld Issue Type: Bug Components: Scopes Contexts Environment: JBoss AS 5.1 Reporter: John Ament Fix For: TBC Attachments: statefulpassivate.zip See forum post -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Commented: (WELD-80) Passivation of stateful session beans results in a loss of reference to injected object
[ https://issues.jboss.org/browse/WELD-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591058#comment-12591058 ] John Ament commented on WELD-80: Pete, maybe this is the discrepancy. What if the EJB has no CDI beans in it, and is injected to the bean via @EJB? Passivation of stateful session beans results in a loss of reference to injected object --- Key: WELD-80 URL: https://issues.jboss.org/browse/WELD-80 Project: Weld Issue Type: Bug Components: Scopes Contexts Environment: JBoss AS 5.1 Reporter: John Ament Fix For: TBC Attachments: statefulpassivate.zip See forum post -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1733) @Singleton beans not found when discovery-mode is annotated
Title: Message Title John Ament commented on WELD-1733 Re: @Singleton beans not found when discovery-mode is annotated Singleton's are not bean defining annotations, as the Singleton scope is not a normal scope. http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations Specifically, this sentence notes the issue: Note that to ensure compatibility with other JSR-330 implementations, all pseudo-scope annotations except @Dependent are not bean defining annotations. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1732) @ApplicationScoped object instantiated twice
Title: Message Title John Ament commented on WELD-1732 Re: @ApplicationScoped object instantiated twice Reviewed with Bruno via twitter. The reason this fails for ApplicationScoped beans is that they get proxied. It looks like whatever proxy gets generated doesn't include the @FXML annotation on the private field for label. It passes for singleton since Singleton is a pseudo scope, it doesn't get proxied. Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-1732) @ApplicationScoped object instantiated twice
Title: Message Title John Ament commented on WELD-1732 Re: @ApplicationScoped object instantiated twice Based on a long twitter conversation, it seems like the issue Bruno is facing is similar to this one: http://stackoverflow.com/questions/22145327/nullpointerexception-javafx-label-settext Basically, it's more of a JavaFX issue where it was trying to eagerly load the controller without instantiating it via the configured factory. I gave him an alternate solution here: https://github.com/johnament/bruno-javafx-weld Add Comment This message was sent by Atlassian JIRA (v6.3.1#6329-sha1:7df76f1) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2065) Resource injection now generates NPE in SE mode
Title: Message Title John Ament created an issue Weld / WELD-2065 Resource injection now generates NPE in SE mode Issue Type: Bug Affects Versions: 2.3.1.Final Assignee: Unassigned Created: 15/Nov/15 3:46 PM Priority: Major Reporter: John Ament This seems to be a regression/behavioural change from 2.2.6 (the last time I was trying this). Scenario: I have an Arquillian test that is leveraging somewhere in its hierarchy an EntityManager. That entity manager is injected using @PersistenceContext. In Weld 2.2.6 that field would end up being null. In 2.3.1, that field is now throwing a Null Pointer Exception java.lang.NullPointerException at org.jboss.weld.util.Preconditions.checkNotNull(Preconditions.java:51)
[weld-issues] [JBoss JIRA] (WELD-2065) Resource injection now generates NPE in SE mode
Title: Message Title John Ament commented on WELD-2065 Re: Resource injection now generates NPE in SE mode After playing with it for a few days, I'm fine with the behavior. It's not really specified, and I think there needs to be some way of specifying the resource factory, but generally not an issue. The way I worked around it makes it a bit more testable. However, the NPE needs to get fixed and provide more information. I shouldn't need a debugger to figure out what classes weld doesn't like. If you want to treat this ticket as "fix the NPE" I'm fine with that. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2065) Resource injection now generates NPE in SE mode
Title: Message Title John Ament commented on WELD-2065 Re: Resource injection now generates NPE in SE mode Interesting, I actually get no errors in CR9 (I missed that I was still on CR8). Looking at the changes that went in, I see the changes related to what was changed for 2.3, so makes sense. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2065) Resource injection now generates NPE in SE mode
Title: Message Title John Ament commented on WELD-2065 Re: Resource injection now generates NPE in SE mode Which container does this run against? Mine were using arquillian-weld-ee or arquillian-weld-se. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2150) Move ActivateThreadScope/ActivateRequestScope to core
Title: Message Title John Ament commented on WELD-2150 Re: Move ActivateThreadScope/ActivateRequestScope to core Makes sense, feel free to change the scope of the ticket to request scope only. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2150) Move ActivateThreadScope/ActivateRequestScope to core
Title: Message Title John Ament created an issue Weld / WELD-2150 Move ActivateThreadScope/ActivateRequestScope to core Issue Type: Feature Request Assignee: Unassigned Components: Java SE Support, Scopes & Contexts Created: 16/May/16 8:05 AM Priority: Major Reporter: John Ament These two interceptors are great, however they're only available in SE mode. Would be great to have them in EE as well. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2150) Move ActivateThreadScope/ActivateRequestScope to core
Title: Message Title John Ament updated an issue Weld / WELD-2150 Move ActivateThreadScope/ActivateRequestScope to core Change By: John Ament Affects Version/s: 2.3.4.Final Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2150) Move ActivateThreadScope/ActivateRequestScope to core
Title: Message Title John Ament commented on WELD-2150 Re: Move ActivateThreadScope/ActivateRequestScope to core It wouldn't do much harm. I use it as a provided dependency for access to BoundRequestContext today for example. It would still be accessible to SE users as well. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2188) Embedded Tomcat 8.5 not picked up as Tomcat environment
Title: Message Title John Ament commented on WELD-2188 Re: Embedded Tomcat 8.5 not picked up as Tomcat environment Nope, I have a beans.xml, It's a plain annotated based one xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd" bean-discovery-mode="annotated"> Add Comment
[weld-issues] [JBoss JIRA] (WELD-2190) ContextNotActive thrown when a static instance holds a reference to a bean and container restarts
Title: Message Title John Ament created an issue Weld / WELD-2190 ContextNotActive thrown when a static instance holds a reference to a bean and container restarts Issue Type: Bug Affects Versions: 2.3.2.Final Assignee: Unassigned Created: 06/Jul/16 6:57 AM Priority: Minor Reporter: John Ament I suspect that this affects the entire 2.3 line. You can run the Weld2 profile in DeltaSpike prior to my last 2 commits to reproduce the issue, specifically in the proxy module. Basically, if you have a static reference that holds a reference to an app scoped bean, and an SE container stops and starts again, any contextual references that may be held in that static instance go away. However, a ContextNotActive exception is thrown. It was unclear why Weld was stating that the App Scope context was not active. ContextNotActive isn't really appropriate here. It should be some other exception. We ultimately fixed by removing the static reference. Add
[weld-issues] [JBoss JIRA] (WELD-2190) ContextNotActive thrown when a static instance holds a reference to a bean and container restarts
Title: Message Title John Ament commented on WELD-2190 Re: ContextNotActive thrown when a static instance holds a reference to a bean and container restarts One interesting thing here - OWB does not throw any exception in this case. We may want to clarify on the EG if in 2.0, if I stop and start an SE container and have references to contextual beans, what happens. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2188) Embedded Tomcat 8.5 not picked up as Tomcat environment
Title: Message Title John Ament created an issue Weld / WELD-2188 Embedded Tomcat 8.5 not picked up as Tomcat environment Issue Type: Bug Affects Versions: 2.3.5.Final Assignee: Unassigned Components: Servlet Container Support Created: 02/Jul/16 9:26 PM Priority: Major Reporter: John Ament Assuming the following dependencies in a project: org.jboss.weld.se
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title
John Ament created an issue
Weld / WELD-2223
Registering servlet listener on tomcat embedded fails
Issue Type:
Bug
Assignee:
Unassigned
Created:
20/Aug/16 10:03 AM
Priority:
Major
Reporter:
John Ament
Presume I have this test:
@Test
public void shouldStartTomcat() throws Exception {
try(WeldContainer weldContainer = new Weld().disableDiscovery()
.beanClasses(DefaultServlet.class).initialize()) {
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails A reproducible test case: https://github.com/hammock-project/hammock/blob/tomcat-issues/web-tomcat/src/test/java/ws/ament/hammock/web/tomcat/TomcatWebServerTest.java#L37 Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails Hi, thanks for rejecting my issue. The item you're proposing assumes I have access to the underlying weld container, which I don't in the case I'm using StartMain to launch my app. Likewise if I'm using arquillian to bootstrap, still don't have WeldContainer. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails I just double checked, after getting it working. This page has no information about setting the weld container. Add Comment This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails Even after setting the bean manager attribute com.google.common.util.concurrent.UncheckedExecutionException: org.jboss.weld.exceptions.IllegalStateException: WELD-001328: Unable to identify the correct BeanManager. The calling class org.jboss.weld.servlet.WeldInitialListener is not placed in bean archive at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2203) at com.google.common.cache.LocalCache.get(LocalCache.java:3937) at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3941) at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4824) at com.google.common.cache.LocalCache$LocalLoadingCache.getUnchecked(LocalCache.java:4830) at org.jboss.weld.SimpleCDI.getBeanManager(SimpleCDI.java:105) at org.jboss.weld.SimpleCDI.getBeanManager(SimpleCDI.java:38) at org.jboss.weld.servlet.WeldInitialListener.contextInitialized(WeldInitialListener.java:94)
[weld-issues] [JBoss JIRA] (WELD-2260) 2.4.1 Regression - Mixed Servlet & SE
Title: Message Title
John Ament updated an issue
Weld / WELD-2260
2.4.1 Regression - Mixed Servlet & SE
Change By:
John Ament
I use Weld SE and Weld Servlet together. While upgrading, I see this error:{code}Nov 26, 2016 8:52:50 AM org.jboss.weld.bootstrap.WeldStartup INFO: WELD-000900: 2.4.1 (Final)Nov 26, 2016 8:52:50 AM org.jboss.weld.bootstrap.WeldStartup startContainerINFO: WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.Nov 26, 2016 8:52:51 AM org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider INFO: Custom config found by DeltaSpike. Name: 'hammock.properties', URL: 'file:/Users/johnament/src/hammock/web-spi/target/classes/hammock.properties'Nov 26, 2016 8:52:51 AM org.apache.deltaspike.core.util.ProjectStageProducer initProjectStageINFO: Computed the following DeltaSpike ProjectStage: ProductionNov 26, 2016 8:52:51 AM org.jboss.weld.environment.se.WeldContainer completeINFO: WELD-ENV-002003: Weld SE container 8df36750-78b6-45d8-bc2c-b549e8b525de initializedNov 26, 2016 8:52:52 AM org.jboss.weld.environment.servlet.Listener contextInitializedINFO: WELD-ENV-001007: Initialize Weld using ServletContextListenerNov 26, 2016 8:52:52 AM org.jboss.weld.environment.undertow.UndertowContainer initializeINFO: WELD-ENV-001302: Undertow detected, CDI injection will be available in Servlets, Filters and Listeners.Nov 26, 2016 8:52:52 AM org.jboss.weld.environment.se.WeldContainer shutdownINFO: WELD-ENV-002001: Weld SE container 8df36750-78b6-45d8-bc2c-b549e8b525de shut downjava.lang.RuntimeException: java.lang.IllegalStateException: Singleton not set for STATIC_INSTANCE => [8df36750-78b6-45d8-bc2c-b549e8b525de] at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:236) at ws.ament.hammock.web.undertow.UndertowWebServer.start(UndertowWebServer.java:112) at ws.ament.hammock.web.undertow.UndertowWebServer$Proxy$_$$_WeldClientProxy.start(Unknown Source) at ws.ament.hammock.web.undertow.UndertowBootTest.shouldBootWebServer(UndertowBootTest.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at
[weld-issues] [JBoss JIRA] (WELD-2260) 2.4.1 Regression - Mixed Servlet & SE
Title: Message Title John Ament created an issue Weld / WELD-2260 2.4.1 Regression - Mixed Servlet & SE Issue Type: Bug Assignee: Unassigned Created: 26/Nov/16 8:56 AM Priority: Major Reporter: John Ament I use Weld SE and Weld Servlet together. While upgrading, I see this error: Nov 26, 2016 8:52:50 AM org.jboss.weld.bootstrap.WeldStartup INFO: WELD-000900: 2.4.1 (Final) Nov 26, 2016 8:52:50 AM org.jboss.weld.bootstrap.WeldStartup startContainer INFO: WELD-000101: Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously. Nov 26, 2016 8:52:51 AM org.apache.deltaspike.core.impl.config.EnvironmentPropertyConfigSourceProvider INFO: Custom config found by DeltaSpike. Name: 'hammock.properties', URL:
[weld-issues] [JBoss JIRA] (WELD-2276) Wrong proxy in use when interface used
Title: Message Title John Ament commented on WELD-2276 Re: Wrong proxy in use when interface used Hi Martin, so I thought about the groovy issue as well. I didn't think it was that issue since the problem went away when I switched it to use ExtensionManagerBus as the passed in type. Any reason you can think of that this would fix it? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2276) Wrong proxy in use when interface used
Title: Message Title John Ament commented on WELD-2276 Re: Wrong proxy in use when interface used Here's the related JIRA: https://issues.apache.org/jira/browse/CXF-7175 And the stacktrace: Caused by: java.lang.AbstractMethodError: org.apache.cxf.Bus$1366014918$Proxy$_$$_WeldClientProxy.getProperty(Ljava/lang/String;)Ljava/lang/Object; at org.apache.cxf.common.util.ClassHelper.getRealClass(ClassHelper.java:81) at org.apache.cxf.jaxrs.JAXRSServiceFactoryBean.setResourceClassesFromBeans(JAXRSServiceFactoryBean.java:223) at org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setServiceBeans(JAXRSServerFactoryBean.java:342) at org.apache.cxf.cdi.JAXRSCdiResourceExtension.createFactoryInstance(JAXRSCdiResourceExtension.java:186) at org.apache.cxf.cdi.JAXRSCdiResourceExtension.load(JAXRSCdiResourceExtension.java:136) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
[weld-issues] [JBoss JIRA] (WELD-2276) Wrong proxy in use when interface used
Title: Message Title John Ament created an issue Weld / WELD-2276 Wrong proxy in use when interface used Issue Type: Bug Affects Versions: 2.4.0.Final Assignee: Unassigned Created: 11/Dec/16 3:37 PM Priority: Major Reporter: John Ament For reference, you can run this test to reproduce this issue: https://github.com/hammock-project/hammock/blob/hammock-0.5.0/rest-cxf/src/test/java/ws/ament/hammock/rest/cxf/CXFTest.java The problem happens within CXF. They attempt to locate a bean using this: final Bean busBean = beanManager.resolve(beanManager.getBeans(CdiBusBean.CXF)); bus = (Bus)beanManager.getReference( busBean, Bus.class,
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails when container bootstrapped outside
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails when container bootstrapped outside Ok, so I think I understand the issue better. What's really happening is a dead lock between the two threads, simply because they're both locking on the same object. The second thread is derived from the first, so the lock never gets cleared. It seems to me, in this situation, the initialized event should not be fired from HttpContextLifecycle (it is fired in all 3 containers) since the container isn't bootstrapped from Weld Servlet. I hate to say it, but adding another boolean to the constructor for lifecycle may make the most sense. Thoughts? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament reopened an issue i was able to dig into this a bit deeper w/ some tomcat guys What I'm seeing is that during the execution of tomcat bootstrap during `AfterDeploymentValidation` this synchronized block causes a deadlock on the calling thread https://github.com/weld/core/blob/2.4/impl/src/main/java/org/jboss/weld/servlet/HttpContextLifecycle.java#L140 I'm going to try to dig in further to take a thread dump. Weld / WELD-2223 Registering servlet listener on tomcat embedded fails Change By: John Ament Resolution: Rejected Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament updated an issue Weld / WELD-2223 Registering servlet listener on tomcat embedded fails Change By: John Ament Affects Version/s: 2.4.0.Final Affects Version/s: 2.3.5.Final Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament updated an issue Weld / WELD-2223 Registering servlet listener on tomcat embedded fails Change By: John Ament Component/s: Servlet Container Support Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament updated an issue Weld / WELD-2223 Registering servlet listener on tomcat embedded fails Change By: John Ament Priority: Major Minor Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails Here's output from main thread: Name: main State: WAITING on java.util.concurrent.FutureTask@70a09034 Total blocked: 0 Total waited: 45 Stack trace: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) java.util.concurrent.FutureTask.get(FutureTask.java:191) org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:939) - locked org.apache.catalina.core.StandardEngine@120b1811 org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262) - locked org.apache.catalina.core.StandardEngine@120b1811
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails when container bootstrapped outside
Title: Message Title John Ament updated an issue Weld / WELD-2223 Registering servlet listener on tomcat embedded fails when container bootstrapped outside Change By: John Ament Summary: Registering servlet listener on tomcat embedded fails when container bootstrapped outside Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails when container bootstrapped outside
Title: Message Title
John Ament edited a comment on WELD-2223
Re: Registering servlet listener on tomcat embedded fails when container bootstrapped outside
i was able to dig into this a bit deeper w/ some tomcat guysWhat I'm seeing is that during the execution of tomcat bootstrap during ` {{ AfterDeploymentValidation ` }} this synchronized block causes a deadlock on the calling threadhttps://github.com/weld/core/blob/2.4/impl/src/main/java/org/jboss/weld/servlet/HttpContextLifecycle.java#L140I'm going to try to dig in further to take a thread dump.
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2260) Mixed Servlet & SE CDIProvider
Title: Message Title John Ament commented on WELD-2260 Re: Mixed Servlet & SE CDIProvider Martin, after debugging through this, I don't think that's the problem. From what I understand, WeldServletLifecycle.BEAN_MANAGER_ATTRIBUTE_NAME was explicitly added to handle this case, where the bean manager is already booted (or in process of being booted). Weld Servlet should be looking at that bean manager alone. I suspect this is what Listener.using(BeanManager) is meant for. However it seems like this attribute isn't being used currently. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2260) Mixed Servlet & SE CDIProvider
Title: Message Title John Ament commented on WELD-2260 Re: Mixed Servlet & SE CDIProvider This is the change that broke this functionality https://github.com/weld/core/commit/8f88f99e1be35061109d6904d4fe33565d49e975 And hence the workaround - manually set the container ID. I suspect that the fix is to use the container ID from the passed in bean manager. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2260) Mixed Servlet & SE CDIProvider
Title: Message Title
John Ament edited a comment on WELD-2260
Re: Mixed Servlet & SE CDIProvider
This is the change that broke this functionality https://github.com/weld/core/commit/8f88f99e1be35061109d6904d4fe33565d49e975And hence the workaround - manually set the container ID.I suspect that the fix is to use the container ID from the passed in bean manager.Its worth clarifying - the only way the work around works is to use the string constant {{STATIC_INSTANCE}} any other value causes it to fail. In addition, the work around does not work if you're using {{StartMain}}
Add Comment
This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2260) Mixed Servlet & SE CDIProvider
Title: Message Title John Ament commented on WELD-2260 Re: Mixed Servlet & SE CDIProvider Pull request raised that propagates the context ID when manager is found higher up in the chain. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2260) Mixed Servlet & SE CDIProvider
Title: Message Title John Ament updated WELD-2260 Weld / WELD-2260 Mixed Servlet & SE CDIProvider Change By: John Ament Status: Open Pull Request Sent Git Pull Request: https://github.com/weld/core/pull/1512 Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails when container bootstrapped outside
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails when container bootstrapped outside But that's not the case here. The first event being fired is `AfterDeploymentValidation` but then in tomcat you're firing `@Initialized(ApplicationScoped.class)` - however I suspect that shouldn't get fired. I don't believe it's fired for undertow, jetty, haven't quite figured out why its fired for Tomcat. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2223) Registering servlet listener on tomcat embedded fails when container bootstrapped outside
Title: Message Title John Ament commented on WELD-2223 Re: Registering servlet listener on tomcat embedded fails when container bootstrapped outside BTW, Tomcat has fixed their upstream issue with this. Starting with 9.0.0.M18, they have the ability to make this single threaded with fixes it as well. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2256) CDI.current() fails in portable extension observer methods
Title: Message Title John Ament commented on WELD-2256 Re: CDI.current() fails in portable extension observer methods I still see this in Weld 2.4.2.Final Exception in thread "main" org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions: Exception 0 : java.lang.IllegalStateException: WELD-ENV-002014: Weld SE container STATIC_INSTANCE not initialized completely at org.jboss.weld.environment.se.WeldContainer.checkInitializedCompletely(WeldContainer.java:316) at org.jboss.weld.environment.se.WeldContainer.checkState(WeldContainer.java:310) at org.jboss.weld.AbstractCDI.instanceInternal(AbstractCDI.java:146) at org.jboss.weld.AbstractCDI.select(AbstractCDI.java:89) at org.jboss.weld.AbstractCDI.select(AbstractCDI.java:47) at ws.ament.hammock.web.extension.StartWebServerExtension.afterDeployment(StartWebServerExtension.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[weld-issues] [JBoss JIRA] (CDITCK-595) Clarify the usage of Arquillian in the SE TCK tests
Title: Message Title John Ament reopened an issue Reopening - there is no where near enough information in https://github.com/cdi-spec/cdi-tck/blob/7da4f93e39fa925c76cf245d1017f53919ee8575/doc/reference/src/main/asciidoc/executing.asciidoc#running-the-tests-in-the-container---se-part to explain how to run the SE suite. You need to dump the dependencies into a directory. You need to configure this SE container to pick up those libraries on its boot. CDI TCK / CDITCK-595 Clarify the usage of Arquillian in the SE TCK tests Change By: John Ament Resolution: Rejected Status: Resolved Reopened Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (WELD-2403) Registering a bean of Optional doesn't satisfy injection points
Title: Message Title John Ament resolved as Done Turns out it was an errant alternative = true Weld / WELD-2403 Registering a bean of Optional doesn't satisfy injection points Change By: John Ament Status: Open Resolved Resolution: Done Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2403) Registering a bean of Optional doesn't satisfy injection points
Title: Message Title John Ament created an issue Weld / WELD-2403 Registering a bean of Optional doesn't satisfy injection points Issue Type: Bug Assignee: Unassigned Created: 08/Jul/17 10:45 AM Priority: Major Reporter: John Ament In Geronimo Config, for any fields found to match @Inject @ConfigProperty private Optional property We register a bean like this: new ConfigInjectionBean(injection.type) { @Override
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament commented on WELD-2402 Re: Weld attempts to proxy signed classes in the same package Assuming Ondrej can, here's a svn repo with the config impl for geronimo you can look at https://svn.apache.org/repos/asf/geronimo/components/config/trunk . There's a Weld profile in there feel free to tweak it. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament commented on WELD-2402 Re: Weld attempts to proxy signed classes in the same package Ondrej Mihályi do you have a way to push up the signed artifacts? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament created an issue Weld / WELD-2402 Weld attempts to proxy signed classes in the same package Issue Type: Bug Assignee: Unassigned Attachments: weld-signed-jars.txt Created: 04/Jul/17 9:15 PM Priority: Major Reporter: John Ament Apologies for the long stacktrace, didn't want to lose anything. Was running the Microprofile Config TCK against an Impl on top of Weld3, but I suspect that this is an issue in the 2.x line as well. Weld fails to load the generated proxy, due to the package being sealed by the signed JAR. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament updated an issue Weld / WELD-2402 Weld attempts to proxy signed classes in the same package Change By: John Ament Attachment: weld-signed-jars.txt Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2379) Principal injection should support KeycloakPrincipal
Title: Message Title John Ament commented on WELD-2379 Re: Principal injection should support KeycloakPrincipal But shouldn't you be inspecting the return of the principal to determine the valid types here? That's the bug in this case, you're only cosidering `Principal` which has a `getName` method.. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2379) Principal injection should support KeycloakPrincipal
Title: Message Title John Ament created an issue Weld / WELD-2379 Principal injection should support KeycloakPrincipal Issue Type: Enhancement Assignee: Unassigned Created: 24/Apr/17 9:26 PM Priority: Major Reporter: John Ament In EE, it is possible to inject a Principal object. I use Keycloak 3.0 on Wildfly 10.1. While the Principal object is injectable, its not an instance of KeycloakPrincipal, so it cannot be casted. Since Weld provides this bean, there should be someway to indicate that it should be a KeycloakPrincipal instead of the default Principal. I can see the right object gets injected, since the name is the same. Add Comment This message was sent by Atlassian JIRA
[weld-issues] [JBoss JIRA] (CDITCK-595) Clarify the usage of Arquillian in the SE TCK tests
Title: Message Title John Ament created an issue CDI TCK / CDITCK-595 Clarify the usage of Arquillian in the SE TCK tests Issue Type: Bug Assignee: Matej Novotny Created: 30/Jul/17 6:13 PM Priority: Major Reporter: John Ament There's a bunch of SE tests that use Arquillian for some reason, but then bootstrap an SE container. I'm not sure what the point of this is. To support this, OWB would need to support the ShrinkWrap protocol via classloader in SE, which seems to bring too much responsibility. Would it be possible to not use Arquillian for these tests? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-596) TCK Reports version JSR 346
Title: Message Title John Ament created an issue CDI TCK / CDITCK-596 TCK Reports version JSR 346 Issue Type: Bug Assignee: Matej Novotny Created: 30/Jul/17 8:47 PM Priority: Major Reporter: John Ament https://github.com/cdi-spec/cdi-tck/blob/49333d24aa5530f509f1d2b7678eb5718d7e3330/impl/src/main/java/org/jboss/cdi/tck/impl/ConfigurationImpl.java#L136 This should be updated to reflect 365. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d)
[weld-issues] [JBoss JIRA] (CDITCK-594) No TCK assertions for request context activation in web
Title: Message Title John Ament created an issue CDI TCK / CDITCK-594 No TCK assertions for request context activation in web Issue Type: Bug Affects Versions: 2.0.0.Final Assignee: Matej Novotny Created: 30/Jul/17 2:32 PM Priority: Major Reporter: John Ament Presently there are no TCK assertions that check the ability to start a context in a web scope. As the author of that section of the spec, what I would like to see includes: Verify it can be applied to a ManagedExecutorService's runnable/thread invocations Verify it can be applied in an async servlet invocation Verify it can be applied in a JAX-RS async invocation Add Comment
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title John Ament created an issue Weld / WELD-2411 Registering a custom Bean of Type Provider doesn't resolve to the right class Issue Type: Bug Assignee: Unassigned Created: 07/Aug/17 8:02 PM Priority: Major Reporter: John Ament https://github.com/apache/geronimo-config/blob/trunk/impl/src/main/java/org/apache/geronimo/config/cdi/ConfigExtension.java#L161 We register a custom bean of type provider, and mark it correctly as an alternative. Based on this, our custom bean should be registered as the bean in use rather than the default InstanceImpl that ships with Weld. However, we still get Weld's InstanceImpl. Add Comment This message was sent by Atlassian JIRA
[weld-issues] [JBoss JIRA] (WELD-2410) Trimmed Bean Archive does not discover injection points for test cases
Title: Message Title John Ament commented on WELD-2410 Re: Trimmed Bean Archive does not discover injection points for test cases Without something like this, it makes tests basically unusable. These components are managed by another runtime, and now because of the trimmed bean archive it doesn't work. It seems unnatural to add a CDI annotation to something that's never managed as a CDI bean. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-594) No TCK assertions for request context activation in web
Title: Message Title John Ament commented on CDITCK-594 Re: No TCK assertions for request context activation in web If there were no assertions that did this type of check, I would agree with you. However, there's already one package with a very limited test. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-595) Clarify the usage of Arquillian in the SE TCK tests
Title: Message Title John Ament commented on CDITCK-595 Re: Clarify the usage of Arquillian in the SE TCK tests Sure, but the only reason I know anything about the SE container is because I know about ALR's original prototype for it from several years ago. I actually had no idea it finally got built, and much less that it is in use in the SE tests for CDI TCK until I dug around that documentation. There's also no documentation on the arquillian website that explains how to use the SE container, which leads to an implicit licensing issue since you basically have to take the code from the RI to run the TCK. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title John Ament commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class Ok. FWIW, simply making isAlternative() return true enables it for OWB. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title John Ament commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class tested adding prioritized, that doesn't work either. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2410) Trimmed Bean Archive does not discover injection points for test cases
Title: Message Title John Ament commented on WELD-2410 Re: Trimmed Bean Archive does not discover injection points for test cases Right, and I lump Arquillian tests into that same bucket as Java EE components. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2411) Registering a custom Bean of Type Provider doesn't resolve to the right class
Title: Message Title John Ament commented on WELD-2411 Re: Registering a custom Bean of Type Provider doesn't resolve to the right class You can run the tests in the same repo, there's a provider test now. Prioritized was added in CDI 2.0, so can't really depend on that. How else would a programmatic bean be activated as an alternative back in Weld 2.x? Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2410) Trimmed Bean Archive does not discover injection points for test cases
Title: Message Title John Ament created an issue Weld / WELD-2410 Trimmed Bean Archive does not discover injection points for test cases Issue Type: Bug Assignee: Unassigned Created: 06/Aug/17 2:33 PM Priority: Major Reporter: John Ament I'm not sure if this is a weld issue or a weld arquillian container issue. Microprofile Config has a ConverterTest that has a field defined as @Inject @ConfigProperty Duck duck. The impls are supposed to find injection points for config and satisfy them. When using a trimmed bean archive from CDI 2.0, no ProcessInjectionPoint is fired for this field, even though the Arquillian adapter will attempt to inject into it. https://github.com/eclipse/microprofile-config/blob/master/tck/src/main/java/org/eclipse/microprofile/config/tck/ConverterTest.java#L83 Add Comment
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament commented on WELD-2402 Re: Weld attempts to proxy signed classes in the same package Matej Novotny FWIW, I looked at this quickly. I see a test was added for this case, but it fails presently - https://github.com/weld/core/commit/a132ec13d1b586cab92a7723aac932a9226f1a27#diff-775ddd78d13920c374858747a791d6df The first assertion is what's failing Assert.assertTrue(SealedBean.class.getPackage().isSealed()); Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2402) Weld attempts to proxy signed classes in the same package
Title: Message Title John Ament commented on WELD-2402 Re: Weld attempts to proxy signed classes in the same package I also don't understand what they try to archive with Typed and Vetoed implementation of the Config interface. Neither do I, this way, their Config bean is gonna be Object only and vetoed on top of that. I think you can ignore that. Vetoed will take precedence and kick out the bean, so Typed gets ignored. I think we were trying to reuse a Deltaspike trick to avoid injection, but Vetoed makes more sense here. Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2423) ParameterizedType information is lost when inspect method parameters under certain scenarios
Title: Message Title John Ament created an issue Weld / WELD-2423 ParameterizedType information is lost when inspect method parameters under certain scenarios Issue Type: Bug Assignee: Unassigned Created: 07/Sep/17 11:28 PM Priority: Major Reporter: John Ament I raised https://issues.apache.org/jira/browse/CXF-7493 as a CXF issue, but after mulling it over longer I decided its really a Weld problem. The issue originally manifested because weld copies annotations from the original class to the sub-class proxy when creating a proxy impl. This is nifty and saves some issues. However, it appears that when inspecting the parameters of these methods, if the type is something like List its not identified as a parameterized type, instead just the raw type, meaning we lose the generic type expected. Add Comment
[weld-issues] [JBoss JIRA] (WELD-2423) ParameterizedType information is lost when inspect method parameters under certain scenarios
Title: Message Title John Ament updated an issue Weld / WELD-2423 ParameterizedType information is lost when inspect method parameters under certain scenarios Change By: John Ament Affects Version/s: 3.0.1.Final Add Comment This message was sent by Atlassian JIRA (v7.2.3#72005-sha1:73be91d) ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-2449) Clarification of flat deployments
Title: Message Title John Ament created an issue Weld / WELD-2449 Clarification of flat deployments Issue Type: Task Assignee: Unassigned Created: 07/Jan/18 1:14 PM Priority: Major Reporter: John Ament When reviewing https://docs.jboss.org/weld/reference/latest/en-US/html/environments.html#_bean_archive_isolation_2 a question came up as to whether or not this propery could be pased in via the properties for a CDI 2.0 SeContainerInitializer. If it can, please update the docs. If it cannot, I will open a feature request to add it. Add Comment This message was sent by Atlassian JIRA (v7.5.0#75005-sha1:fd8c849)
[weld-issues] [JBoss JIRA] (WELD-2480) Invalid license in Weld Probe JAR file
Title: Message Title John Ament created an issue Weld / WELD-2480 Invalid license in Weld Probe JAR file Issue Type: Bug Assignee: Martin Kouba Components: Development Tools (Probe) Created: 26/Mar/18 6:42 AM Priority: Major Reporter: John Ament The Weld Probe JAR seems to include these dependencies in it (for the UI, confirmed by inspecting https://github.com/weld/core/tree/master/probe/core/src/main/client): D3 https://github.com/d3/d3/blob/master/LICENSE Font Awesome https://fontawesome.com/license Bootstrap https://github.com/twbs/bootstrap/blob/v3.3.1/LICENSE Ember JS https://github.com/emberjs/ember.js/blob/master/LICENSE Handlebars https://github.com/wycats/handlebars.js/blob/master/LICENSE Highlight https://github.com/isagalaev/highlight.js/blob/8.9.1/LICENSE Jquery https://github.com/jquery/jquery/blob/2.2.1/LICENSE.txt Moment https://github.com/moment/momentjs.com/blob/master/LICENSE None of these are Apache Licensed, yet the only license file shipped with the Probe JAR is the Apache License. Weld is out of compliance with all of these licenses since it does not replicate these licenses in its distribution of Weld Probe & these other products.
