August 2010 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-539) Upgrade Weld examples to use shared Jetty/Tomcat plugins

by Pete Muir (JIRA)

Upgrade Weld examples to use shared Jetty/Tomcat plugins -------------------------------------------------------- Key: WELD-539 URL: https://jira.jboss.org/browse/WELD-539 Project: Weld Issue Type: Task Components: Examples Reporter: Pete Muir Fix For: 1.0.2.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (WELD-520) Weld does not work in OSGI container's classloader (and lacks OSGI bundles by the way)

by Morten Christensen (JIRA)

Weld does not work in OSGI container's classloader (and lacks OSGI bundles by the way) -------------------------------------------------------------------------------------- Key: WELD-520 URL: https://jira.jboss.org/jira/browse/WELD-520 Project: Weld Issue Type: Bug Components: OSGi support Affects Versions: 1.0.1.Final Environment: Java SE, Weld 1.01 SE, Felix 2.02 Reporter: Morten Christensen Priority: Critical Weld SE will does not work inside an OSGI bundle. If you try to start WeldSE from within a OSGI bundle, you will get. Error loading Weld bootstrap, check that Weld is on the classpath at org.jboss.weld.environment.se.Weld.<init>(Weld.java:59) Looking at the cause, it seems org.jboss.weld.environment.se.util.Reflections only works with Thread context classloaders and plain Class.forname both of which are NO-NO in osgi. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
9
0 / 0

[JBoss JIRA] Created: (WELD-524) org.jboss.weld.environment.se.discovery.URLScanner does not work with resources inside OSGI bundles

by Morten Christensen (JIRA)

org.jboss.weld.environment.se.discovery.URLScanner does not work with resources inside OSGI bundles ---------------------------------------------------------------------------------------------------- Key: WELD-524 URL: https://jira.jboss.org/jira/browse/WELD-524 Project: Weld Issue Type: Bug Environment: JavaSE 6 + Weld SE Reporter: Morten Christensen Priority: Blocker The class org.jboss.weld.environment.se.discovery.URLScanner does no work with resources inside OSGI bundles. So if one try to start WeldSe inside an OSGI bundle and get around the classloader bug in WeldSE by tempoarily setting the ContextClassLoader you will get an NullPointerException. The problem is OSGI resource url related. For a OSGI bundle you will f.x. get "bundleresource://4.fwk1362875764:1/META-INF/beans.xml" from bundleClassLoader.getResources("META-INF/beans.xml" but this is not a valid filename as URLScanner assumes so one will get this exception: java.lang.NullPointerException at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:177) at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:183) at org.jboss.weld.environment.se.discovery.URLScanner.handleDirectory(URLScanner.java:160) at org.jboss.weld.environment.se.discovery.URLScanner.handle(URLScanner.java:122) at org.jboss.weld.environment.se.discovery.URLScanner.scanResources(URLScanner.java:107) at org.jboss.weld.environment.se.discovery.SEWeldDiscovery.scan(SEWeldDiscovery.java:71) at org.jboss.weld.environment.se.discovery.SEWeldDiscovery.<init>(SEWeldDiscovery.java:45) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (WELD-376) Callouts poorly formatted in HTML docs

by Pete Muir (JIRA)

Callouts poorly formatted in HTML docs -------------------------------------- Key: WELD-376 URL: https://jira.jboss.org/jira/browse/WELD-376 Project: Weld Issue Type: Task Components: Documentation Affects Versions: 1.0.0.GA Reporter: Jozef Hartinger Fix For: 1.0.1.CR1 Global problems - a significant number of links is missing the value of href attribute (these links point nowhere) - JBoss AS 5.2.x have become obsolete recently (changed to 6.0.0.M1) - the documentation references this obsolete version. i.e. Chapters 6, section 18.1 - there is a number of unnecessary blank pages in the PDF version - Section 2.1.2. Scope - there is a missing *want* in the Note in the sentence: "If you don't the bean to live in the session indefinitely..." - Section 6.2 Deploying to JBoss AS - there is a missing space in the sentence "Create a new file namedlocal.build.properties ..." - Section 6.2 Deploying to JBoss AS - is not finished - there is a TODO at the very end of the section - Secion 7.1. The numberguess example in depth - the numbers which mark an important line of a code sample (1), (2), etc... are broken in the second sample of the section (web.xml). They are placed on wrong places (wrong line, beggining of the line instead of end) and they are followed by "ml_plain">" in the HTML version. Besides, I would emphasize more the benefit of the typesafe resolution i.e. in section 1.2 - (that all the unsatisfied and ambiguous dependencies are discovered at the deployment time - you do not need to click anything to find out that the you set some dependencies wrong - more formal verification) - I don't say it is not there already. I just had a feeling that it is not stated explicitly enough. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (WELDX-34) Split out user API for SE module, and move to the api project/BOM

