January 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-829) Failed to run examples according to readme

by Ondrej Skutka (JIRA)

Failed to run examples according to readme ------------------------------------------ Key: WELD-829 URL: https://issues.jboss.org/browse/WELD-829 Project: Weld Issue Type: Bug Components: Examples Reporter: Ondrej Skutka Priority: Trivial There are several readme documents in the weld examples directory: /README.md /jsf/numberguess/README.md /jsf/pastecode/readme.txt /jsf/permalink/readme.txt /se/numberguess/readme.txt /se/hello-world/readme.txt Running the examples using instructions in /README.md fails on pastecode example not having JBOSS_HOME property set (should be mentioned in the readme). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
3
0 / 0

[JBoss JIRA] Created: (WELD-828) Clustering numberguess example doesn't work

by Ondrej Skutka (JIRA)

Clustering numberguess example doesn't work ------------------------------------------- Key: WELD-828 URL: https://issues.jboss.org/browse/WELD-828 Project: Weld Issue Type: Bug Components: Clustering, Examples Affects Versions: 1.1.0.Final Environment: JBoss 6.0.0.Final Reporter: Ondrej Skutka - Created cluster according to the readme - Ran "mvn -Pjboss6cluster,ftest-jboss-cluster-6" - The test failed: FAILED: guessingWithFailoverTest java.lang.AssertionError: Page should contain message Higher! expected:<true> but was:<false> at org.jboss.weld.examples.numberguess.clustertest.selenium.NumberGuessClusteringTest.guessingWithFailoverTest(NumberGuessClusteringTest.java:123) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74) at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) And indeed, when running manually and shutting down one of the nodes in cluster, it failes to synchronize the session: 13:39:03,909 WARN [org.jboss.web.tomcat.service.session.distributedcache.ispn.DistributedCacheManager] Problem accessing session [3V****vgLw__]: org.jboss.weld.exceptions.IllegalStateException: WELD-000612 Unable to deserialize field. Declaring bean id org.jboss.weld.bean-jboss.classloader:id="vfs:///home/ony/Programming/jboss-6.0.0.Final/server/all/farm/weld-numberguess.war"-ManagedBean-class org.jboss.weld.examples.numberguess.Game, declaring class public@SessionScoped @Named class org.jboss.weld.examples.numberguess.Game, field name randomNumber -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Updated: (CDITCK-204) TCK Harness property configuration broken

by Sivakumar Thyagarajan (JIRA)

