October 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-966) TCK test failure: ResolutionByNameTest#testFieldNameUsedAsBeanName()

by Martin Kouba (JIRA)

TCK test failure: ResolutionByNameTest#testFieldNameUsedAsBeanName() -------------------------------------------------------------------- Key: WELD-966 URL: https://issues.jboss.org/browse/WELD-966 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Environment: JBoss AS 7 Arquillian/TestNG Reporter: Martin Kouba Running org.jboss.jsr299.tck.tests.lookup.byname.ResolutionByNameTest#testFieldNameUsedAsBeanName() in CDI 1.1 branch fails on deployment validation: WELD-001408 Unsatisfied dependencies for type [Animal] with qualifiers [@Named] at injection point [[field] @Named @Inject private org.jboss.jsr299.tck.tests.lookup.byname.FishingNet.carp]"}} After some debugging I found out that the problem is very likely related to the way default names are handled on injection point and bean definition. Injection point: {code} @Inject @Named private Animal carp; {code} The original qualifier is replaced if no value is specified (@Named => @Named(value="carp")). See org.jboss.weld.resolution.ResolvableBuilder(InjectionPoint). Bean definition: {code} @Named public class Carp implements Animal {code} The qualifier remains the same (without value; see AbstractBean#initName()) only EL name on definition is changed. Later in org.jboss.weld.util.Beans#containsAllQualifiers() comparing the injection point new qualifier to the one on bean definition no match is found (value on @Named is binding) and thus validation fails with error message above. Related CDI spec chapters: 2.5.2 Default bean EL names 3.1.5 Default name for a managed bean 3.11 The qualifier @Named at injection points -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

6
7
0 / 0

[JBoss JIRA] Created: (WELD-948) Weld parent points to jboss nexus in repository settings

by Max Rydahl Andersen (JIRA)

Weld parent points to jboss nexus in repository settings -------------------------------------------------------- Key: WELD-948 URL: https://issues.jboss.org/browse/WELD-948 Project: Weld Issue Type: Bug Reporter: Max Rydahl Andersen Priority: Critical I was playing with mvn today and wanted to use: <dependency> <groupId>org.jboss.spec</groupId> <artifactId>jboss-javaee-6.0</artifactId> <version>1.0.0.Final</version> <type>pom</type> <scope>provided</scope> </dependency> as described on http://community.jboss.org/wiki/WhatsTheCauseOfThisExceptionJavalangClass... And I wanted to see what happens when I *only* have maven central setup. To my surprise I saw this in mvn log: Downloaded: http://repo1.maven.org/maven2/javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.... (7 KB at 10.0 KB/sec) Downloading: http://repo1.maven.org/maven2/org/jboss/weld/weld-parent/17/weld-parent-1... Downloading: https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/w... Downloaded: https://repository.jboss.org/nexus/content/groups/public/org/jboss/weld/w... (31 KB at 4.1 KB/sec) And yes it seems weld-parent explicitly lists repository.jboss.org in its parent pom forcing this repo to be used for resolving dependencies afaics. Even if I have nexus configured to control my dependencies it will visit that ;( Our pom's should not force the choice of repository. Please re-release without these references. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (WELD-947) Fix reference to other chapter (in 5.6. The @New qualifier)

by Ondrej Zizka (JIRA)

Fix reference to other chapter (in 5.6. The @New qualifier) ----------------------------------------------------------- Key: WELD-947 URL: https://issues.jboss.org/browse/WELD-947 Project: Weld Issue Type: Bug Components: Documentation Reporter: Ondrej Zizka Priority: Minor http://docs.jboss.org/weld/reference/latest/en-US/html_single/#d0e2044 At the end of "5.6. The @New qualifier", there's: {quote} This feature is particularly useful with producer methods, as we'll see in the next chapter. {quote} The next chapter is about something else. The referenced chapter is: III. Loose coupling with strong typing 8. Producer methods -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (WELD-929) Typos in documentation

by Jozef Hartinger (JIRA)

