[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 1 month
[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
13 years, 2 months
[JBoss JIRA] Created: (WELD-831) Weld throws an NPE thrown during failover between to jboss servers
by Fin Steenbjerg (JIRA)
Weld throws an NPE thrown during failover between to jboss servers
------------------------------------------------------------------
Key: WELD-831
URL: https://issues.jboss.org/browse/WELD-831
Project: Weld
Issue Type: Feature Request
Environment: OS: MS Windows (XP)
AS: Jboss 6.0.0 Final
JDK: 1.6.0_23 (sun/oracle jdk)
Reporter: Fin Steenbjerg
In a two node jboss environment a failover throws an exception (see description in the forum reference):
2011-01-18 20:55:13,222 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/clusteredcdi.web]] (ajp-127.0.0.1-8209-1) Exception sending request initialized lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.NullPointerException
at org.jboss.weld.context.ForwardingContextual.toString(ForwardingContextual.java:52) [:6.0.0.Final]
at java.lang.String.valueOf(String.java:2826) [:1.6.0_23]
at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23]
at org.jboss.weld.context.SerializableContextualInstanceImpl.toString(SerializableContextualInstanceImpl.java:67) [:6.0.0.Final]
at java.lang.String.valueOf(String.java:2826) [:1.6.0_23]
at java.lang.StringBuilder.append(StringBuilder.java:115) [:1.6.0_23]
at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:120) [:6.0.0.Final]
at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:75) [:6.0.0.Final]
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:161) [:6.0.0.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:180) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) [:6.0.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.event(CatalinaContext.java:285) [:1.1.0.Final]
at org.jboss.modcluster.catalina.CatalinaContext$RequestListenerValve.invoke(CatalinaContext.java:261) [:1.1.0.Final]
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:88) [:6.0.0.Final]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.Final]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.Final]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.Final]
at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:504) [:6.0.0.Final]
at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:437) [:6.0.0.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_23]
Steps to Reproduce:
I have attached an ear file containing a single war module. Inside this war module there is a single class named Pojo (the source is there too) and a single xhtml page which uses the pojo class via CDI. It's very simple. (I have added a servlet filter that prints the session attributes for each request - but that can be removed if it is not wanted).
Test Setup
The jboss setup to use in order reproduce the problem is as follows:
1. A single Jboss installation with two server configurations called node01 and node02 (these are both copies of the all configuration)
2. An apache server in front of the two jboss nodes. The apache uses mod_cluster plugin.
3. The setup is started with the following script (sorry it is for ms windows):
start %~dp0..\..\apache-2.2\bin\httpd.exe
&& sleep 10
&& start %~dp0run.bat -c node01 -Djboss.jvmRoute=node01 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-01
&& sleep 10&& start %~dp0run.bat -c node02 -Djboss.jvmRoute=node02 -Djboss.mod_cluster.proxyList=127.0.0.1:6666 -Djboss.mod_cluster.excludedContexts=ROOT -Djboss.service.binding.set=ports-02
&& sleep 45
&& start http://localhost:8080/mod_cluster-manager
4. Deploy the the clusteredcdi.ear file to farm folder belonging to one of the jboss configurations being used.
Test execution
1. Make a request via the apache server http://localhost:8080/clusteredcdi.web/faces/pages/cdi.xhtml
2. Enter something into the form and submit via the "set new value" button.
3. Kill the jboss server process that handled the request
4. Refresh the browser window in which the request above was submitted.
5. The error occurs.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months