by Pete Muir (JIRA)

Split out user API for SE module, and move to the api project/BOM ----------------------------------------------------------------- Key: WELDX-34 URL: https://jira.jboss.org/jira/browse/WELDX-34 Project: Weld Extensions Issue Type: Feature Request Components: Java SE Reporter: Pete Muir We maintain a separate API project (SVN trunk etc.), BOM etc. Any developer-visible API for the SE extension (so perhaps any non-spec events you can observe?) should go here -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

3
6
0 / 0

[JBoss JIRA] Created: (WELD-629) Full review of sub-module licenses for Weld and Examples

by Pete Muir (JIRA)

Full review of sub-module licenses for Weld and Examples -------------------------------------------------------- Key: WELD-629 URL: https://jira.jboss.org/browse/WELD-629 Project: Weld Issue Type: Task Reporter: Pete Muir Assignee: Pete Muir Priority: Critical Fix For: 1.1.0.BETA2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (WELDX-51) Create a single jar file for Weld SE that includes all dependencies

by Pete Muir (JIRA)

Create a single jar file for Weld SE that includes all dependencies ------------------------------------------------------------------- Key: WELDX-51 URL: https://jira.jboss.org/jira/browse/WELDX-51 Project: Weld Extensions Issue Type: Feature Request Components: Java SE Reporter: Pete Muir Fix For: Java SE 1.0.0.CR3 To make using Weld SE easy, we should create a single jar (primarily for use at runtime, at compile time you would depend just on cdi-api of course) * cdi-api * weld-api * weld-spi * weld-core * weld-se -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

5
14
0 / 0

[JBoss JIRA] Created: (WELD-575) Definition/DeploymentExceptions thrown by an AnnotationModel are wrapped by a ComputationException

by Marius Bogoevici (JIRA)

Definition/DeploymentExceptions thrown by an AnnotationModel are wrapped by a ComputationException -------------------------------------------------------------------------------------------------- Key: WELD-575 URL: https://jira.jboss.org/browse/WELD-575 Project: Weld Issue Type: Feature Request Components: Reflection layer Affects Versions: 1.0.1.Final Reporter: Marius Bogoevici Assignee: Pete Muir Fix For: 1.1.0.BETA1 If an exception is thrown while evaluating a Function, the exception is wrapped by a ComputationException. As a result, the exceptions thrown by the AnnotationModel subclasses (Stereotype, InterceptionBinding) - which indicate a definition error detected while parsing the annotation are thrown as ComputationExceptions by the framework. An illustration for this can be found in MetaAnnotationStore.getInterceptionBindingModel, although this needs to be done in a more general fashion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

4
5
0 / 0

[JBoss JIRA] Created: (WELD-415) testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson

by Martin Gencur (JIRA)

testApplicationScopeActiveDuringCallToEjbTimeoutMethod TCK test method is failing in Hudson ------------------------------------------------------------------------------------------- Key: WELD-415 URL: https://jira.jboss.org/jira/browse/WELD-415 Project: Weld Issue Type: Bug Components: Testing Infrastructure (Mocks and Harness Integration) Affects Versions: 1.0.1.CR1 Reporter: Martin Gencur Assignee: Pete Muir Fix For: 1.0.1.CR2 Stack trace: java.lang.AssertionError at org.jboss.jsr299.tck.tests.context.application.ejb.EJBApplicationContextTest.testApplicationScopeActiveDuringCallToEjbTimeoutMethod(EJBApplicationContextTest.java:31) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
5
0 / 0

[JBoss JIRA] Created: (CDITCK-44) Test coverage files are generated in directory from which maven is run

by Karel Piwko (JIRA)

Test coverage files are generated in directory from which maven is run ---------------------------------------------------------------------- Key: CDITCK-44 URL: https://jira.jboss.org/jira/browse/CDITCK-44 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Infrastructure Affects Versions: 1.0.0.CR2 Reporter: Karel Piwko When running maven target (install) from another directory than cdi-tck root, test coverage is generated in directory from which maven was fired. This caused unexpected FileNotFound when artifacts are to be installed: [trunk]$ mvn cdi-tck/pom.xml -Dtck-audit=true clean install [INFO] Installing /home/kpiwko/devel/weld/trunk/cdi-tck/target/coverage-cdi.html to /home/kpiwko/.m2/repository/org/jboss/jsr299/tck/jsr299-tck-impl/1.0.0-SNAPSHOT/jsr299-tck-impl-1.0.0-SNAPSHOT-coverage-cdi.html [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error installing artifact: File /home/kpiwko/devel/weld/trunk/cdi-tck/target/coverage-cdi.html does not exist Target directory is generated in trunk. This bug causes problems with automatized testing on Hudson. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues August 2010