Typos in documentation ---------------------- Key: WELD-929 URL: https://issues.jboss.org/browse/WELD-929 Project: Weld Issue Type: Bug Components: Documentation Affects Versions: 1.1.1.Final Reporter: Jozef Hartinger Priority: Minor Fix For: 1.1.2.Final contexts.xml: spell check failed on 'abilty' contexts.xml: spell check failed on 'containber' contexts.xml: spell check failed on 'deactivaed' contexts.xml: spell check failed on 'discociating' contexts.xml: spell check failed on 'easiy' contexts.xml: spell check failed on 'http' (should be HTTP) contexts.xml: spell check failed on 'Http' (should be HTTP) contexts.xml: spell check failed on 'implmentations' contexts.xml: spell check failed on 'Javadoc' (should be JavaDoc) environments.xml: spell check failed on 'Programatic' environments.xml: spell check failed on 'situtations' extend.xml: spell check failed on 'dicussed' extend.xml: spell check failed on 'instatiate' extend.xml: spell check failed on 'Javadoc' gettingstarted.xml: spell check failed on 'eclispe' gettingstarted.xml: spell check failed on 'Glassfish' (should be GlassFish) injection.xml: spell check failed on 'alterative' injection.xml: spell check failed on 'ambigous' injection.xml: spell check failed on 'annotatons' injection.xml: spell check failed on 'appling' injection.xml: spell check failed on 'decare' injection.xml: spell check failed on 'prodcuer' injection.xml: spell check failed on 'refactoring' interceptors.xml: spell check failed on 'Whoah' part5.xml: spell check failed on 'Glassfish' (should be GlassFish) resources.xml: spell check failed on 'nonportable' (should be non-portable) ri-spi.xml: repeated instance(s) of 'that'. ri-spi.xml: spell check failed on 'configuation' ri-spi.xml: spell check failed on 'intercepter' ri-spi.xml: spell check failed on 'programtically' weldexamples.xml: spell check failed on 'ommitted' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

5
4
0 / 0

[JBoss JIRA] Created: (WELD-958) URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file

by Geoffrey De Smet (JIRA)

URLScanner parses the wrong META-INF/beans.xml files if the parent classloader has a META-INF/beans.xml file ------------------------------------------------------------------------------------------------------------ Key: WELD-958 URL: https://issues.jboss.org/browse/WELD-958 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Geoffrey De Smet Priority: Critical Note that WELD-714 (fixed for 1.1.0.CR1) does NOT fix this in weld 1.1.2.Final. Here's the code that causes the problem: {code} public class URLScanner { ... protected void handleArchiveByFile(File file, ...) ... { ... ZipFile zip = new ZipFile(file); Enumeration<? extends ZipEntry> entries = zip.entries(); // Replace out the default classloader with one for the zip URLClassLoader classLoader = new URLClassLoader(new URL[] { file.toURI().toURL() }); // PROBLEM PART 1: delegates first to parent classloader while (entries.hasMoreElements()) { ZipEntry entry = entries.nextElement(); String name = entry.getName(); handle(..., classLoader.getResource(name), ...); // PROBLEM PART 2: if parent classloader contains that name, the file content is ignored! } ... } ... } {code} Here's what's happens with this input: {code} file = /tmp/tomcat-embedded-6/work/arquillian-tomcat-embedded-6/localhost/guvnor-webapp-5.3.0-SNAPSHOT/WEB-INF/lib/seam-persistence-api-3.1.0.Beta2.jar classLoader = URL is file:/tmp/tomcat-embedded-6/work/arquillian-tomcat-embedded-6/localhost/guvnor-webapp-5.3.0-SNAPSHOT/WEB-INF/lib/seam-persistence-api-3.1.0.Beta2.jar for each entry, when: name = "META-INF/beans.xml" classLoader.getResource(name) = file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml // WRONG // Should be = .../seam-persistence-api-3.1.0.Beta2.jar!META-INF/beans.xml {code} As a direct result, URLScanner.handle(...) handles the same wrong META-INF/beans.xml file multiple times (one for each real META-INF/beans.xml): {code} Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml Handle file META-INF/beans.xml from file:/home/gdesmet/projects/jboss/forked-guvnor/guvnor-webapp/target/classes/META-INF/beans.xml ... {code} For more info, see this gist: https://gist.github.com/1180446 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (WELD-981) weld-core 1.1.3-SNAPSHOT depends on weld-spi 1.1.Beta2, while weld-spi 1.1.Final was releasd 4 months later

