[JBoss JIRA] (WELD-1012) CLONE - NPE in org.jboss.weld.wicket.util.NonContextual.<init>
by Ondrej Zizka (Created) (JIRA)
CLONE - NPE in org.jboss.weld.wicket.util.NonContextual.<init>
--------------------------------------------------------------
Key: WELD-1012
URL: https://issues.jboss.org/browse/WELD-1012
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 r147
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.
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, 7 months
[JBoss JIRA] (WELD-892) Calling session-scoped components from session initialized observer goes into infinite loop
by Ales Justin (Assigned) (JIRA)
[ https://issues.jboss.org/browse/WELD-892?page=com.atlassian.jira.plugin.s... ]
Ales Justin reassigned WELD-892:
--------------------------------
Assignee: Marko Strukelj (was: Ales Justin)
> Calling session-scoped components from session initialized observer goes into infinite loop
> -------------------------------------------------------------------------------------------
>
> Key: WELD-892
> URL: https://issues.jboss.org/browse/WELD-892
> Project: Weld
> Issue Type: Bug
> Components: Scopes & Contexts
> Affects Versions: 1.1.1.Final
> Reporter: Nicklas Karlsson
> Assignee: Marko Strukelj
>
> Given a session scoped component
> {code}
> @SessionScoped
> public class Pinger implements Serializable
> {
> public void ping()
> {
> };
> }
> {code}
> and a session initialized observer calling it
> {code}
> public class Observer
> {
> @Inject
> Pinger pinger;
> public void newSession(@Observes @Initialized HttpSession s)
> {
> pinger.ping();
> }
> }
> {code}
> We go off into an infinite loop. Since Pinger doesn't exist, it is created and placed in the session scoped beanstore, which creates a session and fires off the observer. I'm not sure why the session isn't considered created at this point. This is bordering on feature since I think the result would be the same if servlet listeners would be used. Perhaps this could be worked around int the event bridge somehow so that the firing would be prevented if we're already handling the session created event...
--
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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[JBoss JIRA] (WELD-1001) Decorator is missing abstract methods implementation
by Ales Justin (Created) (JIRA)
Decorator is missing abstract methods implementation
----------------------------------------------------
Key: WELD-1001
URL: https://issues.jboss.org/browse/WELD-1001
Project: Weld
Issue Type: Bug
Components: Interceptors and Decorators
Affects Versions: 1.1.2.Final
Reporter: Ales Justin
Assignee: Ales Justin
Fix For: 1.2.0.Beta1
java.lang.AbstractMethodError: org.jboss.test.workshop.cdi.interceptors.support.LargeAmountAccount.getState()D
at org.jboss.test.workshop.cdi.interceptors.support.LargeAmountAccount.deposit(LargeAmountAccount.java:44)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.bean.proxy.DecoratorProxyMethodHandler.doInvoke(DecoratorProxyMethodHandler.java:91)
at org.jboss.interceptor.util.proxy.TargetInstanceProxyMethodHandler.invoke(TargetInstanceProxyMethodHandler.java:43)
at org.jboss.weld.bean.proxy.TargetBeanInstance.invoke(TargetBeanInstance.java:102)
at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:125)
at org.jboss.test.workshop.cdi.interceptors.support.BasicAccount$Proxy$_$$_Weld$Proxy$.deposit(BasicAccount$Proxy$_$$_Weld$Proxy$.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:76)
at org.jboss.test.workshop.cdi.interceptors.support.-239510789$Proxy$_$$_WeldSubclass.deposit(-239510789$Proxy$_$$_WeldSubclass.java)
at org.jboss.test.workshop.cdi.interceptors.support.BasicAccount$Proxy$_$$_WeldClientProxy.deposit(BasicAccount$Proxy$_$$_WeldClientProxy.java)
at org.jboss.test.workshop.cdi.interceptors.support.BusinessObject.deposit(BusinessObject.java:46)
at org.jboss.test.workshop.cdi.interceptors.support.BusinessObject$Proxy$_$$_WeldClientProxy.deposit(BusinessObject$Proxy$_$$_WeldClientProxy.java)
at org.jboss.test.workshop.cdi.interceptors.test.DecoratorTestCase.testInterceptors(DecoratorTestCase.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
--
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, 7 months