[weld-issues] [JBoss JIRA] (CDITCK-419) Add sig files for Java SE 8 to CDI 1.0 and CDI 1.1 TCKs
Title: Message Title Pete Muir created an issue CDI TCK / CDITCK-419 Add sig files for Java SE 8 to CDI 1.0 and CDI 1.1 TCKs Issue Type: Feature Request Assignee: Martin Kouba Components: Signature Tests Created: 21/May/14 4:18 AM Priority: Major Reporter: Pete Muir Security Level: Public (Everyone can see) Add Comment This message was sent by Atlassian JIRA (v6.2.3#6260-sha1:63ef1d6)
[weld-issues] [JBoss JIRA] (CDITCK-41) Remove lib/ directories, and instead provide maven goal that will generate lib/
Pete Muir commented on CDITCK-41 Remove lib/ directories, and instead provide maven goal that will generate lib/ In the TCK distro, we have a lib dir, which we bundle. Instead, provide a maven pom.xml which can create the lib directory on demand. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-1293) When calling getReference with a type of EventBlah Weld errors
Pete Muir created WELD-1293 When calling getReference with a type of EventBlah Weld errors Issue Type: Bug Affects Versions: 1.1.10.Final Assignee: Jozef Hartinger Created: 21/Dec/12 9:01 AM Description: 13:55:13,472 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/jboss-as-ds-exception-handling].[FacesServlet]] (http-/127.0.0.1:8080-1) Servlet.service() for servlet FacesServlet threw exception: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001305 The given type javax.enterprise.event.EventBlah is not a type of the bean Implicit Bean [javax.enterprise.event.Event] with qualifiers [@Default] at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:633) [weld-core-1.1.10.Final-redhat-1.jar:1.1.10.Final-redhat-1] at org.jboss.as.quickstarts.deltaspike.exceptionhandling.jsf.DeltaSpikeExceptionHandler.getExceptionToCatchEvent(DeltaSpikeExceptionHandler.java:39) [classes:] at org.jboss.as.quickstarts.deltaspike.exceptionhandling.jsf.DeltaSpikeExceptionHandler.init(DeltaSpikeExceptionHandler.java:26) [classes:] at org.jboss.as.quickstarts.deltaspike.exceptionhandling.jsf.DeltaSpikeExceptionHandlerFactory.getExceptionHandler(DeltaSpikeExceptionHandlerFactory.java:16) [classes:] at com.sun.faces.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:98) [jsf-impl-2.1.13-redhat-1.jar:2.1.13-redhat-1] at javax.faces.webapp.FacesServlet.service(FacesServlet.java:583) [jboss-jsf-api_2.1_spec-2.0.7.Final-redhat-1.jar:2.0.7.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.10.Final-redhat-1.jar:1.1.10.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.1.3.Final-redhat-4.jar:7.1.3.Final-redhat-4] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679) [jbossweb-7.0.17.Final-redhat-1.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.17.Final-redhat-1.jar:] at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_37] Project: Weld Priority: Major Reporter: Pete Muir
[weld-issues] [JBoss JIRA] (WELD-621) Write tutorial for pastecode for refguide
Pete Muir commented on WELD-621 Write tutorial for pastecode for refguide We should close this and move it to JDF. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-1183) Add an easy way to pass a list of classes to start as beans to Weld SE
Pete Muir created WELD-1183 Add an easy way to pass a list of classes to start as beans to Weld SE Issue Type: Feature Request Affects Versions: 1.1.9.Final Assignee: Marko Lukša Components: Java SE Support Created: 16/Aug/12 5:54 PM Description: e.g. create an overloaded version of initialize that can take a list of classes and another than can take a varargs This is very useful for explicitly booting Weld in a test case. Project: Weld Priority: Major Reporter: Pete Muir This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. 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] (CDITCK-15) Corner case tests for injecting into non-contextual EJBs
[
https://issues.jboss.org/browse/CDITCK-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12679361#comment-12679361
]
Pete Muir commented on CDITCK-15:
-
For example, check that:
{code}
@Stateful @RequestScoped
class Bar {
@Inject Baz baz;
public Baz getBaz() { return baz; }
}
{code}
{code}
@Stateful @RequestScoped
class Baz {
@Inject Bar bar;
public Bar getBar() { return bar; }
}
{code}
And verify that this works, assuming they are normal scoped of course!
Corner case tests for injecting into non-contextual EJBs
Key: CDITCK-15
URL: https://issues.jboss.org/browse/CDITCK-15
Project: CDI TCK
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Tests
Reporter: Pete Muir
Assignee: Shane Bryzak
Fix For: 1.1.0.CR1
For example:
* chains of EJBs with contextual instances
* reentrant injcetion (allowed by EJB?)
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-994) Passivating Beans do not allow Injection of non-serializable Instance injections
[
https://issues.jboss.org/browse/WELD-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12675533#comment-12675533
]
Pete Muir commented on WELD-994:
This is a key use case for Instance though, so I'm not sure. Maybe we need to
offer both modes - did we ever add the option to not @PreDestroy dependent
instances got via Instance?
Passivating Beans do not allow Injection of non-serializable Instance
injections
Key: WELD-994
URL: https://issues.jboss.org/browse/WELD-994
Project: Weld
Issue Type: Bug
Components: Producers (Methods, Fields and Disposers)
Affects Versions: 1.1.2.Final
Environment: AS 7.0.2
WELD-000900 1.1.2 (Final)
Reporter: Cody Lerum
Assignee: Marko Lukša
Fix For: 1.2.0.Beta1
Given the following Code
{code:java}
@ConversationScoped
@Named
public class EmailTester implements Serializable {
private static final long serialVersionUID = 1L;
@Inject
private InstanceMailMessage mailMessage;
@Inject
private ActiveUser activeUser;
@Inject
private Messages messages;
@Inject
private InstanceSession session;
public void send()
{
MailMessage m = mailMessage.get();
m.from(activeUser.getUser());
m.to(activeUser.getUser());
m.subject(test);
m.bodyText(Blah blah blah);
m.send(session.get());
messages.info(Message Sent);
}
}
{code}
Weld throws
org.jboss.weld.exceptions.IllegalProductException: WELD-54 Producers
cannot produce non-serializable instances for injection into non-transient
fields of passivating beans\\n\\nProducer\: Producer Method [Session] with
qualifiers [@Any @Default] declared as [[method] @Produces @ExtensionManaged
public
org.jboss.seam.mail.core.MailSessionProducer.getMailSession(MailConfig)]\\nInjection
Point\:
org.jboss.weld.bean.builtin.InstanceImpl$InstanceInjectionPoint@2146ca:
javax.faces.FacesException: #{emailTester.send()}:
org.jboss.weld.exceptions.IllegalProductException: WELD-54 Producers
cannot produce non-serializable instances for injection into non-transient
fields of passivating beans\\n\\nProducer\: Producer Method [Session] with
qualifiers [@Any @Default] declared as [[method] @Produces @ExtensionManaged
public
org.jboss.seam.mail.core.MailSessionProducer.getMailSession(MailConfig)]\\nInjection
Point\:
org.jboss.weld.bean.builtin.InstanceImpl$InstanceInjectionPoint@2146ca
Since a new instance is returned each time a get() is called it should not
matter that the javax.mail.Session is not non-serializable
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-999) Interceptor binding transitivity broken
[ https://issues.jboss.org/browse/WELD-999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672685#comment-12672685 ] Pete Muir commented on WELD-999: resolveInterceptors should resolve transitive interceptors, if that is what you are asking. Interceptor binding transitivity broken --- Key: WELD-999 URL: https://issues.jboss.org/browse/WELD-999 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.2.Final Reporter: Jozef Hartinger Assignee: Marko Lukša Fix For: 1.2.0.Beta1 See org.jboss.weld.tests.interceptors.binding.transitivity.InterceptorBindingTransitivityTest -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-693) Add a way to get the active context easily
[ https://issues.jboss.org/browse/WELD-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672013#comment-12672013 ] Pete Muir commented on WELD-693: What else would be injected? Add a way to get the active context easily -- Key: WELD-693 URL: https://issues.jboss.org/browse/WELD-693 Project: Weld Issue Type: Feature Request Components: Scopes Contexts Reporter: Pete Muir Fix For: TBC For example @Inject @Active ConversationContext ctx; which would inject null if there was no active context -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-27) Consider using JBoss maven plugin, not ant for example builds
[ https://issues.jboss.org/browse/WELD-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reopened WELD-27: --- Assignee: Ales Justin (was: Dan Allen) Right, it's not done, e.g. https://github.com/weld/core/blob/master/examples/jsf/login/pom.xml Consider using JBoss maven plugin, not ant for example builds - Key: WELD-27 URL: https://issues.jboss.org/browse/WELD-27 Project: Weld Issue Type: Task Components: Examples Reporter: Pete Muir Assignee: Ales Justin Fix For: TBC -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-27) Consider using JBoss maven plugin, not ant for example builds
[ https://issues.jboss.org/browse/WELD-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671532#comment-12671532 ] Pete Muir commented on WELD-27: --- I'm not sure if it is done, it was done for the AS7 quickstarts, but I don't think it was ever sorted in Weld. Consider using JBoss maven plugin, not ant for example builds - Key: WELD-27 URL: https://issues.jboss.org/browse/WELD-27 Project: Weld Issue Type: Task Components: Examples Reporter: Pete Muir Assignee: Dan Allen Fix For: TBC -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-27) Consider using JBoss maven plugin, not ant for example builds
[ https://issues.jboss.org/browse/WELD-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671573#comment-12671573 ] Pete Muir commented on WELD-27: --- http://search.maven.org/#search%7Cga%7C1%7Ca%3A%22jboss-as-maven-plugin%22 Consider using JBoss maven plugin, not ant for example builds - Key: WELD-27 URL: https://issues.jboss.org/browse/WELD-27 Project: Weld Issue Type: Task Components: Examples Reporter: Pete Muir Assignee: Ales Justin Fix For: TBC -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (WELD-27) Consider using JBoss maven plugin, not ant for example builds
[ https://issues.jboss.org/browse/WELD-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671653#comment-12671653 ] Pete Muir commented on WELD-27: --- http://docs.jboss.org/jbossas/7/plugins/maven/latest/index.html Consider using JBoss maven plugin, not ant for example builds - Key: WELD-27 URL: https://issues.jboss.org/browse/WELD-27 Project: Weld Issue Type: Task Components: Examples Reporter: Pete Muir Assignee: Ales Justin Fix For: TBC -- 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 ___ weld-issues mailing list weld-issues@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] (CDITCK-211) Test that beans which are @Named via a stereotype are selectable with Instance.select()
[
https://issues.jboss.org/browse/CDITCK-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666798#comment-12666798
]
Pete Muir commented on CDITCK-211:
--
I think you are probably right Martin.
Test that beans which are @Named via a stereotype are selectable with
Instance.select()
---
Key: CDITCK-211
URL: https://issues.jboss.org/browse/CDITCK-211
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Shane Bryzak
Assignee: Martin Kouba
Priority: Minor
For example, say we have the following bean:
public @Model class Foo implements IFoo { }
And we have the following injection point within another bean:
@Inject InstanceFoo fooInstance;
Check that it is possible to select it
// This must not result in an UnsatisfiedDependencyException
Foo foo = fooInstance.select(new NamedLiteral(foo)).get();
--
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
___
weld-issues mailing list
weld-issues@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-issues
[weld-issues] [JBoss JIRA] Assigned: (WELD-963) Change Singleton to use a Map of ids - singletons
[ https://issues.jboss.org/browse/WELD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned WELD-963: -- Assignee: Mathieu ANCELIN Change Singleton to use a Map of ids - singletons -- Key: WELD-963 URL: https://issues.jboss.org/browse/WELD-963 Project: Weld Issue Type: Feature Request Components: OSGi support, Weld SPI Affects Versions: 1.1.2.Final Reporter: Pete Muir Assignee: Mathieu ANCELIN Fix For: 1.2.0.Beta1 This will allow for a more flexible approach to locating the singleton. -- 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-963) Change Singleton to use a Map of ids - singletons
[ https://issues.jboss.org/browse/WELD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626003#comment-12626003 ] Pete Muir commented on WELD-963: Note, it may make sense to introduce a deployment ID to make this easier. Change Singleton to use a Map of ids - singletons -- Key: WELD-963 URL: https://issues.jboss.org/browse/WELD-963 Project: Weld Issue Type: Feature Request Components: OSGi support, Weld SPI Affects Versions: 1.1.2.Final Reporter: Pete Muir Assignee: Mathieu ANCELIN Fix For: 1.2.0.Beta1 This will allow for a more flexible approach to locating the singleton. -- 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] Assigned: (WELD-962) Attach bda id and deployment id to the serialized proxy and use it on deserialization to locate correct singleton
[ https://issues.jboss.org/browse/WELD-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned WELD-962: -- Assignee: Mathieu ANCELIN Attach bda id and deployment id to the serialized proxy and use it on deserialization to locate correct singleton - Key: WELD-962 URL: https://issues.jboss.org/browse/WELD-962 Project: Weld Issue Type: Feature Request Components: Proxies Affects Versions: 1.1.2.Final Reporter: Pete Muir Assignee: Mathieu ANCELIN Fix For: 1.2.0.Beta1 -- 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] Issue Comment Edited: (WELD-963) Change Singleton to use a Map of ids - singletons
[ https://issues.jboss.org/browse/WELD-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626004#comment-12626004 ] Pete Muir edited comment on WELD-963 at 9/2/11 8:47 AM: Also, this will allow us to reattach much more reliably to the weld deployment in use, we may even be able to move the notion of a singleton to be internalized. However, given that we still need to initially attach various contexts to our deployment (e.g. JSF, Servlet, EJB invocation contexts). It may make sense to attach them once, by storing the deployment id into the context the first time we encounter them. was (Author: petemuir): Also, this will allow us to reattach much more reliably to the weld deployment in use, we may even be able to move the notion of a singleton to be internalized? Change Singleton to use a Map of ids - singletons -- Key: WELD-963 URL: https://issues.jboss.org/browse/WELD-963 Project: Weld Issue Type: Feature Request Components: OSGi support, Weld SPI Affects Versions: 1.1.2.Final Reporter: Pete Muir Assignee: Mathieu ANCELIN Fix For: 1.2.0.Beta1 This will allow for a more flexible approach to locating the singleton. -- 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-940) Possible bug when using weld:scan
[
https://issues.jboss.org/browse/WELD-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614704#comment-12614704
]
Pete Muir commented on WELD-940:
Interceptors and decorators are defined as beans, and are scanned. They are
simply enabled in beans.xml. However we can certainly produce a better error
message. Please file an issue for that.
Possible bug when using weld:scan
---
Key: WELD-940
URL: https://issues.jboss.org/browse/WELD-940
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.1.1.Final
Environment: Java SE application with weld-se-core, and a module with
embedded jetty hosting a servlet using weld-servlet-core
Reporter: Ondrej Zizka
Assignee: Pete Muir
A project has two jars.
One jar contains beans in package `org.jboss.jawabot`.
Other has WEB-INF/beans.xml (used by weld-servlet-core through embedded
Jetty), which contains
{code}
weld:scan
weld:include name=org.jboss.jawabot.**/
...
{code}
This causes CDI to stop working, giving errors like Unable to resolve
dependency XY or (after removing this @Inject) this:
{code}
Exception in thread main org.jboss.weld.exceptions.DeploymentException:
WELD-001417 Enabled interceptor class
classorg.jboss.weld.environment.se.jpa.JpaTransactionInterceptor/class in
jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml@11
is neither annotated @Interceptor nor registered through a portable extension
at
org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
{code}
, despite the class has @Interceptor (and the same class works fine with the
other module).
The project is at
http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ rev.
293
To see the error, run mvn dependency:copy-dependencies java -cp ...
org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
--
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-927) ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable
[ https://issues.jboss.org/browse/WELD-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614140#comment-12614140 ] Pete Muir commented on WELD-927: I think this a bug in Seam Faces, it can't assume it can serialize a Bean object. ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable Key: WELD-927 URL: https://issues.jboss.org/browse/WELD-927 Project: Weld Issue Type: Bug Components: CDI API, Class Beans (Managed and Session), Scopes Contexts, Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.1.Final Environment: Tomcat/Jetty, Weld Servlet 1.1.2-SNAPSHOT or 1.1.1-Final, MyFaces 2.x or 2.1.x, Seam Faces 3.0.1-Final, Seam Persistence 3.0.0 Reporter: Thomas Andraschko Priority: Blocker If you use @ViewScoped, a will exception occur that org.jboss.weld.bean.Managedbean is not serializable. This a blocker because we can't use @ViewScoped with Weld (and this envorionment) and Seam does not work with OWB. This should be the same issue as: https://issues.apache.org/jira/browse/EXTCDI-118 -- 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] Updated: (CDITCK-224) Missing injection points for CircularDependencyTest
[
https://issues.jboss.org/browse/CDITCK-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir updated CDITCK-224:
-
Fix Version/s: 1.1.0.CR1
Correct. I've scheduled for 1.1 as we can't introduce new tests in 1.0.x now
Missing injection points for CircularDependencyTest
---
Key: CDITCK-224
URL: https://issues.jboss.org/browse/CDITCK-224
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: Alexey Kazakov
Fix For: 1.1.0.CR1
It looks like that some beans tested by CircularDependencyTest miss injection
points.
See
org.jboss.jsr299.tck.tests.lookup.circular.NormalSelfConsumingNormalProducer,
org.jboss.jsr299.tck.tests.lookup.circular.DependentSelfConsumingNormalProducer,
org.jboss.jsr299.tck.tests.lookup.circular.NormalSelfConsumingDependentProducer
For instance there is a field *@SelfConsumingNormal1 Violation violation* in
DependentSelfConsumingNormalProducer:
{code}
class DependentSelfConsumingNormalProducer
{
@SelfConsumingNormal1 Violation violation;
@Produces @ApplicationScoped @SelfConsumingNormal1
public Violation produceViolation() {
return new Violation();
}
public void ping() {
}
}
{code}
which should be declared as an injection point: *@Inject*
@SelfConsumingNormal1 Violation violation
--
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-939) javax.inject-1's @Named does not have @Target
[ https://issues.jboss.org/browse/WELD-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613905#comment-12613905 ] Pete Muir commented on WELD-939: I guess Weld should suppress this error, it's not useful for a user javax.inject-1's @Named does not have @Target - Key: WELD-939 URL: https://issues.jboss.org/browse/WELD-939 Project: Weld Issue Type: Bug Reporter: Ondrej Zizka Priority: Minor @Named in javax.inject-1 artifact taken from jboss.org repo does not have @Target. Weld reports it: 18:49:15.594 DEBUG [main] org.jboss.weld.Reflection WELD-000601 interface javax.inject.Named is missing @Target. Weld will use this annotation, however this may make the application unportable. -- 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-940) Possible bug when using weld:scan
[
https://issues.jboss.org/browse/WELD-940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613906#comment-12613906
]
Pete Muir commented on WELD-940:
This looks like a user error to me. You are trying to activate an interceptor
which you provide in your code, but don't include in scan includes.
Possible bug when using weld:scan
---
Key: WELD-940
URL: https://issues.jboss.org/browse/WELD-940
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.1.1.Final
Environment: Java SE application with weld-se-core, and a module with
embedded jetty hosting a servlet using weld-servlet-core
Reporter: Ondrej Zizka
A project has two jars.
One jar contains beans in package `org.jboss.jawabot`.
Other has WEB-INF/beans.xml (used by weld-servlet-core through embedded
Jetty), which contains
{code}
weld:scan
weld:include name=org.jboss.jawabot.**/
...
{code}
This causes CDI to stop working, giving errors like Unable to resolve
dependency XY or (after removing this @Inject) this:
{code}
Exception in thread main org.jboss.weld.exceptions.DeploymentException:
WELD-001417 Enabled interceptor class
classorg.jboss.weld.environment.se.jpa.JpaTransactionInterceptor/class in
jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml@11
is neither annotated @Interceptor nor registered through a portable extension
at
org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
{code}
, despite the class has @Interceptor (and the same class works fine with the
other module).
The project is at
http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ rev.
293
To see the error, run mvn dependency:copy-dependencies java -cp ...
org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
--
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] Closed: (WELD-940) Possible bug when using weld:scan
[
https://issues.jboss.org/browse/WELD-940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir closed WELD-940.
--
Assignee: Pete Muir
Resolution: Rejected
Possible bug when using weld:scan
---
Key: WELD-940
URL: https://issues.jboss.org/browse/WELD-940
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.1.1.Final
Environment: Java SE application with weld-se-core, and a module with
embedded jetty hosting a servlet using weld-servlet-core
Reporter: Ondrej Zizka
Assignee: Pete Muir
A project has two jars.
One jar contains beans in package `org.jboss.jawabot`.
Other has WEB-INF/beans.xml (used by weld-servlet-core through embedded
Jetty), which contains
{code}
weld:scan
weld:include name=org.jboss.jawabot.**/
...
{code}
This causes CDI to stop working, giving errors like Unable to resolve
dependency XY or (after removing this @Inject) this:
{code}
Exception in thread main org.jboss.weld.exceptions.DeploymentException:
WELD-001417 Enabled interceptor class
classorg.jboss.weld.environment.se.jpa.JpaTransactionInterceptor/class in
jar:file:/mnt/ssd1/data/.m2/repository/org/jboss/jawabot/JawaBot-core/2.0.0-SNAPSHOT/JawaBot-core-2.0.0-SNAPSHOT.jar!/META-INF/beans.xml@11
is neither annotated @Interceptor nor registered through a portable extension
at
org.jboss.weld.bootstrap.Validator.validateEnabledInterceptorClasses(Validator.java:466)
{code}
, despite the class has @Interceptor (and the same class works fine with the
other module).
The project is at
http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0/ rev.
293
To see the error, run mvn dependency:copy-dependencies java -cp ...
org.jboss.jawabot.JawaBotApp Or simply run the web module in NetBeans.
--
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-927) ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable
[ https://issues.jboss.org/browse/WELD-927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613907#comment-12613907 ] Pete Muir commented on WELD-927: Can you provide a stack trace. ViewScoped does not work because org.jboss.weld.bean.Managedbean is not serializable Key: WELD-927 URL: https://issues.jboss.org/browse/WELD-927 Project: Weld Issue Type: Bug Components: CDI API, Class Beans (Managed and Session), Scopes Contexts, Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.1.Final Environment: Tomcat/Jetty, Weld Servlet 1.1.2-SNAPSHOT or 1.1.1-Final, MyFaces 2.x or 2.1.x, Seam Faces 3.0.1-Final, Seam Persistence 3.0.0 Reporter: Thomas Andraschko Priority: Blocker If you use @ViewScoped, a will exception occur that org.jboss.weld.bean.Managedbean is not serializable. This a blocker because we can't use @ViewScoped with Weld (and this envorionment) and Seam does not work with OWB. This should be the same issue as: https://issues.apache.org/jira/browse/EXTCDI-118 -- 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-920) Memory leak through the creational context of an @AppScoped bean when injecting Instance
[
https://issues.jboss.org/browse/WELD-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611472#comment-12611472
]
Pete Muir commented on WELD-920:
It appears that the discussion we had about this issue has not made it to the
issue :-/. Anyway, in essence the behavior you are seeing is expected in CDI
1.0, and this is not really an implementation bug. If you use Instance to
create an instance of a bean, then that instance becomes dependent on the
creator, and therefore you should not expect to see the instance discarded
until the parent instance is discarded.
We can describe instances which are attached (as the CDI 1.0 spec requires) as
managed instances, and those which the user takes responsibility for cleaning
up themselves as unmanaged instances. In CDI 1.1 I would like to add support
for unmanaged instances (the impl will just hand these over and forget about
them) and also to allow the app to request an unmanaged instance is cleaned up.
Please can someone file a CDI issue for this?
Weld could certainly be more friendly and more proactively discard instances.
Ideas:
1) Analyse the dependent instance graph, and if there are no
@PreDestroy/@Disposer callbacks on in the graph, do not store the dependent
instance for cleanup (this would be a good general optimization
(2) Add a config option to allow instances created from Instance to be held
only as long as the app holds a reference, and if the app doesn't hold a
reference for it's lifetime, then Weld would not do any cleanup (Weld would
hold a weak ref).
Memory leak through the creational context of an @AppScoped bean when
injecting Instance
--
Key: WELD-920
URL: https://issues.jboss.org/browse/WELD-920
Project: Weld
Issue Type: Bug
Components: Scopes Contexts
Affects Versions: 1.1.0.CR3, 1.1.1.Final
Reporter: Adam Warski
Attachments: leak-test-1.war, leak-test.tar.gz
Given a simple dependent-scoped bean: public class InstanceBean {}, and an
application-scoped bean (see below) to which an instance of the
dependent-scoped bean is injected, each time the get() method is called on
the instance, even though it's not used, a reference to it stays in the
creational context of the application scoped bean
(http://screencast.com/t/XqjQ1GB7Wv3). That way after several requests, where
each one calls the method, more and more memory is leaked
(http://screencast.com/t/s1VBx49i).
Attached is a simple web application demonstrating this. To reproduce, deploy
to AS6, click the leak button several times, and analyze the heap dump e.g.
in JProfiler.
@ApplicationScoped
@Named(test)
public class AppScopedBean {
private InstanceInstanceBean instanceBeanInstance;
@Inject
public AppScopedBean(InstanceInstanceBean instanceBeanInstance) {
this.instanceBeanInstance = instanceBeanInstance;
}
public AppScopedBean() {
}
public void leakOneInstance() {
System.out.println(Leaked!);
instanceBeanInstance.get();
}
}
--
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] Updated: (CDITCK-221) Synchronization bug in testXScopeActiveDuringCallToEjbTimeoutMethod tests
[
https://issues.jboss.org/browse/CDITCK-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir updated CDITCK-221:
-
Fix Version/s: 1.0.5.CR1
David, I will exclude these. Do you have a full list of affected tests?
Synchronization bug in testXScopeActiveDuringCallToEjbTimeoutMethod tests
---
Key: CDITCK-221
URL: https://issues.jboss.org/browse/CDITCK-221
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Fix For: 1.0.5.CR1
Waiting on either climbed or descended just tests that the timeout method was
entered but does not guarantee the end of the method was reached and the
proper state was set in the other variables. These tests will occasionally
fail for this timing issue.
Though not fancy, this kind of synchronization can work. We just need to
move these variables to the end of the timeout method. That will guarantee
that when either climbed or descended are set to true the other variables are
also in a testable state.
{code}
@Timeout
public void timeout(Timer timer)
{
if (beanManager.getContext(ApplicationScoped.class).isActive())
{
applicationScopeActive = true;
if (beanId 0.0)
{
if (beanId == simpleApplicationBeanInstance.get().getId())
{
sameBean = true;
}
}
else
{
beanId = simpleApplicationBeanInstance.get().getId();
}
}
// applicationScopeActive, beanId and sameBean have been set and are
testable
if (timer.getInfo().equals(CLIMB_COMMAND))
{
climbed = true;
}
if (timer.getInfo().equals(DESCEND_COMMAND))
{
descended = true;
}
}
{code}
--
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] Updated: (CDITCK-220) BuiltInBeansTest.testUserTransactionBean()
[
https://issues.jboss.org/browse/CDITCK-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir updated CDITCK-220:
-
Fix Version/s: 1.0.5.CR1
Thanks David. Confirmed. Not excluding for now unless I get asked to.
BuiltInBeansTest.testUserTransactionBean()
--
Key: CDITCK-220
URL: https://issues.jboss.org/browse/CDITCK-220
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Fix For: 1.0.5.CR1
We're passing this test, but wanted to drop a note that it should be updated.
We just need to update this bean like so:
{code}
@Stateful
@TransactionManagement(BEAN)
public class UserTransactionInjectedBean implements
UserTransactionInjectedBeanLocal
{
@Inject transient UserTransaction userTransaction;
public UserTransaction getUserTransaction()
{
return userTransaction;
}
}
{code}
Only @Stateful session bean explicitly marked as @TransactionManagement(BEAN)
are allowed to get UserTransaction via lookup or injection, the EJB TCK tests
cover this pretty well. In OpenEJB we have deploy-time checks for this if
@Resource is used to get a UserTransaction and we'd like to expand that
checking to properly cover @Inject injection as well. Even though we are
currently injecting that object and passing the test, it's a false pass and
at runtime that UserTransaction object is hardwired to throw exceptions if
used by a non-CMT bean.
--
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-923) Error in beans other than BeanManager are injected into a portable extension
Error in beans other than BeanManager are injected into a portable extension Key: WELD-923 URL: https://issues.jboss.org/browse/WELD-923 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Reporter: Pete Muir -- 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] Updated: (WELD-923) Error if beans other than BeanManager are injected into a portable extension
[ https://issues.jboss.org/browse/WELD-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated WELD-923: --- Summary: Error if beans other than BeanManager are injected into a portable extension (was: Error in beans other than BeanManager are injected into a portable extension) Error if beans other than BeanManager are injected into a portable extension Key: WELD-923 URL: https://issues.jboss.org/browse/WELD-923 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Reporter: Pete Muir -- 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: (CDITCK-212) DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created
[ https://issues.jboss.org/browse/CDITCK-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609306#comment-12609306 ] Pete Muir commented on CDITCK-212: -- Confirmed and tests excluded. DestroyedInstanceReturnedByGetTest assumes that the application scope can be destroyed and then re-created -- Key: CDITCK-212 URL: https://issues.jboss.org/browse/CDITCK-212 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Reporter: Stuart Douglas Context applicationContext = getCurrentManager().getContext(ApplicationScoped.class); destroyContext(applicationContext); setContextActive(applicationContext); myApplicationBeanInstance = applicationContext.get(myApplicationBean); The spec does not require that the application scope can be destroyed and re-created, if fact it could be argued that this behaviour violates the spec, as the application context is supposed to last for the lifetime of the application. -- 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: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count
[
https://issues.jboss.org/browse/CDITCK-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608142#comment-12608142
]
Pete Muir commented on CDITCK-215:
--
Gurkan, this is not how observer resolution works, . See 10.2.1. Essentially,
the issue is that when the the event type is parameterized, you must consider
only the observed type where the raw type is identical, so we can only consider
ProcessBeanObject as the event type to match the parameterized types for.
David gives an abstract example above.
Regarding the parameterized type of ProcessBean in the ProcessSessionBean type
hierarchy, this is as described in 11.5.8.
ProcessSessionBeanTest testProcessSessionBeanEvent count
Key: CDITCK-215
URL: https://issues.jboss.org/browse/CDITCK-215
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Assignee: Pete Muir
[Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2]
Test:
org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
Not sure if this is an issue or not, so filling this as a bug and not a
challenge. The test essentially has two observer methods and is asserting
that only one of them are called.
public void observeElephantSessionBean(@Observes
ProcessSessionBeanElephant event)
{
ProcessBeanObserver.elephantProcessSessionBean = event;
}
public void observeElephantBean(@Observes ProcessBeanElephant event)
{
ProcessBeanObserver.elephantProcessBeanCount++;
}
Specifically the test asserts that observeElephantSessionBean is called and
that observeElephantBean is not called.
Currently we call both because ProcessSessionBean is assignable to
ProcessBean and the generics are the same.
Is there a part of the spec that mandates only the most specific observer
method is called?
The only thing I can find is in 10.4 which says pretty clearly:
There may be arbitrarily many observer methods with the same event
parameter type and qualifiers.
A bean (or extension) may declare multiple observer methods.
Well I guess it's not that clear as it says essentially this may happen
rather than this may happen...and when it does the behavior is...[all are
invoked || only the most specific is invoked]
--
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] Assigned: (CDITCK-217) InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port
[ https://issues.jboss.org/browse/CDITCK-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned CDITCK-217: Assignee: Jozef Hartinger Jozef did you write this test? InjectionIntoWebServiceEndpoint test uses hard-coded HTTP port -- Key: CDITCK-217 URL: https://issues.jboss.org/browse/CDITCK-217 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton Assignee: Jozef Hartinger The following test in the CDI TCK: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.InjectionIntoWebServiceEndPointTest.testInjectionIntoWebServiceEndpoint appears to use a hard-coded HTTP port in the following web service client class: org.jboss.jsr299.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService This test is quite different from the rest of the suite, in that the configured HTTP port is not used in this client. It appears that the test is non-portable in its current state. I request that this test be excluded. Thanks. -- 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: (CDITCK-216) No Support for standalone EJBContainer
[
https://issues.jboss.org/browse/CDITCK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607779#comment-12607779
]
Pete Muir commented on CDITCK-216:
--
David, correct, we will address this in CDI 1.1
No Support for standalone EJBContainer
--
Key: CDITCK-216
URL: https://issues.jboss.org/browse/CDITCK-216
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: David Blevins
Fix For: 1.0.4.Final
Actually pertains to [1.0.4.SP2]
The ContainerEventTest has an ejb-jar.xml file that defines a stateful
session bean which is otherwise not annotated and discoverable. The harness
is not including this ejb-jar.xml in the 'deploy(InputStream archive, String
name)' call on the Containers implement. The contents are as follows:
{code}
2 Wed Jun 08 20:54:02 PDT 2011 META-INF/MANIFEST.MF
0 Wed Jun 08 20:54:02 PDT 2011 META-INF/beans.xml
237 Wed Jun 08 20:54:02 PDT 2011 META-INF/jboss-test-harness.properties
243 Wed Jun 08 20:54:02 PDT 2011
META-INF/services/javax.enterprise.inject.spi.Extension
9369 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/AbstractJSR299Test.class
860 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/api/JSR299Configuration.class
824 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/DeploymentFailure.class
2712 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/ForwardingBean.class
3199 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/JSR299ConfigurationImpl.class
2690 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/JSR299PropertiesBasedConfigurationBuilder.class
1995 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/MockCreationalContext.class
3914 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/OldSPIBridge.class
2331 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/WebProfileMethodSelector.class
497 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/AnyLiteral.class
521 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/DefaultLiteral.class
482 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/InjectLiteral.class
572 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/NamedLiteral.class
497 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/NewLiteral.class
524 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/RetentionLiteral.class
506 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/TargetLiteral.class
557 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Beans.class
684 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Contexts.class
800 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/EL.class
398 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Managers.class
421 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Cheese.class
8613 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ContainerEventTest.class
412 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Cow.class
151 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/CowLocal.class
834 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Farm.class
405 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Food.class
415 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Milk.class
3580 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessAnnotatedTypeObserver.class
5054 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessBeanObserver.class
6331 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessInjectionTargetObserver.class
697 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Sheep.class
786 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/SheepInterceptor.class
235 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/SheepLocal.class
528 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Tame.class
{code}
Here's the toString() value of the harness Configuration in case that helps.
Possibly there's some flag I need.
{code}
JSR 299 TCK Configuration
-
Beans: org.apache.openejb.tck.cdi.embedded.BeansImpl@61e090ee
Containers: org.apache.openejb.tck.cdi.embedded.ContainersImpl@5e4b2b75
Contexts: org.apache.openejb.tck.cdi.embedded.ContextsImpl@19123eb0
EL:
[weld-issues] [JBoss JIRA] Commented: (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec
[ https://issues.jboss.org/browse/CDITCK-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607797#comment-12607797 ] Pete Muir commented on CDITCK-213: -- Hi Bob, Sorry for that, should be fixed now. Thanks! Interceptor classes in TCK do not follow the Interceptor spec - Key: CDITCK-213 URL: https://issues.jboss.org/browse/CDITCK-213 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton Fix For: 1.0.5.CR1 There are some interceptor-related suites in the CDI TCK that are not portable in some situations. The interceptor classes listed here: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.MissileInterceptor These interceptor classes do not have a public, no-args constructor, which is required by the Interceptor 1.1 specification. This means that the tests may not be portable to all environments, since application servers may choose to treat this as an error condition. The following tests are affected by this issue: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.SessionBeanInterceptorOrderTest.testInterceptorsDeclaredUsingInterceptorsCalledBeforeInterceptorBinding org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest.testNonContextualSessionBeanReferenceIsIntercepted org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.SessionBeanInterceptorDefinitionTest.testSessionBeanIsIntercepted I request that these tests be excluded from the 1.0.4 suite, and that the interceptors be fixed for subsequent versions of the test suite. -- 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: (CDITCK-216) ContainerEventTest and missing ejb-jar.xml file
[
https://issues.jboss.org/browse/CDITCK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607426#comment-12607426
]
Pete Muir commented on CDITCK-216:
--
Hmm, I see it on my unzip.
I'll exclude this test from 1.0.4 but it looks like this is fixed already.
Could you check trunk for me when you have time?
ContainerEventTest and missing ejb-jar.xml file
---
Key: CDITCK-216
URL: https://issues.jboss.org/browse/CDITCK-216
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: David Blevins
Fix For: 1.0.4.Final
Actually pertains to [1.0.4.SP2]
The ContainerEventTest has an ejb-jar.xml file that defines a stateful
session bean which is otherwise not annotated and discoverable. The harness
is not including this ejb-jar.xml in the 'deploy(InputStream archive, String
name)' call on the Containers implement. The contents are as follows:
{code}
2 Wed Jun 08 20:54:02 PDT 2011 META-INF/MANIFEST.MF
0 Wed Jun 08 20:54:02 PDT 2011 META-INF/beans.xml
237 Wed Jun 08 20:54:02 PDT 2011 META-INF/jboss-test-harness.properties
243 Wed Jun 08 20:54:02 PDT 2011
META-INF/services/javax.enterprise.inject.spi.Extension
9369 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/AbstractJSR299Test.class
860 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/api/JSR299Configuration.class
824 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/DeploymentFailure.class
2712 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/ForwardingBean.class
3199 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/JSR299ConfigurationImpl.class
2690 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/JSR299PropertiesBasedConfigurationBuilder.class
1995 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/MockCreationalContext.class
3914 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/OldSPIBridge.class
2331 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/impl/WebProfileMethodSelector.class
497 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/AnyLiteral.class
521 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/DefaultLiteral.class
482 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/InjectLiteral.class
572 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/NamedLiteral.class
497 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/NewLiteral.class
524 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/RetentionLiteral.class
506 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/literals/TargetLiteral.class
557 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Beans.class
684 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Contexts.class
800 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/EL.class
398 Wed Jun 08 20:54:02 PDT 2011 org/jboss/jsr299/tck/spi/Managers.class
421 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Cheese.class
8613 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ContainerEventTest.class
412 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Cow.class
151 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/CowLocal.class
834 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Farm.class
405 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Food.class
415 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Milk.class
3580 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessAnnotatedTypeObserver.class
5054 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessBeanObserver.class
6331 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/ProcessInjectionTargetObserver.class
697 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Sheep.class
786 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/SheepInterceptor.class
235 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/SheepLocal.class
528 Wed Jun 08 20:54:02 PDT 2011
org/jboss/jsr299/tck/tests/extensions/container/event/Tame.class
{code}
Here's the toString() value of the harness Configuration in case that helps.
Possibly there's some flag I need.
{code}
JSR 299 TCK Configuration
-
Beans: org.apache.openejb.tck.cdi.embedded.BeansImpl@61e090ee
Containers:
[weld-issues] [JBoss JIRA] Commented: (CDITCK-215) ProcessSessionBeanTest testProcessSessionBeanEvent count
[
https://issues.jboss.org/browse/CDITCK-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607427#comment-12607427
]
Pete Muir commented on CDITCK-215:
--
The signature of ProcessSessionBean is
{code}
public interface ProcessSessionBeanX extends ProcessManagedBeanObject {
{code}
So I don't believe you would see a ProcessBeanElephant observer called, as
10.2.1 tells us:
{quote}
the observed event type parameter is an actual type with identical raw type to
the event type parameter, and, if the type is parameterized, the event type
parameter is assignable to the observed event type parameter according to these
rules
{quote}
and Object is not assignable to Elephant.
ProcessSessionBeanTest testProcessSessionBeanEvent count
Key: CDITCK-215
URL: https://issues.jboss.org/browse/CDITCK-215
Project: CDI TCK
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.0.4.Final
Reporter: David Blevins
[Side note maybe there should be versions for 1.0.4.SP1 and 1.0.4.SP2]
Test:
org.jboss.jsr299.tck.tests.extensions.processBean.ProcessSessionBeanTest.testProcessSessionBeanEvent
Not sure if this is an issue or not, so filling this as a bug and not a
challenge. The test essentially has two observer methods and is asserting
that only one of them are called.
public void observeElephantSessionBean(@Observes
ProcessSessionBeanElephant event)
{
ProcessBeanObserver.elephantProcessSessionBean = event;
}
public void observeElephantBean(@Observes ProcessBeanElephant event)
{
ProcessBeanObserver.elephantProcessBeanCount++;
}
Specifically the test asserts that observeElephantSessionBean is called and
that observeElephantBean is not called.
Currently we call both because ProcessSessionBean is assignable to
ProcessBean and the generics are the same.
Is there a part of the spec that mandates only the most specific observer
method is called?
The only thing I can find is in 10.4 which says pretty clearly:
There may be arbitrarily many observer methods with the same event
parameter type and qualifiers.
A bean (or extension) may declare multiple observer methods.
Well I guess it's not that clear as it says essentially this may happen
rather than this may happen...and when it does the behavior is...[all are
invoked || only the most specific is invoked]
--
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-918) interceptor binding for java interfaces/methods
[ https://issues.jboss.org/browse/WELD-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607433#comment-12607433 ] Pete Muir commented on WELD-918: No, this is not supported by CDI. interceptor binding for java interfaces/methods --- Key: WELD-918 URL: https://issues.jboss.org/browse/WELD-918 Project: Weld Issue Type: Feature Request Components: Weld SPI Affects Versions: 1.1.0.Final Environment: tomcat6 Reporter: Manuel Hartl Priority: Minor - i created an interceptor and marked an java interface class with its binding (or a method of the interface) - interception does not work on methods of beans, that implement this interface. should this work? (interceptor binding to java interfaces?) if yes: it's a bug :) if no: please update weld documentation actually, i would like to use in interfaces -- 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] Updated: (WELD-918) interceptor binding for java interfaces/methods
[ https://issues.jboss.org/browse/WELD-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated WELD-918: --- Issue Type: Task (was: Feature Request) Please file a CDI issue for using bindings on interfaces. interceptor binding for java interfaces/methods --- Key: WELD-918 URL: https://issues.jboss.org/browse/WELD-918 Project: Weld Issue Type: Task Components: Weld SPI Affects Versions: 1.1.0.Final Environment: tomcat6 Reporter: Manuel Hartl Priority: Minor - i created an interceptor and marked an java interface class with its binding (or a method of the interface) - interception does not work on methods of beans, that implement this interface. should this work? (interceptor binding to java interfaces?) if yes: it's a bug :) if no: please update weld documentation actually, i would like to use in interfaces -- 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-919) Conversation propagation token that negates the cid parameter
[ https://issues.jboss.org/browse/WELD-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607435#comment-12607435 ] Pete Muir commented on WELD-919: Nik, make sure you add a CDI feature request as well. Conversation propagation token that negates the cid parameter --- Key: WELD-919 URL: https://issues.jboss.org/browse/WELD-919 Project: Weld Issue Type: Feature Request Components: Conversations Affects Versions: 1.1.1.Final Reporter: Nicklas Karlsson Assignee: Ales Justin Fix For: 1.1.2.Final A method that negates the propagation of the cid parameter by the ConversationAwareViewHandler so that a non-transient is not resumed even if there is a cid parameter in the request. Stripping it out on a per-component-basis is tricky. Suggested implementation: change the last line in WeldPhaseListener.getConversationId to return facesContext.getExternalContext().getRequestParameterMap().containsKey(nocid) ? null : cid; -- 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] Updated: (CDITCK-213) Interceptor classes in TCK do not follow the Interceptor spec
[ https://issues.jboss.org/browse/CDITCK-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDITCK-213: - Fix Version/s: 1.0.5.CR1 Confirmed, and excludes updated. Interceptor classes in TCK do not follow the Interceptor spec - Key: CDITCK-213 URL: https://issues.jboss.org/browse/CDITCK-213 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Bob Nettleton Fix For: 1.0.5.CR1 There are some interceptor-related suites in the CDI TCK that are not portable in some situations. The interceptor classes listed here: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.MissileInterceptor org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.MissileInterceptor These interceptor classes do not have a public, no-args constructor, which is required by the Interceptor 1.1 specification. This means that the tests may not be portable to all environments, since application servers may choose to treat this as an error condition. The following tests are affected by this issue: org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.interceptorOrder.SessionBeanInterceptorOrderTest.testInterceptorsDeclaredUsingInterceptorsCalledBeforeInterceptorBinding org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.nonContextualReference.SessionBeanInterceptorOnNonContextualEjbReferenceTest.testNonContextualSessionBeanReferenceIsIntercepted org.jboss.jsr299.tck.tests.interceptors.definition.enterprise.simpleInterception.SessionBeanInterceptorDefinitionTest.testSessionBeanIsIntercepted I request that these tests be excluded from the 1.0.4 suite, and that the interceptors be fixed for subsequent versions of the test suite. -- 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-900) Docs: Improve Weld reference. Make it less poetic and more structured.
[
https://issues.jboss.org/browse/WELD-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605737#comment-12605737
]
Pete Muir commented on WELD-900:
{quote}
For instance, 1.2. Getting our feet wet.
1) Call me boring, but in reference manual, I'd expect CDI Basics or such.
{quote}
Boring :-p
Generally, I understand your comment about style, and we disagree with you, we
feel the style the guide is written in is one that many people appreciate.
There are other sources of info on CDI that are bookish, such as the Java EE
guide, which might be more to your taste.
Your specific comments about flow are very useful, could you open new issues
for these so we can correct?
Docs: Improve Weld reference. Make it less poetic and more structured.
--
Key: WELD-900
URL: https://issues.jboss.org/browse/WELD-900
Project: Weld
Issue Type: Bug
Components: Documentation
Reporter: Ondrej Zizka
Assignee: Pete Muir
It's nice to have a nice text for a DZone article, but for a reference
documentation, we should favor briefness and structure over potential
nomination for Man Booker International Prize :)
What I mean is, e.g., if someone starts with Weld, he needs steps 1., 2., 3.
IMO, this should be in **bold** in a special chapter called Preparing
project to use Weld, with a sample code which is verified to work if copied
and run, and eventually a reference to a quick-start app:
{quote}
There's just little one thing you need to do before you can start injecting
them into stuff: you need to put them in an archive (a jar, or a Java EE
module such as a war or EJB jar) that contains a special marker file:
META-INF/beans.xml.
{quote}
In contrast, currently this most important information is buried at the end
of last paragraph of irrelevantly sounding chapter, 1.1. What is a bean?.
Why would anyone read What is a bean?
my2p, ymmv
--
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-914) WARN if beans.xml is missing in standalone mode.
[
https://issues.jboss.org/browse/WELD-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604642#comment-12604642
]
Pete Muir commented on WELD-914:
Note that we know in SE that the user does want CDI enabled, so a missing
beans.xml is obviously wrong!
WARN if beans.xml is missing in standalone mode.
Key: WELD-914
URL: https://issues.jboss.org/browse/WELD-914
Project: Weld
Issue Type: Enhancement
Reporter: Ondrej Zizka
Attachments: CdiTry.zip
STR:
1) Get the attached project, or,
svn co http://ondrazizka.googlecode.com/svn/trunk/CdiTry -r 219
2) Remove beans.xml (if present)
3) Run org.jboss.qa.test.cditry.AppWeld
You'll get an exception
{code}
33 [main] INFO org.jboss.weld.Version - WELD-000900 1.1.1 (Final)
54 [main] INFO org.jboss.weld.Bootstrap - WELD-000101 Transactional services
not available. Injection of @Inject UserTransaction not available.
Transactional observers will be invoked synchronously.
273 [main] WARN org.jboss.interceptor.util.InterceptionTypeRegistry - Class
'javax.ejb.PostActivate' not found, interception based on it is not enabled
273 [main] WARN org.jboss.interceptor.util.InterceptionTypeRegistry - Class
'javax.ejb.PrePassivate' not found, interception based on it is not enabled
Exception in thread main
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308 Unable
to resolve any beans for Types: [class org.jboss.myapp.MyApp]; Bindings:
[@javax.enterprise.inject.Default()]
at
org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:809)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:108)
at org.jboss.jawabot.JawaBotAppWeld.main(JawaBotAppWeld.java:17)
{code}
There should be a WARN if beans.xml is not found in standalone mode to make
it easier to figure it out.
(I was tending to believe that there's something much more complex going on.)
--
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-905) @Alternative broken if multiple implementations are in the classpath
[ https://issues.jboss.org/browse/WELD-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602709#comment-12602709 ] Pete Muir commented on WELD-905: Could you attach this as an example, I'm struggling to understand the pseudo version... @Alternative broken if multiple implementations are in the classpath Key: WELD-905 URL: https://issues.jboss.org/browse/WELD-905 Project: Weld Issue Type: Bug Components: Resolution (Typesafe and by Name) Affects Versions: 1.1.1.Final Reporter: Gerhard Petracek Priority: Critical example (broken): bean-archive #1: - BeanA - BeanA1 (@Alternative) - beans.xml (activates BeanA1 as alternative) bean-archive #2: - BeanA2 (@Typed()) - beans.xml (empty) BeanA1 doesn't get used (without an error or a warning BeanA is used instead - even though BeanA1 is activated as alternative in the same bean-archive) example (working): bean-archive #1: - BeanA - BeanA1 (@Alternative) - beans.xml (activates BeanA1 as alternative) jar #2 (no bean-archive): - BeanA2 (@Typed()) BeanA1 gets activated as alternative (as expected) because jar #2 isn't a bean-archive (that's the difference compared to the broken example). that prevents e.g. portable extensions from providing extension-points to work around the broken @Alternative spec. section. -- 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-900) Docs: Improve Weld reference. Make it less poetic and more structured.
[
https://issues.jboss.org/browse/WELD-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600641#comment-12600641
]
Pete Muir commented on WELD-900:
We already have a chapter that details how to get started with Weld, called
Getting started with Weld --
http://docs.jboss.org/weld/reference/latest/en-US/html/gettingstarted.html
Anyway, if you have any concrete changes, please create a pull request,
otherwise I'll close this issue as it's not particularly definite about what
can be changed.
Docs: Improve Weld reference. Make it less poetic and more structured.
--
Key: WELD-900
URL: https://issues.jboss.org/browse/WELD-900
Project: Weld
Issue Type: Bug
Components: Documentation
Reporter: Ondrej Zizka
It's nice to have a nice text for a DZone article, but for a reference
documentation, we should favor briefness and structure over potential
nomination for Man Booker International Prize :)
What I mean is, e.g., if someone starts with Weld, he needs steps 1., 2., 3.
IMO, this should be in **bold** in a special chapter called Preparing
project to use Weld, with a sample code which is verified to work if copied
and run, and eventually a reference to a quick-start app:
{quote}
There's just little one thing you need to do before you can start injecting
them into stuff: you need to put them in an archive (a jar, or a Java EE
module such as a war or EJB jar) that contains a special marker file:
META-INF/beans.xml.
{quote}
In contrast, currently this most important information is buried at the end
of last paragraph of irrelevantly sounding chapter, 1.1. What is a bean?.
Why would anyone read What is a bean?
my2p, ymmv
--
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: (CDITCK-210) org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interfac
[ https://issues.jboss.org/browse/CDITCK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597787#comment-12597787 ] Pete Muir commented on CDITCK-210: -- It means that the test will be fixed in 1.0.5.CR1 and that is the point it can be removed from the exclude list (which you can put it on now). The 1.1.0.CR1 is just a housekeeping thing.. org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface -- Key: CDITCK-210 URL: https://issues.jboss.org/browse/CDITCK-210 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Environment: Generic Java Platform Reporter: Bob Nettleton Assignee: Jozef Hartinger Fix For: 1.0.5.CR1, 1.1.0.CR1 A Stateful session bean defined in the following test suite: org.jboss.jsr299.tck.tests.implementation.enterprise.definition includes a @Remove method that is not part of the Session Bean's Business interface. The bean in question is: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull According to the javadoc for the Remove annotation: http://download.oracle.com/javaee/6/api/javax/ejb/Remove.html This annotation must be placed on a method that is also a part of the Session Bean's business interface. This issue can cause problems with the portability of this test application and test suite, since different application servers may fail at deployment time with this type of EJB-related error. I request that either the Session Bean be modified to add this method to the business interface, or that the tests listed below be removed from the TCK: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testStatelessMustBeDependentScoped [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanViaXmlTest.testEjbDeclaredInXmlNotSimpleBean [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithDependentScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testEnterpriseBeanClassLocalView [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testObjectIsInAPITypes [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithStereotype [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testDefaultName [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithNamedAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithQualifiers [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithScopeAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithApplicationScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanTypesAreLocalInterfacesWithoutWildcardTypesOrTypeVariablesWithSuperInterfaces [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testConstructorAnnotatedInjectCalled [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testRemoteInterfacesAreNotInAPITypes Another test suite: org.jboss.jsr299.tck.tests.context.dependent.ejb also has this problem in the following Stateful session EJB: org.jboss.jsr299.tck.tests.context.dependent.ejb.Fox In addition to the list above, the following tests also appear to be affected by this issue: org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependentSimples [testng] org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependents -- 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-888) Interceptors not resolvable from a WAR-module which is part of an EAR-deployment
[ https://issues.jboss.org/browse/WELD-888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597035#comment-12597035 ] Pete Muir commented on WELD-888: How do you try to resolve it? Is there an exception thrown? Interceptors not resolvable from a WAR-module which is part of an EAR-deployment Key: WELD-888 URL: https://issues.jboss.org/browse/WELD-888 Project: Weld Issue Type: Bug Components: Interceptors and Decorators Affects Versions: 1.1.1.Final Environment: - Weld 1.1.1. Final on JBoss 6.0 GA and JBoss 6.1 nightly - tested and confirmed on Vista 32 and Linux 64 Reporter: Jan Groth Attachments: probear-jar.zip, probear.zip It seems like CDI interceptors cannot be accessed from inside a WAR-module of an EAR deployment if the interceptor is defined inside a dependent JAR which is located in the EAR/lib directory. BUT: - Managed beans and producers from the same JAR work without problems. - Moving the dependency from EAR/lib to WAR/WEB-INF/lib makes the interceptor work without problems. I consider that a serious problem, because this is a substantial restriction for enterprise applications. -- 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-890) CDI Bean doesn't work like a webservice/soap client
[
https://issues.jboss.org/browse/WELD-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597037#comment-12597037
]
Pete Muir commented on WELD-890:
Please open an issue in the GlassFish issue tracker, this is an issue in
GF/Weld integration most likely nothing to do with Weld core.
CDI Bean doesn't work like a webservice/soap client
---
Key: WELD-890
URL: https://issues.jboss.org/browse/WELD-890
Project: Weld
Issue Type: Bug
Components: Class Beans (Managed and Session)
Affects Versions: 1.1.0.Final
Environment: NetBeans 7.0 RC2 + GlassFish 3.1 + Weld 1.1.0 + JSF2
Mojarra 2.1.0
Reporter: Edilmar Alves
Priority: Critical
Original Estimate: 4 weeks
Remaining Estimate: 4 weeks
I have a @Named/@ConversationScoped managed bean with a method to call a
webservice/SOAP1.1.
If I change the managed bean to @ManagedBean, the method works fine. And with
NetBeans 6.9.1 + GlassFish 3.0.1 + Weld 1.0.0 it works fine. But in this new
environment, Weld arises this error:
INFO: WSP5018: Loaded WSIT configuration from file:
file:/sistemas/sitesat2/build/web/WEB-INF/classes/META-INF/wsit-client.xml.
INFO: Missing required extension methods detected on
'javax.transaction.TransactionManager' implementation
'com.sun.enterprise.transaction.TransactionManagerHelper':
getTxLogLocation
INFO: WSATGatewayRM.initStore path:null/../wsat/inbound/
INFO: WSATGatewayRM.initStore path:null/../wsat/outbound/
INFO: the effective transaction attribute for operation' getCidadeCodIBGE' is
: enabled(false),required(false), version(WSAT10).
INFO: WS-AT recovery is enabled but WS-AT is not ready for runtime.
Processing WS-AT recovery log files...
INFO: recover() flag=25165824
INFO: recover() for this server flag=25165824
txlogdirOutbound:null/../wsat/outbound/,txlogdirInbound:null/../wsat/inbound/
INFO: recoverPendingBranches outbound directory:null/../wsat/outbound/
INFO: recoverPendingBranches inbound directory:null/../wsat/inbound/
INFO: WSAT recover(25165824) returning []
INFO: WS-AT activityId:[B@1bfbc471
INFO: WSAT4575: WS-AT transaction id is '4D2-313330333234363739323134372D30'
and time to live is '0' for transaction 'suspendedTransaction' on thread
Thread[http-thread-pool-8080(2),5,grizzly-kernel]
INFO: WSAT4575: WS-AT transaction id is '4D2-313330333234363739323134372D30'
and time to live is '0' for transaction 'suspendedTransaction' on thread
Thread[http-thread-pool-8080(2),5,grizzly-kernel]
INFO: WSAT4568: Client-side outbound application message after adding
transaction context for 'suspendedTransaction'
INFO: WSAT4577: About to suspend transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4578: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4569: Client-side inbound message received
INFO: WSAT4570: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' will be resumed on
thread 'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
INFO: WSAT4571: Suspended transaction 'JavaEETransactionImpl: txId=29
nonXAResource=null jtsTx=null localTxStatus=0 syncs=[]' resumed on thread
'Thread[http-thread-pool-8080(2),5,grizzly-kernel]'
AVISO: #{cidade.getCidadeCodIBGE}: javax.xml.ws.soap.SOAPFaultException:
java.lang.NullPointerException
javax.faces.FacesException: #{cidade.getCidadeCodIBGE}:
javax.xml.ws.soap.SOAPFaultException: java.lang.NullPointerException
at
com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1259)
at
com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at
org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215)
at
util.OpenSessionInViewFilter.doFilter(OpenSessionInViewFilter.java:42)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-778) Weld must be able to support extension discovery in the modules of an multi-module application (EAR)
[ https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12597038#comment-12597038 ] Pete Muir commented on WELD-778: We can't solve this with the current SPI AFAICS. We need to completely revisit how extensions are processed. I admit that when I wrote this originally, the stuff I did with classloading/structure seemed a little bit odd, and I think I just didn't see that extensions need to be per bda and call events for any bean on extensions defined in that bda for any classes that are resolvable. The primary issue I wanted to avoid with the previous design was that events would be called multiple times for the same bean/class on the same extension, however if we only ever call events on extensions within the bda then I think this won't be a problem. I would propose we redesign the SPI so that loadExtensions is per BDA not per app. Weld must be able to support extension discovery in the modules of an multi-module application (EAR) Key: WELD-778 URL: https://issues.jboss.org/browse/WELD-778 Project: Weld Issue Type: Feature Request Components: Bootstrap and Metamodel API Affects Versions: 1.1.0.Beta2 Reporter: Marius Bogoevici Fix For: TBC Currently, only extensions which are visible to the entire application (i.e. all modules) are installed. -- 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] Assigned: (CDITCK-210) org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface
[ https://issues.jboss.org/browse/CDITCK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned CDITCK-210: Assignee: Jozef Hartinger org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull (Stateful session bean) 's @Remove method not part of EJB's business interface -- Key: CDITCK-210 URL: https://issues.jboss.org/browse/CDITCK-210 Project: CDI TCK Issue Type: Bug Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Environment: Generic Java Platform Reporter: Bob Nettleton Assignee: Jozef Hartinger A Stateful session bean defined in the following test suite: org.jboss.jsr299.tck.tests.implementation.enterprise.definition includes a @Remove method that is not part of the Session Bean's Business interface. The bean in question is: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.Pitbull According to the javadoc for the Remove annotation: http://download.oracle.com/javaee/6/api/javax/ejb/Remove.html This annotation must be placed on a method that is also a part of the Session Bean's business interface. This issue can cause problems with the portability of this test application and test suite, since different application servers may fail at deployment time with this type of EJB-related error. I request that either the Session Bean be modified to add this method to the business interface, or that the tests listed below be removed from the TCK: org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testStatelessMustBeDependentScoped [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanViaXmlTest.testEjbDeclaredInXmlNotSimpleBean [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithDependentScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testEnterpriseBeanClassLocalView [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testObjectIsInAPITypes [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithStereotype [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testDefaultName [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithNamedAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithQualifiers [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanWithScopeAnnotation [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testSingletonWithApplicationScopeOK [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testBeanTypesAreLocalInterfacesWithoutWildcardTypesOrTypeVariablesWithSuperInterfaces [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testConstructorAnnotatedInjectCalled [testng] org.jboss.jsr299.tck.tests.implementation.enterprise.definition.EnterpriseBeanDefinitionTest.testRemoteInterfacesAreNotInAPITypes Another test suite: org.jboss.jsr299.tck.tests.context.dependent.ejb also has this problem in the following Stateful session EJB: org.jboss.jsr299.tck.tests.context.dependent.ejb.Fox In addition to the list above, the following tests also appear to be affected by this issue: org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependentSimples [testng] org.jboss.jsr299.tck.tests.context.dependent.ejb.DependentContextEjbTest.testDestroyingEjbDestroysDependents -- 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-886) AbstractContext creationLock deadlock
[ https://issues.jboss.org/browse/WELD-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596017#comment-12596017 ] Pete Muir commented on WELD-886: Yes, this didn't get fixed when Oracle contributed the shared library mode to Weld. We should address this asap... I have no idea why the lock is static, it should be instance based. AbstractContext creationLock deadlock - Key: WELD-886 URL: https://issues.jboss.org/browse/WELD-886 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Environment: glassfish Reporter: MIchail Nikolaev Labels: AbstractContext, applicationscoped, deadlock AbstractContext.creationLock same for all applications on same server. I have portlet and webservice deployed on same glassfish server. On start of portlet the call to managed bean (@ApplicationScoped) is occured (FolderService.getRootFolder). It causes to lock creationLock in AbstractContext, create instance for bean, then call getRootFolder as default postconstruct method. After getRootFolder calls webservice deployed on the same server. Webservice method access another @ApplicationScoped bean. It causes to lock creationLock again (in another thread) and produces deadlock. Thanks. -- 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: (CDITCK-209) TCK tests should not cleanup app context explicitly
[ https://issues.jboss.org/browse/CDITCK-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12595008#comment-12595008 ] Pete Muir commented on CDITCK-209: -- Yes, others are fine. TCK tests should not cleanup app context explicitly --- Key: CDITCK-209 URL: https://issues.jboss.org/browse/CDITCK-209 Project: CDI TCK Issue Type: Task Security Level: Public(Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Ales Justin Assignee: Jozef Hartinger Fix For: 1.1.0.CR1 Atm org.jboss.jsr299.tck.tests.context.DestroyForSameCreationalContext2Test cleans up app context, which breaks context lifecycle handling asymmetry. See WELD-858 for the use case. -- 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=12591127#comment-12591127 ] Pete Muir commented on WELD-80: --- Should still just work I think without any spec language, but would be worth testing... Did you take a look at our test, can you enhance it to show your issue? Or add another one? If you set the timeouts very low (there are annotations for the passivation timeout) and use a thread.sleep it should work (albeit it is very fragile). 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=12589709#comment-12589709 ] Pete Muir commented on WELD-80: --- I don't think there is any spec issue here, a passivated EJB with CDI services should just work. All the spec could add would be it should work. What were you thinking of explicitly? 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-871) Publish snapshots for weld-osgi-bundle
[ https://issues.jboss.org/browse/WELD-871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589286#comment-12589286 ] Pete Muir commented on WELD-871: Just need to add -Pbundles to the build command... Publish snapshots for weld-osgi-bundle -- Key: WELD-871 URL: https://issues.jboss.org/browse/WELD-871 Project: Weld Issue Type: Feature Request Components: GlassFish Integration Affects Versions: 1.1.0.Final Reporter: Dan Allen Priority: Minor It appears that the snapshots for the weld-osgi-bundle are not being published to the JBoss snapshots repository: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jboss/weld/ The main weld artifacts are there, so it's clear that this is just the case of a missing artifact. -- 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-867) bean implementations should be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589294#comment-12589294 ] Pete Muir commented on WELD-867: Personally I don't think there is any reason to make Bean implement serializable, it's better to use the spec defined mechanism of getPassivationCapableBean bean implementations should be serializable --- Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that beans are serializable. - one of the following classes should implement java.io.Serializable https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/RIBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/AbstractBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/ManagedBean.java -- 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] Updated: (WELD-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated WELD-867: --- Summary: CreationalContext implementations need to be serializable (was: bean implementations should be serializable) Description: for custom scope implementations it's required that the creationalcontext is serializable. (was: for custom scope implementations it's required that beans are serializable. - one of the following classes should implement java.io.Serializable https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/RIBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/AbstractBean.java https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/ManagedBean.java) CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- 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-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589300#comment-12589300 ] Pete Muir commented on WELD-867: Ok, I retitled the issue. Mark, AFAICS Weld's CC impl is serializable as long as the Bean implements PassivationCapable and the bean impl is serializable. Isn't the real issue here that the Bean passed to a custom Context impl by Weld isn't serializable? I think what we discussed before on IRC is having Weld wrap this bean if passed to custom context in a serializable wrapper that knows how to serialize/deserialize as you and Stuart discussed. CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- 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-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589323#comment-12589323 ] Pete Muir commented on WELD-867: Bean has never been Serializable in any final release of Weld, of this I am sure :-) Agreed on the CC stuff. CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- 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-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589330#comment-12589330 ] Pete Muir commented on WELD-867: Yes, this is the one that is used to wrap all Beans inside the built in Context implementations. This was in Weld 1.0 and is in Weld 1.1... The built in Bean objects are not serializable, and the wrapping has always happened inside the Context. CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- 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-867) CreationalContext implementations need to be serializable
[ https://issues.jboss.org/browse/WELD-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589335#comment-12589335 ] Pete Muir commented on WELD-867: Nope, in Weld 1.0 this work was done inside the Context object -- http://anonsvn.jboss.org/repos/weld/core/tags/1.0.0/impl/src/main/java/org/jboss/weld/context/AbstractMapContext.java and look at getBeans() in http://anonsvn.jboss.org/repos/weld/core/tags/1.0.0/impl/src/main/java/org/jboss/weld/BeanManagerImpl.java CreationalContext implementations need to be serializable - Key: WELD-867 URL: https://issues.jboss.org/browse/WELD-867 Project: Weld Issue Type: Feature Request Components: Built-in beans, Clustering, Scopes Contexts Affects Versions: 1.1.0.Final Reporter: Gerhard Petracek Fix For: 1.2.0.Beta1 for custom scope implementations it's required that the creationalcontext is serializable. -- 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=12589377#comment-12589377 ] Pete Muir commented on WELD-80: --- John, we think with AS6 Final this should be much improved. Could you give it a spin and let us know what issues you hit? 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-860) Fired events are observed by any match.
[ https://issues.jboss.org/browse/WELD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584710#comment-12584710 ] Pete Muir commented on WELD-860: This is per the spec - see http://docs.jboss.org/cdi/spec/1.0/html/events.html#d0e6742. There is however some contradictory statements in the spec (see CDI-7), but all evidence points towards this behavior being desired. 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] Closed: (WELD-860) Fired events are observed by any match.
[ https://issues.jboss.org/browse/WELD-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir closed WELD-860. -- Assignee: Pete Muir Resolution: Rejected Behavior is correct per the spec. 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 Assignee: Pete Muir 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-855) Error while catching NonexistentConversationException with Seam Faces/Catch
[
https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584416#comment-12584416
]
Pete Muir commented on WELD-855:
Ok, that last comment is the uesful one. Can you switch out the stack traces
etc. to show it without any authz in the way?
Error while catching NonexistentConversationException with Seam Faces/Catch
---
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's
WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles
CaughtExceptionNonexistentConversationException t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---
java.lang.RuntimeException: Exception invoking method [conversationExpired]
on object
[ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c],
using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at
org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at
org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at
org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at
org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at
org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-855) Error while catching NonexistentConversationException with Seam Faces/Catch
[
https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12582314#comment-12582314
]
Pete Muir commented on WELD-855:
Sorry, got confused with method names. Can you check that it is specifically
called for the form auth forward, not for the original request. Assuming you
are coming from a JSF page I think you should see it hit twice.
Error while catching NonexistentConversationException with Seam Faces/Catch
---
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's
WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles
CaughtExceptionNonexistentConversationException t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---
java.lang.RuntimeException: Exception invoking method [conversationExpired]
on object
[ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c],
using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at
org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at
org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at
org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at
org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at
org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-855) Error while catching NonexistentConversationException with Seam Faces/Catch
[
https://issues.jboss.org/browse/WELD-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581991#comment-12581991
]
Pete Muir commented on WELD-855:
Brian, this looks like the age old problem of the contexts not being properly
set up inside servlet forwards, which I thought we were past. It's look like
you are using form auth below? Can you debug and see if the
WeldListener.beginRequest is properly invoked for this request?
Error while catching NonexistentConversationException with Seam Faces/Catch
---
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's
WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles
CaughtExceptionNonexistentConversationException t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---
java.lang.RuntimeException: Exception invoking method [conversationExpired]
on object
[ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c],
using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at
org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at
org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at
org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at
org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at
org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at
org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at
org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at
org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at
org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at
org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at
org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at
org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at
org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at
org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at
org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at
com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at
[weld-issues] [JBoss JIRA] Commented: (WELD-853) @AroundInvoke annotations added by SPI are ignored
[ https://issues.jboss.org/browse/WELD-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581049#comment-12581049 ] Pete Muir commented on WELD-853: Looks like this happened during the big switchover to Arquillian, and I mistracked what the test should look like or something - probably due to a lack of comments and commneted out code (which always looks like a mistake). If it needs to be changed to something else, thats fine. @AroundInvoke annotations added by SPI are ignored -- Key: WELD-853 URL: https://issues.jboss.org/browse/WELD-853 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Final Reporter: Stuart Douglas Assignee: Pete Muir There should be a test for this however it has been reverted by this commit: https://github.com/weld/core/commit/562d55d27938f01b9f1a793f161540f681d51f47 -- 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] Assigned: (WELD-853) @AroundInvoke annotations added by SPI are ignored
[ https://issues.jboss.org/browse/WELD-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir reassigned WELD-853: -- Assignee: (was: Pete Muir) @AroundInvoke annotations added by SPI are ignored -- Key: WELD-853 URL: https://issues.jboss.org/browse/WELD-853 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Final Reporter: Stuart Douglas There should be a test for this however it has been reverted by this commit: https://github.com/weld/core/commit/562d55d27938f01b9f1a793f161540f681d51f47 -- 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] Updated: (CDI-86) Support firing general purpose lifecycle events in Java EE environments
[ https://issues.jboss.org/browse/CDI-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-86: - Summary: Support firing general purpose lifecycle events in Java EE environments (was: Support startup beans) Support firing general purpose lifecycle events in Java EE environments --- Key: CDI-86 URL: https://issues.jboss.org/browse/CDI-86 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir -- 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: (CDI-86) Support startup beans
Support startup beans - Key: CDI-86 URL: https://issues.jboss.org/browse/CDI-86 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir -- 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: (CDI-87) Declarative control over classes including in bean archive scanning
Declarative control over classes including in bean archive scanning --- Key: CDI-87 URL: https://issues.jboss.org/browse/CDI-87 Project: CDI Specification Issues Issue Type: Feature Request Reporter: Pete Muir Weld introduced a XML syntax for this -- 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] Updated: (CDI-82) Clarify the usage of EJB3 interceptors as managed beans
[ https://issues.jboss.org/browse/CDI-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-82: - Component/s: Beans Interceptors Java EE integration Clarify the usage of EJB3 interceptors as managed beans --- Key: CDI-82 URL: https://issues.jboss.org/browse/CDI-82 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans, Interceptors, Java EE integration Affects Versions: 1.0 Reporter: Marius Bogoevici Fix For: 1.1 Background: http://lists.jboss.org/pipermail/weld-dev/2010-April/002484.html -- 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] Updated: (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-3: Component/s: Portable Extensions Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes Key: CDI-3 URL: https://issues.jboss.org/browse/CDI-3 Project: CDI Specification Issues Issue Type: Feature Request Components: Portable Extensions Affects Versions: 1.0 Reporter: Stuart Douglas At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes. Some of the things that the bean interface will not let you mimic are: - Interceptors - Disposal methods - Producer fields for normal scoped beans -- 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] Updated: (CDI-2) Interceptor bindings defined at method level should override those at the class level
[ https://issues.jboss.org/browse/CDI-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-2: Component/s: Interceptors Interceptor bindings defined at method level should override those at the class level - Key: CDI-2 URL: https://issues.jboss.org/browse/CDI-2 Project: CDI Specification Issues Issue Type: Bug Components: Interceptors Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 We certainly *intended* for method-level interceptor bindings to override bindings declared at the class level, but whether we actually wrote that down is another story. It certainly doesn't look like that behavior is properly defined in the latest version of the spec. In section 9.5.2 of the spec: If the set of interceptor bindings of a bean or interceptor, including bindings inherited from stereotypes and other interceptor bindings, has two instances of a certain interceptor binding type and the instances have different values of some annotation member, the container automatically detects the problem and treats it as a definition error. -- 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] Updated: (CDI-71) Make it possible to obtain the qualifiers used when the currently observed event was fired
[ https://issues.jboss.org/browse/CDI-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-71: - Affects Version/s: 1.0 Make it possible to obtain the qualifiers used when the currently observed event was fired -- Key: CDI-71 URL: https://issues.jboss.org/browse/CDI-71 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-39) Add a standard format for defining metadata about extensions
[ https://issues.jboss.org/browse/CDI-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-39: - Affects Version/s: 1.0 Add a standard format for defining metadata about extensions Key: CDI-39 URL: https://issues.jboss.org/browse/CDI-39 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir e.g. add optional name, description and version fields to an optional annotation. Makes it easy for modules to track what is being loaded -- 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] Updated: (CDI-48) Global Interceptor/Decorator ordering
[ https://issues.jboss.org/browse/CDI-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-48: - Affects Version/s: 1.0 Global Interceptor/Decorator ordering - Key: CDI-48 URL: https://issues.jboss.org/browse/CDI-48 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas Currently interceptor/decorator ordering is specified on a per bean archive level. In the majority of cases the correct ordering is the same for every BDA in the application, so this violates DRY and opens the door to nasty bugs due to different ordering per module if beans.xml files get out of sync. We should look at allowing the user to define interceptor and decorator ordering once per app and have this applied to all modules in the deployment. -- 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] Updated: (CDI-9) Interceptors are not applied to custom bean types
[ https://issues.jboss.org/browse/CDI-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-9: Affects Version/s: 1.0 Interceptors are not applied to custom bean types - Key: CDI-9 URL: https://issues.jboss.org/browse/CDI-9 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas Beans added through the SPI do not have interceptors applied. Even though bean does not have a getInterceptorBindings() method, interceptors applied to stereotypes should still work. -- 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] Updated: (CDI-45) Optional Injection Points
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-45: - Affects Version/s: 1.0 Optional Injection Points - Key: CDI-45 URL: https://issues.jboss.org/browse/CDI-45 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas There are occoasions where it may be useful for some injection points to be optional, e.g. @Inject @Optional MyBean bean; This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified. -- 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] Updated: (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-44: - Affects Version/s: 1.0 Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation - Key: CDI-44 URL: https://issues.jboss.org/browse/CDI-44 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not. When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification. -- 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] Updated: (CDI-57) Clarify that not all classes in a bean archive are bean classes
[ https://issues.jboss.org/browse/CDI-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-57: - Affects Version/s: 1.0 Clarify that not all classes in a bean archive are bean classes --- Key: CDI-57 URL: https://issues.jboss.org/browse/CDI-57 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir We should be clearer and say that you can put non-bean classes (e.g.MDBs) in a bean archive. -- 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] Updated: (CDI-52) Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean
[ https://issues.jboss.org/browse/CDI-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-52: - Affects Version/s: 1.0 Make it clearer that an InjectionPoint injected into a disposer method refers to the producer method bean and not to the declaring bean --- Key: CDI-52 URL: https://issues.jboss.org/browse/CDI-52 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-8) Decorators are not applied to custom beans
[ https://issues.jboss.org/browse/CDI-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-8: Affects Version/s: 1.0 Decorators are not applied to custom beans -- Key: CDI-8 URL: https://issues.jboss.org/browse/CDI-8 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas Beans added with AfterBeanDiscovery.addBean() do not have decorators applied -- 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] Updated: (CDI-73) Specify that the BM should be available from the Servlet context for ease of access
[ https://issues.jboss.org/browse/CDI-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-73: - Affects Version/s: 1.0 Specify that the BM should be available from the Servlet context for ease of access --- Key: CDI-73 URL: https://issues.jboss.org/browse/CDI-73 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-40) XSD missing enable element
[ https://issues.jboss.org/browse/CDI-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-40: - Affects Version/s: 1.0 XSD missing enable element -- Key: CDI-40 URL: https://issues.jboss.org/browse/CDI-40 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Jason Porter Assignee: Pete Muir Section 12.3 says there's an enable element, it's not there in the XSD. -- 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] Updated: (CDI-28) Abstract methods on decorators
[ https://issues.jboss.org/browse/CDI-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-28: - Affects Version/s: 1.0 Abstract methods on decorators -- Key: CDI-28 URL: https://issues.jboss.org/browse/CDI-28 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir If a method is abstract: * if it is a method of a decorated type, it has a generated implementation that calls the delegate * otherwise, definition error -- 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] Updated: (CDI-27) Support declarative transactions on managed beans
[ https://issues.jboss.org/browse/CDI-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-27: - Affects Version/s: 1.0 Support declarative transactions on managed beans - Key: CDI-27 URL: https://issues.jboss.org/browse/CDI-27 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-60) In lifecycle chapter, clarify creation of interceptors/decorator
[ https://issues.jboss.org/browse/CDI-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-60: - Affects Version/s: 1.0 In lifecycle chapter, clarify creation of interceptors/decorator Key: CDI-60 URL: https://issues.jboss.org/browse/CDI-60 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-16) Improve EE 6 Managed Bean integration
[ https://issues.jboss.org/browse/CDI-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-16: - Affects Version/s: 1.0 Improve EE 6 Managed Bean integration - Key: CDI-16 URL: https://issues.jboss.org/browse/CDI-16 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir Fix For: 1.1 Try to work out if we can improve on this. At least, we should clarify what happens if a CDI managed bean is annotated with @ManagedBean -- 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] Updated: (CDI-69) Clarify that POST_ACTIVATE and PRE_PASSIVATE on InterceptorType are only for EJBs
[ https://issues.jboss.org/browse/CDI-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-69: - Affects Version/s: 1.0 Clarify that POST_ACTIVATE and PRE_PASSIVATE on InterceptorType are only for EJBs - Key: CDI-69 URL: https://issues.jboss.org/browse/CDI-69 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-75) Clarify what happens to a bean which belongs to inactive when it observes an event
[ https://issues.jboss.org/browse/CDI-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-75: - Affects Version/s: 1.0 Clarify what happens to a bean which belongs to inactive when it observes an event -- Key: CDI-75 URL: https://issues.jboss.org/browse/CDI-75 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-25) Support @Inject FacesContext facesContext;
[ https://issues.jboss.org/browse/CDI-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-25: - Affects Version/s: 1.0 Support @Inject FacesContext facesContext; -- Key: CDI-25 URL: https://issues.jboss.org/browse/CDI-25 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-68) Clarify that there is only one instance of a Context object per application deployment for built in contexts
[ https://issues.jboss.org/browse/CDI-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-68: - Affects Version/s: 1.0 Clarify that there is only one instance of a Context object per application deployment for built in contexts Key: CDI-68 URL: https://issues.jboss.org/browse/CDI-68 Project: CDI Specification Issues Issue Type: Bug Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-34) Make special note in the spec about beans that are @Named via a stereotype being unselectable with Instance.select()
[
https://issues.jboss.org/browse/CDI-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pete Muir updated CDI-34:
-
Affects Version/s: 1.0
Make special note in the spec about beans that are @Named via a stereotype
being unselectable with Instance.select()
Key: CDI-34
URL: https://issues.jboss.org/browse/CDI-34
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 1.0
Reporter: Shane Bryzak
Priority: Minor
For example, say we have the following bean:
public @Model class Foo implements IFoo { }
And we have the following injection point within another bean:
@Inject InstanceFoo fooInstance;
It is not possible to select Foo via name using the Instance:
// This results in an UnsatisfiedDependencyException
Foo foo = fooInstance.select(new NamedLiteral(foo)).get();
Instead, Foo must be annotated directly with the @Named annotation itself:
/*
* This Foo can be selected by name
*/
public @Named @RequestScoped Foo implements IFoo { }
This special case might be worthwhile mentioning in the next revision of the
spec.
--
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] Updated: (CDI-24) Make it easier to build passivating contexts by making sure Contextual objects passed to them are serializable
[ https://issues.jboss.org/browse/CDI-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-24: - Affects Version/s: 1.0 Make it easier to build passivating contexts by making sure Contextual objects passed to them are serializable -- Key: CDI-24 URL: https://issues.jboss.org/browse/CDI-24 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir OWB ensures that any Contextual impl passed to a passivating context is serializable, making it much easier to impl a custom passivating context. We should probably make this required by the spec. -- 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] Updated: (CDI-46) Clarify in the specification that extensions do not require a beans.xml file
[ https://issues.jboss.org/browse/CDI-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-46: - Affects Version/s: 1.0 Clarify in the specification that extensions do not require a beans.xml file Key: CDI-46 URL: https://issues.jboss.org/browse/CDI-46 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Shane Bryzak -- 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] Updated: (CDI-80) Support conversations in Servlet
[ https://issues.jboss.org/browse/CDI-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-80: - Affects Version/s: 1.0 Support conversations in Servlet Key: CDI-80 URL: https://issues.jboss.org/browse/CDI-80 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Pete Muir -- 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] Updated: (CDI-47) Add required attribute to interceptor tag in beans.xml
[ https://issues.jboss.org/browse/CDI-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-47: - Affects Version/s: 1.0 Add required attribute to interceptor tag in beans.xml - Key: CDI-47 URL: https://issues.jboss.org/browse/CDI-47 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Stuart Douglas Currently the deployment will fail if an interceptor is not present, which means that it is not conventient to use interceptors from optional modules, as the end user will need to open up the jar file and edit the beans.xml file manually. Adding a required=true|false attribute to the interceptor element in beans.xml would allow an archive to specify that the interceptor is not essential, and if it is not found it should simply be ignored. For example, currently Seam Security has a hard dependency on Seam Persistence because it uses the Transaction interceptor, and the deployment will fail if Seam Persistence is not present. -- 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] Updated: (CDI-36) ObserverMethod.notify() does not forward qualifiers for Event
[ https://issues.jboss.org/browse/CDI-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Muir updated CDI-36: - Affects Version/s: 1.0 ObserverMethod.notify() does not forward qualifiers for Event - Key: CDI-36 URL: https://issues.jboss.org/browse/CDI-36 Project: CDI Specification Issues Issue Type: Feature Request Affects Versions: 1.0 Reporter: Jordan Ganoff There's currently no way to get the qualifiers for a fired event. ObserverMethod.notify() only passes the event object itself. Without the qualifiers it is difficult to bridge the gap between CDI events and some other event infrastructure (e.g. JMS). -- 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
