October 2011 - weld-issues - Jboss List Archives

[JBoss JIRA] Created: (WELD-617) Can not find beans when deploying compressed Archive to Tomcat

by Aslak Knutsen (JIRA)

Can not find beans when deploying compressed Archive to Tomcat -------------------------------------------------------------- Key: WELD-617 URL: https://jira.jboss.org/browse/WELD-617 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.0.1.Final Reporter: Aslak Knutsen When deploying a compressed Archive on Tomcat, WebAppBeanDeploymentArchive.scan fails to find and classes. In WebAppBeanDeploymentArchive.scan we try to get the File object representation of the WEB-INF/classes directory so we can recursively scan for classes, but in Tomcat this is a URL to jndi backed by a DirContext. WebAppBeanDeploymentArchive.scan { // inside scan File webInfClasses = Servlets.getRealFile(servletContext, WEB_INF_CLASSES); { // inside getRealFile String realPath = servletContext.getRealPath(path); realPath == null URL resourcePath = servletContext.getResource(path); resourcePath == jndi:/localhost/test/WEB-INF/classes } webInfClasses == null } End result is no classes are found. -- 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

12 years, 5 months

5
9
0 / 0

[JBoss JIRA] Created: (WELD-904) Observer method inheritance broken

by Christian Bauer (JIRA)

Observer method inheritance broken ---------------------------------- Key: WELD-904 URL: https://issues.jboss.org/browse/WELD-904 Project: Weld Issue Type: Bug Affects Versions: 1.1.1.Final Reporter: Christian Bauer Priority: Minor /* <beans xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd"> <alternatives> <class>Foo$Bar</class> </alternatives> </beans> */ @ApplicationScoped public class Foo { public static void main(String[] args) { WeldContainer weld = new Weld().initialize(); weld.event().select(MyEvent.class).fire(new MyEvent()); } static class MyEvent { } @Qualifier @Target({FIELD, PARAMETER}) @Retention(RUNTIME) public @interface SomeQualifier { } @PostConstruct void init() { System.out.println("INIT FOO"); } void onEvent(@Observes MyEvent e) { System.out.println("EVENT FOO"); } @Alternative @Specializes static public class Bar extends Foo { @Override void init() { System.out.println("INIT BAR"); } @Override void onEvent(@Observes @SomeQualifier MyEvent e) { System.out.println("EVENT BAR"); } } } The expected output is: INIT BAR The actual output is: INIT BAR EVENT BAR Removing the @SomeQualifier annotation on the Bar#onEvent() method results in: INIT BAR EVENT BAR EVENT BAR Removing also the @Observes annotation on the Bar#onEvent() method results in: -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
9
0 / 0

[JBoss JIRA] Created: (WELD-885) NPE in org.jboss.weld.wicket.util.NonContextual.<init>

by Ondrej Zizka (JIRA)

NPE in org.jboss.weld.wicket.util.NonContextual.<init> ------------------------------------------------------ Key: WELD-885 URL: https://issues.jboss.org/browse/WELD-885 Project: Weld Issue Type: Bug Components: Servlet Container Support Affects Versions: 1.0.1.Final Environment: Jetty 6.1.26 Wicket 1.4.16 Reporter: Ondrej Zizka I have a standalone app with embedded Jetty running a Wicket app. I added weld-wicket as dependency, and after I changed parent class of my WicketApplication to WeldApplication and tried to run, the NPE occured. Whole project can be seen at http://ondrazizka.googlecode.com/svn/trunk/bots/JawaBot/branches/2.0 20:56:17.343 ERROR [main] / unavailable java.lang.NullPointerException at org.jboss.weld.wicket.util.NonContextual.<init>(NonContextual.java:33) at org.jboss.weld.wicket.WeldApplication.internalInit(WeldApplication.java:50) at org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:723) at org.apache.wicket.protocol.http.ReloadingWicketFilter.init(ReloadingWicketFilter.java:175) at org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:219) at javax.servlet.GenericServlet.init(GenericServlet.java:241) at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:440) at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:736) at org.mortbay.jetty.servlet.Context.startContext(Context.java:140) at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:518) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130) at org.mortbay.jetty.Server.doStart(Server.java:224) at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50) at org.jboss.jawabot.web.RunInJetty.run(RunInJetty.java:145) at org.jboss.jawabot.mod.web.WebModuleHook.initModule(WebModuleHook.java:18) at org.jboss.jawabot.JawaBotApp.initAndStartModules(JawaBotApp.java:106) at org.jboss.jawabot.JawaBotApp.main(JawaBotApp.java:53) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
4
0 / 0

[JBoss JIRA] Created: (WELD-957) Log says "JSR-299 injection will be available in Servlets" on Jetty 6, but it is not if jetty-env.xml and jetty-web.xml are missing