[ https://issues.jboss.org/browse/CDITCK-204?page=com.atlassian.jira.plugin... ] Sivakumar Thyagarajan updated CDITCK-204: ----------------------------------------- Affects Version/s: 1.0.4.CR2 Component/s: Infrastructure > TCK Harness property configuration broken > ----------------------------------------- > > Key: CDITCK-204 > URL: https://issues.jboss.org/browse/CDITCK-204 > Project: CDI TCK > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Infrastructure > Affects Versions: 1.0.4.CR2 > Reporter: Sivakumar Thyagarajan > > As per http://docs.jboss.org/cdi/tck/reference/latest/en-US/html/test-harness-co..., a custom ConfigurationBuilder or an implementation of the SPI class such as org.jboss.jsr299.tck.spi.Beans could be provided by the TCK executor through a system property specifying the FQCN of the implementation class. > However while trying to plug in a custom Beans SPI implementation or a ConfigurationBuilder using the system property, the default PropertiesBasedConfigurationBuilder seems to collate [1] all the properties file in the classpath and include the default implementations (bundled in the porting package or harness) as well. > > [testng] Exception in thread "main" java.lang.IllegalArgumentException: More than one implementation of Beans specified by org.jboss.jsr299.tck.spi.Beans, not sure which one to use! > > [testng] at org.jboss.testharness.properties.PropertiesManager.getClassValue(PropertiesManager.java:159) > > [testng] at org.jboss.testharness.properties.PropertiesManager.getInstanceValue(PropertiesManager.java:169) > > [testng] at org.jboss.testharness.impl.PropertiesBasedConfigurationBuilder.getInstanceValue(PropertiesBasedConfigurationBuilder.java:62) > This prevents configuration of the TCK to use a custom SPI class implementation and/or ConfigurationBuilder. The only workaround seems to be providing a modified version of the existing porting package class and ensuring that it is loaded ahead. > [1] > [1] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (WELD-819) Fix for WELD-812 introduced a performance regression to Weld

by Martin Gencur (JIRA)

Fix for WELD-812 introduced a performance regression to Weld ------------------------------------------------------------ Key: WELD-819 URL: https://issues.jboss.org/browse/WELD-819 Project: Weld Issue Type: Bug Components: Conversations Reporter: Martin Gencur Assignee: Pete Muir Fix For: 1.1.0.CR4 This particular commit introduced a perf. regression: WELD-812 , hash: df3c26d42fe387f549ff ( https://github.com/weld/core/commit/df3c26d42fe387f549ff1a433666abd3520cc609 ) A stress test now reaches only 10500 sessions while it was 12900 sessions before and the response times are higher too. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (WELD-812) Session serialization fails because of non-serializable org.jboss.weld.injection.SimpleInjectionPoint

by Sivakumar Thyagarajan (JIRA)

Session serialization fails because of non-serializable org.jboss.weld.injection.SimpleInjectionPoint ----------------------------------------------------------------------------------------------------- Key: WELD-812 URL: https://issues.jboss.org/browse/WELD-812 Project: Weld Issue Type: Bug Components: Conversations Affects Versions: 1.1.0.CR2 Reporter: Sivakumar Thyagarajan Fix For: 1.1.0.Final Our HA session serialization and failure testcase fails from the RC2 integration. This test case used to pass earlier(with BETA2). It appears that since Weld 1.1.0.RC2, the session has a non-serializable SimpleInjectionPoint in its closure of references that prevents serialization of the session. Please see the GlassFish issue http://java.net/jira/browse/GLASSFISH-15278 for more information. This prevents our HA failover scenarios. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

3
9
0 / 0

[JBoss JIRA] Updated: (CDI-34) Make special note in the spec about beans that are @Named via a stereotype being unselectable with Instance.select()

by Shane Bryzak (JIRA)

[ https://issues.jboss.org/browse/CDI-34?page=com.atlassian.jira.plugin.sys... ] Shane Bryzak updated CDI-34: ---------------------------- Summary: Make special note in the spec about beans that are @Named via a stereotype being unselectable with Instance.select() (was: Make special note in the spec about @Named beans (via a stereotype) cannot be selected with Instance.select()) > 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 > 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 Instance<Foo> 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

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (CDITCK-203) InvocationContextTest:testGetTarget

by Scott Ferguson (JIRA)

InvocationContextTest:testGetTarget ----------------------------------- Key: CDITCK-203 URL: https://issues.jboss.org/browse/CDITCK-203 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.CR2 Reporter: Scott Ferguson This test has a implementation-dependency on how interception is implemented (requires proxy implementation), but the proxy implementation is not mandated by the spec (and the EJB spec has always allowed both implementation methods.) The test calls SimpleBean.getId(), which is intercepted by Interceptor1. Interceptor1's aroundInvoke calls target.getId(), which is a circular reference for extension and only works for proxy-based interception: class SimpleBean { @Interceptors(Interceptor1.class) public int getId() { return id; } ... } class Interceptor1 { @AroundInvoke public Object aroundInvoke(InvocationContext ctx) throws Exception { SimpleBean target = (SimpleBean) ctx.getTarget(); int id1 = target.getId(); ... } } The only change needed to the test is to create a SimpleBean.getBareId() which is not an intercepted method. (Or, if the spec is re-interpreted to require a proxy implementation, there should be an explicit test for it, not an implicit dependency like this test.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

2
4
0 / 0

[JBoss JIRA] Updated: (WELD-819) Fix for WELD-812 introduced a performance regression to Weld

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/WELD-819?page=com.atlassian.jira.plugin.s... ] Pete Muir updated WELD-819: --------------------------- Fix Version/s: 1.1.0.Final (was: 1.1.0.CR4) > Fix for WELD-812 introduced a performance regression to Weld > ------------------------------------------------------------ > > Key: WELD-819 > URL: https://issues.jboss.org/browse/WELD-819 > Project: Weld > Issue Type: Bug > Components: Conversations > Reporter: Martin Gencur > Assignee: Pete Muir > Fix For: 1.1.0.Final > > > This particular commit introduced a perf. regression: > WELD-812 , hash: df3c26d42fe387f549ff > ( https://github.com/weld/core/commit/df3c26d42fe387f549ff1a433666abd3520cc609 ) > A stress test now reaches only 10500 sessions while it was 12900 sessions before and the response times are higher too. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (CDITCK-201) InjectionIntoWebServiceEndPointTest bundles incorrect artifacts

by Jozef Hartinger (JIRA)

InjectionIntoWebServiceEndPointTest bundles incorrect artifacts --------------------------------------------------------------- Key: CDITCK-201 URL: https://issues.jboss.org/browse/CDITCK-201 Project: CDI TCK Issue Type: Bug Security Level: Public (Everyone can see) Components: Tests Affects Versions: 1.0.4.CR1 Reporter: Jozef Hartinger Assignee: Jozef Hartinger Fix For: 1.0.4.Final This is a problem with TCK not bundling correct web service artifacts which causes mismatch between client and server. Service has: @WebService(name="SheepWS") public class SheepWSEndPoint { ... @WebMethod public boolean testSheepInjected() { return (sheep != null) && initializerCalled; } } WSDL is created by the runtime/tools using testSheepInjected() method. So without customizations, wsimport generates the following artifacts from that wsdl: WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/TestSheepInjected.class WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/TestSheepInjectedResponse.class But, the bundled artifacts in the war are : WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/IsSheepInjected.class WEB-INF/classes/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/ws/IsSheepInjectedResponse.class and the annotations in these classes don't reflect what WSDL has(or what service is expecting) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
4
0 / 0

[JBoss JIRA] Commented: (WELD-13) Use the builder pattern to create Bean objects

by Pete Muir (JIRA)

[ https://issues.jboss.org/browse/WELD-13?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on WELD-13: ------------------------------- Stuart, I think that this is just a design screw up in Weld. We should simply resolve decorators and interceptors at runtime. I don't see that this will be a big perf issue as we already cache resolutions for interceptors and decorators. > Use the builder pattern to create Bean objects > ---------------------------------------------- > > Key: WELD-13 > URL: https://issues.jboss.org/browse/WELD-13 > Project: Weld > Issue Type: Feature Request > Components: Class Beans (Managed and Session) > Reporter: Pete Muir > Assignee: Stuart Douglas > Priority: Critical > Fix For: 1.2.0.Beta1 > > > Currently we create the Bean objects using a two phase initialization, partly via the constructor, and partly via an initialize() method, this allows us to create the beans, attach them to the bean manager and then do further work once all bean objects exist. This has a number of problems: > 1) objects are not fully immutable which means we rely on developers ability to keep them effectively immutable > 2) the objects are a mess of init methods and getters > 3) creation logic is convoluted > It would be far better to create builders (or factories) that can create the beans as needed, this will cleanly split out the creation logic from the bean object, and allow us to create fully immutable objects, thus making it easier to verify the thread-safety of the code. > A side effect of this will be that we can't use two-phase initialization two set up certain stuff after all beans are present. To overcome this we will need to order the bean creation so that beans required by other beans are created first and thus can be attached as needed. > The rules I am aware of: > * producer methods and fields should be created after the class bean that declares them as they need to know that bean in order to be instantiated > * specialized beans need to be created in the order least specialized to most specialized as a more specialized bean needs to read the metadata of the less specialized bean -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues January 2011