[JBoss JIRA] Created: (WELD-570) Partial export of javasisst from Weld breaks other javasisst clients
by Harald Wellmann (JIRA)
Partial export of javasisst from Weld breaks other javasisst clients
--------------------------------------------------------------------
Key: WELD-570
URL: https://jira.jboss.org/browse/WELD-570
Project: Weld
Issue Type: Bug
Components: OSGi support
Affects Versions: 1.1.0.BETA1
Reporter: Harald Wellmann
weld-osgi-bundle.jar (as used in Glassfish 3.0 and higher) still contains a buggy version of javasisst causing memory leaks.
See WELD-453 and JASSIST-104. Even though Weld itself no longer uses the problematic javassist ProxyFactory, it is still the root cause for a memory leak occurring when HIbernate (or potentially any other Javassist client) is used on Glassfish.
The problem exists in Glassfish 3.0.1 and also in the promoted build 3.1-b12 using a 1.1.0 prerelease of Weld, see https://glassfish.dev.java.net/issues/show_bug.cgi?id=12368
weld-osgi-bundle.jar contains a version of javassist which is almost but not fully private. There is a package export for javassist.util.proxy. When deploying a WAR on Glassfish containing Hibernate (3.5.3) and another copy of Javasisst required by Hibernate, then by parent classloader delegation Hibernate will end up using the javassist ProxyFactory from Weld, registering its proxies deep down in the container, and thus causing a memory leak with each redeployment of the WAR.
Weld should either keep its included version of javassist fully private or import all of javasisst via Import-Package, relying on javasisst installed in a separate bundle.
--
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
14 years, 1 month
[JBoss JIRA] Created: (WELD-659) hello-world example - unexpected behavior
by Jozef Hartinger (JIRA)
hello-world example - unexpected behavior
-----------------------------------------
Key: WELD-659
URL: https://jira.jboss.org/browse/WELD-659
Project: Weld
Issue Type: Bug
Components: Examples
Affects Versions: 1.1.0.Beta1
Reporter: Jozef Hartinger
Priority: Minor
Fix For: 1.1.0.Beta2
According to documentation, the example should print "Hello ${name}" where name is an environment property passed to maven i.e. "mvn -Drun -Dname=Pete". However, the following profile configuration
<configuration>
<mainClass>org.jboss.weld.environment.se.StartMain</mainClass>
<arguments>
<argument>${project.name}</argument>
</arguments>
</configuration>
results in "Hello Weld Examples: Hello World (Java SE)" to be printed every time independently on the name environment property.
--
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
14 years, 1 month
[JBoss JIRA] Created: (WELD-587) Exception happened when invalid session before ending Conversation with Post-Redirect-Get
by Wang Liyu (JIRA)
Exception happened when invalid session before ending Conversation with Post-Redirect-Get
-----------------------------------------------------------------------------------------
Key: WELD-587
URL: https://jira.jboss.org/browse/WELD-587
Project: Weld
Issue Type: Bug
Components: Conversations, Scopes & Contexts
Affects Versions: 1.0.1.Final
Environment: Weld-servlet 1.0.1.Final, GlassFish3.0.1 or Tomcat6.0.26
Reporter: Wang Liyu
See http://seamframework.org/Community/ExceptionWhenEndingConversationWithPos... for the test case.
basically, when you call HttpSession.invalidate() method with a LRC running, after redirect, it will report an exception:
INFO: Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.
INFO: HelloWorld was constructed
INFO: begin the LRC here.
INFO: about to invalid the session here.
WARNING: StandardWrapperValve[Faces Servlet]: PWC1406: Servlet.service() for servlet Faces Servlet threw exception
org.jboss.weld.context.NonexistentConversationException: WELD-000301 Could not restore long-running conversation 2 because id not known
at org.jboss.weld.conversation.AbstractConversationManager.beginOrRestoreConversation(AbstractConversationManager.java:107)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:304)
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:298)
at org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:113)
at org.jboss.weld.util.CleanableMethodHandler.invoke(CleanableMethodHandler.java:43)
at org.jboss.weld.conversation.ServletConversationManager_$$_javassist_3.beginOrRestoreConversation(ServletConversationManager_$$_javassist_3.java)
at org.jboss.weld.jsf.WeldPhaseListener.initiateSessionAndConversation(WeldPhaseListener.java:171)
at org.jboss.weld.jsf.WeldPhaseListener.beforeRestoreView(WeldPhaseListener.java:118)
at org.jboss.weld.jsf.WeldPhaseListener.beforePhase(WeldPhaseListener.java:87)
at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:228)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:99)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:110)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
--
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
14 years, 1 month
[JBoss JIRA] Created: (WELDSE-23) Disable logging out of the box
by Peter Royle (JIRA)
Disable logging out of the box
------------------------------
Key: WELDSE-23
URL: https://jira.jboss.org/jira/browse/WELDSE-23
Project: Weld support for Java SE
Issue Type: Feature Request
Affects Versions: 1.0.1.Final
Reporter: Peter Royle
Assignee: Peter Royle
Priority: Minor
Fix For: 1.0.2.CR1
The presence of SLF4J-simple within the Weld SE jar causes problems for those wanting to use a different SLF4J provider (eg: jdk14).
This comment from Ceki points to a good solution, using SLF4J 1.6:
Ceki Gulcu - 23/Apr/10 04:17 AM
As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing an exception, SLF4J will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. If Weld's distribution includes slf4j-api.jar but no binding, then even in the absence of any SLF4J binding on the class path, Weld's distribution will still work out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user wishes to enable logging will she need to install a binding.
The problem with this currently is that version 1.6 is still alpha, so resolution of this issue will have to wait until version 1.6 is released as stable, and becomes available in the JBoss maven repositories:
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month