by Geoffrey De Smet (JIRA)

Log says "JSR-299 injection will be available in Servlets" on Jetty 6, but it is not if jetty-env.xml and jetty-web.xml are missing ----------------------------------------------------------------------------------------------------------------------------------- Key: WELD-957 URL: https://issues.jboss.org/browse/WELD-957 Project: Weld Issue Type: Task Affects Versions: 1.1.2.Final Reporter: Geoffrey De Smet Priority: Optional 1) Either the log should say "... if jetty-env.xml and jetty-web.xml have been correctly added." Or 2) it should check if they are there in the war before state that injection works on servlets. Or 3) - better yet - the system should be improved so the jetty-web.xml thing is obsolete (like on tomcat). That log statement was very misleading and it took me quite some time to find out that it was not my jetty6 plugin that was causing the trouble, but that in fact I was missing these bits: http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html_single/#d0e5286 I've looked into 3), but adding this in org.jboss.weld.environment.jetty.AbstractJettyPre72Container: {code} Class<?> weldServletHandlerClass = Reflections.classForName("org.jboss.weld.environment.jetty.WeldServletHandler"); Method processMethod = weldServletHandlerClass.getMethod("process", WebAppContext.class); processMethod.invoke(null, (WebAppContext) WebAppContext.getCurrentWebAppContext()); {code} But that results in 404, because in org.jboss.weld.environment.jetty.WeldServletHandler#WeldServletHandler the existingHandler is properly started and the new one is not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
7
0 / 0

[JBoss JIRA] Created: (WELD-842) Event injection via constructor injection results in stacktrace.

by Christopher Brock (JIRA)

Event injection via constructor injection results in stacktrace. ----------------------------------------------------------------- Key: WELD-842 URL: https://issues.jboss.org/browse/WELD-842 Project: Weld Issue Type: Bug Affects Versions: 1.1.0.Final Reporter: Christopher Brock {code} /** * @author Mike Brock . */ @ApplicationScoped public class HelloWorldService { private Event<ResponseEvent> responseEvent; @Inject public HelloWorldService(Event<ResponseEvent> responseEvent) { this.responseEvent = responseEvent; } public void handleMessage(@Observes MessageEvent event) { System.out.println("Received Message: " + event.getMessage()); responseEvent.fire(new ResponseEvent(event.getMessage())); } } {code} Results in stacktrace: {code} com.google.common.collect.ComputationException: org.jboss.weld.exceptions.DefinitionException: org.jboss.errai.demos.cdi.helloworld.server.org$jboss$weld$bean-flat-ManagedBean-class_org$jboss$errai$demos$cdi$helloworld$server$HelloWorldService_$$_WeldClientProxy at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:602) at com.google.common.collect.MapMaker$StrategyImpl.compute(MapMaker.java:462) at com.google.common.collect.CustomConcurrentHashMap$ComputingImpl.get(CustomConcurrentHashMap.java:2045) at org.jboss.weld.bean.proxy.ClientProxyProvider.getClientProxy(ClientProxyProvider.java:112) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:660) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:252) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222) at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:614) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:607) at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:601) at org.jboss.errai.cdi.server.EventDispatcher.callback(EventDispatcher.java:60) {code} Thought it was a problem in our integration at first, but then I realized the problem does not happen when field injection is used for the Event. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
4
0 / 0

[JBoss JIRA] Created: (WELD-932) weld-osgi-bundle binds to invalid SLF4J package versions

by Ancoron Luciferis (JIRA)