by Geoffrey De Smet (JIRA)

weld-core 1.1.3-SNAPSHOT depends on weld-spi 1.1.Beta2, while weld-spi 1.1.Final was releasd 4 months later ----------------------------------------------------------------------------------------------------------- Key: WELD-981 URL: https://issues.jboss.org/browse/WELD-981 Project: Weld Issue Type: Task Reporter: Geoffrey De Smet Priority: Minor It's wierd that the latest weld-core, wouldn't use the latest weld-spi release (which is already 9 months old anyway). The problem is in weld-core-parent's pom.xml: {code} <properties> ... <weld.api.version>1.1.Beta2</weld.api.version> </properties> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

4
3
0 / 0

[JBoss JIRA] Created: (WELD-983) Portable war: Weld deployment on JBoss AS 7 should not require to remove the WeldListener line from the web.xml

by Geoffrey De Smet (JIRA)

Portable war: Weld deployment on JBoss AS 7 should not require to remove the WeldListener line from the web.xml --------------------------------------------------------------------------------------------------------------- Key: WELD-983 URL: https://issues.jboss.org/browse/WELD-983 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Geoffrey De Smet Priority: Critical When deploying on JBoss AS 7, the web.xml can't contain this: {code} <listener> <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class> </listener> {code} When deploying on any other app servers (JBoss AS 5.1 EAP, Tomcat 6, Jetty 6, ...) that code needs to be there. This makes for an unportable wars. Maven profiles cannot fix this in many cases: - You don't want to run your build 5 times to build 5 different wars. You run it once, build a generic war and use assembly descriptors to build 5 appserver specific wars from that. - When you're using GWT, you want run in GWT-hosted mode (which uses jetty 6) a lot. So the default web.xml needs to contain it. - When you're using arquillian-jboss7 (in maven and straight for your IDE), the default web.xml should not have it. - When you're deploying a generic war to nexus, the web.xml should contain it? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

3
7
0 / 0

[JBoss JIRA] (WELD-990) Fix transactional observer methods tests

by Martin Kouba (Created) (JIRA)

Fix transactional observer methods tests ---------------------------------------- Key: WELD-990 URL: https://issues.jboss.org/browse/WELD-990 Project: Weld Issue Type: Bug Components: Events Affects Versions: 1.1.2.Final Reporter: Martin Kouba *org.jboss.weld.tests.event.observer.transactional.TransactionalObserversTest* doesn't test transactional observer methods correctly. Every observer method in *org.jboss.weld.tests.event.observer.transactional.Pomeranian* contains: {code} if (transaction.getStatus() == STATUS_NO_TRANSACTION) { setCorrectTransactionState(true); } {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] Created: (CDITCK-230) Review Weld, Seam Compatibility and OpenWebBeans test suites

by Martin Kouba (JIRA)

Review Weld, Seam Compatibility and OpenWebBeans test suites ------------------------------------------------------------ Key: CDITCK-230 URL: https://issues.jboss.org/browse/CDITCK-230 Project: CDI TCK Issue Type: Task Security Level: Public (Everyone can see) Reporter: Martin Kouba Review Weld, Seam Compatibility and OpenWebBeans test suites. Check which tests are validating bits of the CDI spec and move/extract them to CDI TCK. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (CDITCK-205) Add test to verify extensions in non-bean archives are loaded

by Dan Allen (JIRA)

Add test to verify extensions in non-bean archives are loaded ------------------------------------------------------------- Key: CDITCK-205 URL: https://issues.jboss.org/browse/CDITCK-205 Project: CDI TCK Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.Final Reporter: Dan Allen Priority: Minor Add a test to answers this question: Does an extension have to be in an bean archive in order to be loaded? Section 11.5 states: "An extension is a service provider of the service javax.enterprise.inject.spi.Extension declared in META-INF/services." If one assumes that "service provider" refers to the term defined in the jar specification [1], then one would conclude that an extension does not have to be in a bean archive to be recognized (these are orthogonal concerns). A test for this scenario is available in the OpenTCK project and may be ported to the CDI TCK. [2] [1] http://download.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Se... [2] https://github.com/opentck/javaee_cdi/tree/master/src/test/java/org/opent... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues October 2011