June 2012 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-921) Incorrect handling of business interfaces for EJBs (where defining class of business method is not the Business interface of the EJBs)

by Sivakumar Thyagarajan (JIRA)

Incorrect handling of business interfaces for EJBs (where defining class of business method is not the Business interface of the EJBs) --------------------------------------------------------------------------------------------------------------------------------------- Key: WELD-921 URL: https://issues.jboss.org/browse/WELD-921 Project: Weld Issue Type: Bug Components: Weld SPI Affects Versions: 1.1.1.Final, 1.1.0.Final Reporter: Sivakumar Thyagarajan Fix For: 1.1.2.Final This is based on the scenario described in http://java.net/jira/browse/GLASSFISH-16186 - @Named @Stateless TimeProviderImpl extends SimpleTimeProvider implements LocalTimeProvider. - SimpleTimeProvider implements TimeProvider (the latter defining some methods, the former implementing them. No annotations.) - LocalTimeProvider is @Local and also extends TimeProvider and does nothing more. So the Local Business interface is LocalTimeProvider. The following injection is performed on a SessionScoped Bean @Inject private LocalTimeProvider timeProvider1; The Weld bean proxy for the SessionBean Object reference being injected(timeProvider1) tries to get [1] the BusinessObject when a method is invoked on it. Weld seems to use [2] the declaring class of the method being invoked to determine the business interface. Though the business interface of the Bean is set to com.dummy.time.LocalTimeProvider, the class that declares the method being invoked ("getThisMonth()") is com.dummy.time.TimeProvider. Therefore, the Weld implementation calls SessionObjectReferenceImpl.getBusinessObject("com.dummy.time.TimeProvider"), which fails, as TimeProvider is not a Business interface. As per [3], the businessInterfaceType must be a type of the business interface of the bean. Is Weld incorrect in mapping the method to its declaring interface. Weld must instead use the injected type as the business interface, while trying to get the business object. [1] https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651bed9... [2]https://github.com/weld/core/blob/76c31d311cf1ff449eb2d5c80943b913651be... [3] https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

7
12
0 / 0

[JBoss JIRA] (WELD-1095) Document unsafe instantiators

by Jozef Hartinger (JIRA)

Jozef Hartinger created WELD-1095: ------------------------------------- Summary: Document unsafe instantiators Key: WELD-1095 URL: https://issues.jboss.org/browse/WELD-1095 Project: Weld Issue Type: Feature Request Components: Reflection layer Affects Versions: 1.1.6.Final Reporter: Jozef Hartinger Assignee: Ales Justin Priority: Minor Fix For: 1.2.0.Beta1 WELD-56 has been resolved a while ago however the docs still say: {quote} A future release of Weld will likely support a non-standard workaround for this limitation, using non-portable JVM APIs: Sun, IcedTea, Mac: Unsafe.allocateInstance() (The most efficient) IBM, JRockit: ReflectionFactory.newConstructorForSerialization() But we didn't get around to implementing this yet. {quote} -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] (WELD-995) The built-in InjectionTarget implementation should use getInjectionPoints()

by Jozef Hartinger (Created) (JIRA)

The built-in InjectionTarget implementation should use getInjectionPoints() --------------------------------------------------------------------------- Key: WELD-995 URL: https://issues.jboss.org/browse/WELD-995 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 1.1.2.Final Reporter: Jozef Hartinger Fix For: 1.2.0.Beta1 See CDI-178 for details. -- 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, 1 month

6
7
0 / 0

[JBoss JIRA] (WELD-1113) Specializing beans in different bean archives is still broken

by Mark Struberg (JIRA)

Mark Struberg created WELD-1113: ----------------------------------- Summary: Specializing beans in different bean archives is still broken Key: WELD-1113 URL: https://issues.jboss.org/browse/WELD-1113 Project: Weld Issue Type: Bug Reporter: Mark Struberg This is a follow up on WELD-912. It appears that this is still broken! I tried it first on glassfish-3.1.1. with an upgraded weld-osgi-bundle.1.1.7.Final. I get the following error reported: remote failure: Error occurred during deployment: Exception while loading the app : WELD-000047 Specializing bean must extend another bean: Managed Bean [class at.ac.tuwien.tiss.core.fe.codi.TissCodiWindowContextConfig] with qualifiers [@Any @Default]. Please see server.log for more details. But my class extends the parent class: public class TissCodiWindowContextConfig extends WindowContextConfig { .. The TissCodiWindowContextConfig is in my project jar, the parent class in codi-jsf.jar, both in my WEB-INF/lib folders of my webapp. -- 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, 1 month

3
6
0 / 0

[JBoss JIRA] (WELD-1145) Unsatisfied dependencies for generic type arrays

by Marek Schmidt (JIRA)