weld-osgi-bundle binds to invalid SLF4J package versions -------------------------------------------------------- Key: WELD-932 URL: https://issues.jboss.org/browse/WELD-932 Project: Weld Issue Type: Bug Components: OSGi support Affects Versions: 1.1.1.Final Environment: OSGi + SLF4J 1.6.x Reporter: Ancoron Luciferis Priority: Critical Fix For: 1.1.2.Final The current weld-osgi-bundle is a bit weird in multiple ways: # it packages slf4j 1.5.6 and at the same time imports it # the package import definition is not a range, although incompatible API's are known already (1.5.x vs. 1.6.x) The actual problem manifests itself e.g. in GlassFish 3.1+ with a deployed SLF4J 1.6.1: {noformat} WARNING: Failed to deploy bundle com.something.support.web [319] org.glassfish.osgijavaeebase.DeploymentException: Deployment of com.something.support.web [319] failed because of following reason: Failed while deploying bundle com.something.support.web [319] : java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:125) at org.glassfish.osgijavaeebase.OSGiContainer.deploy(OSGiContainer.java:154) at org.glassfish.osgijavaeebase.JavaEEExtender.deploy(JavaEEExtender.java:107) at org.glassfish.osgijavaeebase.JavaEEExtender.access$200(JavaEEExtender.java:61) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:151) at org.glassfish.osgijavaeebase.JavaEEExtender$HybridBundleTrackerCustomizer$1.call(JavaEEExtender.java:148) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.RuntimeException: Failed to deploy bundle [ com.something.support.web [319] ], root cause: Exception while loading the app at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:196) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.execute(OSGiDeploymentRequest.java:118) at org.glassfish.osgijavaeebase.AbstractOSGiDeployer.deploy(AbstractOSGiDeployer.java:121) ... 10 more Caused by: java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V at org.slf4j.cal10n.LocLogger.info(LocLogger.java:122) at org.jboss.weld.bootstrap.WeldBootstrap.<clinit>(WeldBootstrap.java:213) at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:345) at org.glassfish.weld.WeldDeployer.load(WeldDeployer.java:99) at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:186) at org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:257) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:461) at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240) at org.glassfish.osgijavaeebase.OSGiDeploymentRequest.deploy(OSGiDeploymentRequest.java:183) ... 12 more {noformat} This introduces problems when someone deploys an application which in turn requires the SLF4J API 1.6.x. So I suggest to fix it like this: {noformat} Import-Package: ... org.slf4j;version="[1.5.10,1.6)";resolution:=optional, org.slf4j.helpers;version="[1.5.10,1.6)";resolution:=optional, org.slf4j.spi;version="[1.5.10,1.6)";resolution:=optional {noformat} Furthermore there are still some placeholders inside the {{META-INF/MANIFEST.MF}}: {noformat} Specification-Version: ${parsedVersion.osgiVersion} Maven-Version: ${maven.version} SCM: r${buildNumber} {noformat} The final goal should be to get rid of embedding the org.slf4j stuff altogether. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

9
10
0 / 0

[JBoss JIRA] Created: (WELD-955) If a class is ignored due to classloading problems the log level shouldn't be debug

by Adam Warski (JIRA)

If a class is ignored due to classloading problems the log level shouldn't be debug ----------------------------------------------------------------------------------- Key: WELD-955 URL: https://issues.jboss.org/browse/WELD-955 Project: Weld Issue Type: Enhancement Components: Bootstrap and Metamodel API Affects Versions: 1.1.2.Final Reporter: Adam Warski In BeanDeployer:99, if a class has classloading problems and is ignored, information about that is logged with the "debug" level, which by default isn't visible in any AS7 logs. I found this after a long search why some of my beans stopped being visible (when migrating to AS7 the app must now bundle slf4j), and I think it would be much more user-friendly if this was logged at least with an info. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
4
0 / 0

[JBoss JIRA] Created: (WELD-691) Add tests for Tomcat 7

by Pete Muir (JIRA)

Add tests for Tomcat 7 ---------------------- Key: WELD-691 URL: https://jira.jboss.org/browse/WELD-691 Project: Weld Issue Type: Feature Request Components: Servlet Container Support Affects Versions: 1.1.0.Beta1 Reporter: Pete Muir Fix For: 1.1.0.Beta2 Need to run Servlet Tests on Tomcat 7 container -- 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

12 years, 5 months

5
5
0 / 0

[JBoss JIRA] Created: (WELD-978) Cannot fire event with parametrized type as a payload

by Martin Kouba (JIRA)

Cannot fire event with parametrized type as a payload ----------------------------------------------------- Key: WELD-978 URL: https://issues.jboss.org/browse/WELD-978 Project: Weld Issue Type: Bug Affects Versions: 1.1.2.Final Reporter: Martin Kouba It should be possible to fire event with parametrized type as a payload. See CDI 1.0 spec chapter *10.1. Event types and qualifier types*. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

5
10
0 / 0

[JBoss JIRA] Created: (WELD-865) Weld allows for concurrent call to conversation

by George Sapountzis (JIRA)

Weld allows for concurrent call to conversation ----------------------------------------------- Key: WELD-865 URL: https://issues.jboss.org/browse/WELD-865 Project: Weld Issue Type: Bug Components: Scopes & Contexts, Web Tier integration (JSF, JSP, EL and Servlet) Affects Versions: 1.1.0.Final Reporter: George Sapountzis Concurrent calls to a @ConversationScoped component: Thread 1: AbstractConversationContext.activate(String cid) ConversationImpl.lock(long timeout) <-- returns true correctly proceed inside method Thread 2: AbstractConversationContext.activate(String cid) ConversationImpl.lock(long timeout) <-- returns false but activate() does not check result !!! *incorrectly* proceed inside method ---- I think AbstractConversationContext.activate(String cid) should check the result of ConversationImpl.lock(long timeout) and not allow the second thread to proceed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

3
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

weld-issues October 2011