[JBoss JIRA] Created: (WELD-928) Weld should log failure to load a class at a higher level than DEBUG
by Stuart Douglas (JIRA)
Weld should log failure to load a class at a higher level than DEBUG
--------------------------------------------------------------------
Key: WELD-928
URL: https://issues.jboss.org/browse/WELD-928
Project: Weld
Issue Type: Bug
Affects Versions: 1.1.1.Final
Reporter: Stuart Douglas
Priority: Critical
Fix For: 1.1.2.Final
At the moment weld logs failure to load a class at a log level of debug, which is not displayed by default.
Due to the new modular class loading in AS7 these types of errors will become much more frequent, and the user is given no debug information to determine where the problem is. Changing the default log level to DEBUG for org.jboss.weld.Bootstrap is not an option as this is to verbose.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (WELD-575) Definition/DeploymentExceptions thrown by an AnnotationModel are wrapped by a ComputationException
by Marius Bogoevici (JIRA)
Definition/DeploymentExceptions thrown by an AnnotationModel are wrapped by a ComputationException
--------------------------------------------------------------------------------------------------
Key: WELD-575
URL: https://jira.jboss.org/browse/WELD-575
Project: Weld
Issue Type: Feature Request
Components: Reflection layer
Affects Versions: 1.0.1.Final
Reporter: Marius Bogoevici
Assignee: Pete Muir
Fix For: 1.1.0.BETA1
If an exception is thrown while evaluating a Function, the exception is wrapped by a ComputationException. As a result, the exceptions thrown by the AnnotationModel subclasses (Stereotype, InterceptionBinding) - which indicate a definition error detected while parsing the annotation are thrown as ComputationExceptions by the framework.
An illustration for this can be found in MetaAnnotationStore.getInterceptionBindingModel, although this needs to be done in a more general fashion.
--
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
13 years, 4 months
[JBoss JIRA] Created: (WELD-799) Weld throws java.lang.IllegalStateException: Context is not active during stress testing at higher number of clients
by Martin Gencur (JIRA)
Weld throws java.lang.IllegalStateException: Context is not active during stress testing at higher number of clients
--------------------------------------------------------------------------------------------------------------------
Key: WELD-799
URL: https://issues.jboss.org/browse/WELD-799
Project: Weld
Issue Type: Bug
Components: Performance and Scalability
Affects Versions: 1.1.0.CR1
Environment: JBossAS 6 CR1, Weld/trunk
Reporter: Martin Gencur
Fix For: 1.1.0.Final
I executed performance stress test using Wicket for view layer and Weld-trunk. Everything goes well up to 2100 sessions. Then the following exception is thrown. I tried it twice and it failed at the same amount of sessions.
Whole stack trace:
2010-12-17 03:03:57,840 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (http-10.16.89.196-8080-304) Unable to reduce enough channels, no idle channels left to remove.
2010-12-17 03:03:57,842 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (PageSavingThread-Wicket Filter) Unable to reduce enough channels, no idle channels left to remove.
2010-12-17 03:03:57,842 WARN [org.apache.wicket.protocol.http.pagestore.FileChannelPool] (PageSavingThread-Wicket Filter) Unable to reduce enough channels, no idle channels left to remove.
2010-12-17 03:03:58,499 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/seam-wicket-examples-numberguess-3.0.0-SNAPSHOT]] (http-10.16.89.196-8080-6) Exception sending request destroyed lifecycle event to listener instance of class org.jboss.weld.servlet.WeldListener: java.lang.IllegalStateException: Context is not active
at org.jboss.weld.context.AbstractConversationContext.deactivate(AbstractConversationContext.java:263) [:2010-12-17 02:45]
at org.jboss.weld.servlet.WeldListener.requestDestroyed(WeldListener.java:125) [:2010-12-17 02:45]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:204) [:6.0.0.20101110-CR1]
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:181) [:6.0.0.20101110-CR1]
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.20101110-CR1]
at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:100) [:6.0.0.20101110-CR1]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [:6.0.0.20101110-CR1]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [:6.0.0.20101110-CR1]
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [:6.0.0.20101110-CR1]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [:6.0.0.20101110-CR1]
at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:53) [:6.0.0.20101110-CR1]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [:6.0.0.20101110-CR1]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [:6.0.0.20101110-CR1]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [:6.0.0.20101110-CR1]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:951) [:6.0.0.20101110-CR1]
at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
There is a new hudson job which tests this at http://hudson.qa.jboss.com/hudson/view/Weld/job/perf-seam-wicket-numbergu...
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (WELD-809) NPE in ForwardingContextual.toString during session failover
by Sivakumar Thyagarajan (JIRA)
NPE in ForwardingContextual.toString during session failover
------------------------------------------------------------
Key: WELD-809
URL: https://issues.jboss.org/browse/WELD-809
Project: Weld
Issue Type: Bug
Reporter: Sivakumar Thyagarajan
Please see the corresponding GlassFish issue for more information http://java.net/jira/browse/GLASSFISH-15277
GlassFish SQE has a multi-machine HA cluster setup, where during session failover of a shopping cart sample application, the following NPE is thrown is ForwardingContextual.toString
java.lang.NullPointerException
at org.jboss.weld.context.ForwardingContextual.toString(ForwardingContextual.java:53)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at org.jboss.weld.context.SerializableContextualInstanceImpl.toString(SerializableContextualInstanceImpl.java:66)
at java.lang.String.valueOf(String.java:2826)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at org.jboss.weld.context.beanstore.AttributeBeanStore.attach(AttributeBeanStore.java:120)
at org.jboss.weld.context.AbstractBoundContext.activate(AbstractBoundContext.java:75)
at org.jboss.weld.servlet.WeldListener.requestInitialized(WeldListener.java:138)
at org.apache.catalina.core.StandardContext.fireRequestInitializedEvent(StandardContext.java:4544)
at org.apache.catalina.core.StandardHostValve.preInvoke(StandardHostValve.java:626)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:323)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (WELD-879) Tomcat 7 container is identified as Tomcat 6
by Ashley Westwell (JIRA)
Tomcat 7 container is identified as Tomcat 6
--------------------------------------------
Key: WELD-879
URL: https://issues.jboss.org/browse/WELD-879
Project: Weld
Issue Type: Bug
Components: CDI API
Affects Versions: 1.1.1.Final
Environment: Tomcat 7.0.11
Reporter: Ashley Westwell
Weld-servlet 1.1.1-Final identifies tomcat 7 as tomcat 6 environment.In Listener.java it executes the following code
container = checkContainers(cc, dump, Arrays.asList(
Tomcat6Container.INSTANCE,
Tomcat7Container.INSTANCE,
Jetty6Container.INSTANCE,
Jetty7Container.INSTANCE,
JettyPost72Container.INSTANCE)
);
This method returns a Tomcat6Container as Tomcat 7.0.11 at least has the class org.apache.catalina.core.ApplicationContextFacade. I would suggest reversing the order to have Tomcat7Container checked first as I from my knowledge the class org.apache.tomcat.InstanceManager is new to Tomcat 7
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[JBoss JIRA] Created: (WELD-913) SeamApplicationWrapper doesn't implement setApplication() correctly
by Christian Kaltepoth (JIRA)
SeamApplicationWrapper doesn't implement setApplication() correctly
-------------------------------------------------------------------
Key: WELD-913
URL: https://issues.jboss.org/browse/WELD-913
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.1.0.Final
Environment: Tomcat 7.0.8, Seam Faces 3.0.1, MyFaces 2.0.5
Reporter: Christian Kaltepoth
While debugging SEAMFACES-165 I discovered that {{SeamApplicationWrapper}} doesn't implement {{setApplication()}} correctly. The class should recreate the locally cached {{Application}} so that future calls to {{getApplication()}} return a correctly wrapped version of the new {{Application}} instance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months