Marek Schmidt created WELD-1145: ----------------------------------- Summary: Unsatisfied dependencies for generic type arrays Key: WELD-1145 URL: https://issues.jboss.org/browse/WELD-1145 Project: Weld Issue Type: Bug Affects Versions: 1.1.8.Final Environment: JBoss AS 7.1.2.Final Reporter: Marek Schmidt Assignee: Ales Justin The following set of beans fail to deploy with {code} public class Bar<X> { public Bar(X x) { this.x = x; } public X x; } {code} {code} public class BarsProducer { private static Bar<Integer>[] bars = new Bar[]{new Bar<Integer>(new Integer(1))}; @Produces public Bar<Integer>[] getBars() { return bars; } } {code} {code} public class Foo { @Inject Bar<Integer>[] field; } {code} {noformat} 14:23:47,915 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jboss-as-helloworld.war".WeldService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jboss-as-helloworld.war".WeldService: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bar[]] with qualifiers [@Default] at injection point [[field] @Inject org.jboss.as.quickstarts.helloworld.Foo.field] at org.jboss.as.weld.services.WeldService.start(WeldService.java:83) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0] Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Bar[]] with qualifiers [@Default] at injection point [[field] @Inject org.jboss.as.quickstarts.helloworld.Foo.field] at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:311) at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:280) at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:143) at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:163) at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:382) at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:367) at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:380) at org.jboss.as.weld.WeldContainer.start(WeldContainer.java:83) at org.jboss.as.weld.services.WeldService.start(WeldService.java:76) ... 5 more {noformat} Also note that the src/test/java/org/jboss/weld/tests/arrays/ArrayInjectionTest.java will fail if @Inject is used to inject the arrays instead of the arquillian enrichment. -- 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, 1 month

4
11
0 / 0

[JBoss JIRA] (WELD-1098) java.lang.NoSuchMethodError: org.jboss.weld.bootstrap.WeldBootstrap.startContainer

by Nebrass Lamouchi (JIRA)

Nebrass Lamouchi created WELD-1098: -------------------------------------- Summary: java.lang.NoSuchMethodError: org.jboss.weld.bootstrap.WeldBootstrap.startContainer Key: WELD-1098 URL: https://issues.jboss.org/browse/WELD-1098 Project: Weld Issue Type: Bug Components: Bootstrap and Metamodel API Affects Versions: 2.0.0.Alpha1 Environment: Glassfish-3.1.2 Reporter: Nebrass Lamouchi java.lang.NoSuchMethodError: org.jboss.weld.bootstrap.WeldBootstrap.startContainer(Lorg/jboss/weld/bootstrap/api/Environment;Lorg/jboss/weld/bootstrap/spi/Deployment;)Lorg/jboss/weld/bootstrap/api/Bootstrap; at org.glassfish.weld.WeldDeployer.event(WeldDeployer.java:176) at org.glassfish.kernel.event.EventsImpl.send(EventsImpl.java:128) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:277) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:460) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389) at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363) at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085) at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291) at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259) at com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:461) at com.sun.enterprise.v3.admin.AdminAdapter.service(AdminAdapter.java:212) at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179) at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117) at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59) at com.sun.grizzly.ContextTask.run(ContextTask.java:71) at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532) at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513) at java.lang.Thread.run(Thread.java:662) -- 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, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (WELD-963) Change Singleton to use a Map of ids -> singletons

by Pete Muir (JIRA)

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 Affects Versions: 1.1.2.Final Reporter: Pete Muir 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

12 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (WELD-962) Attach bda id and deployment id to the serialized proxy and use it on deserialization to locate correct singleton

by Pete Muir (JIRA)

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 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

12 years, 1 month

3
4
0 / 0

[JBoss JIRA] (WELD-1144) Superclass of processed AnnotationType is ignored

by Richard Kennard (JIRA)

Richard Kennard created WELD-1144: ------------------------------------- Summary: Superclass of processed AnnotationType is ignored Key: WELD-1144 URL: https://issues.jboss.org/browse/WELD-1144 Project: Weld Issue Type: Bug Components: Weld SPI Affects Versions: 1.1.8.Final Reporter: Richard Kennard This issue has been raised a couple times (WELD-705 and WELD-1062) and marked as 'resolved' both times, but still appears broken in 1.1.8.Final? The documentation for ProcessAnnotatedType says it allows "an extension class [to] process the annotations of a bean class before the container builds its metamodel". However this appears very brittle. For example, any attempt to touch the AnnotatedFields of an AnnotatedType breaks superclass injection? I attach a sample that uses processAnnotationType. All it does is *recreate* each AnnotatedField and put it back into a new Set. This is sufficient to break superclass injection. Note that putting the *same* AnnotatedField (not a recreated version) back into the new Set works fine. Of course for a real use case I would do something more useful to each AnnotatedField that simply recreating it. For example I would change its type (like Solder's @Exact does) or add additional annotations. But I wanted to keep the test case simple. -- 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, 1 month

4
19
0 / 0

[JBoss JIRA] (WELD-1111) Inheritance of member-level metadata for generic types - missing substitution of actual type arguments

by Martin Kouba (JIRA)

Martin Kouba created WELD-1111: ---------------------------------- Summary: Inheritance of member-level metadata for generic types - missing substitution of actual type arguments Key: WELD-1111 URL: https://issues.jboss.org/browse/WELD-1111 Project: Weld Issue Type: Bug Reporter: Martin Kouba Priority: Minor See the spec *4.2. Inheritance of member-level metadata*. {code} class Bar<T> { @Inject Baz<T> baz; } class Foo extends Bar<String> {} {code} The required type of inherited injection point on {{Foo}} is {{Baz<T>}} but should be {{Baz<String>}}. -- 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, 1 month

6
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues June 2012