On Fri, Oct 15, 2010 at 2:47 AM, ssilv...@redhat.com wrote:
Yes, the goal is to allow any version and any implementation of JSF. That's
why you will see Initialized 3 JSF configurations: [Mojarra-1.2,
MyFaces-2.0,
Mojarra-2.0]
What about MyFaces 1.2 ? :)
Just to be clear, it's AS6
Am 15.10.10 09:26, schrieb Matthias Wessendorf:
Right now it has MyFaces 2.0.1, but I'm soon planning to do the full
integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a
little more efficient on JBoss AS.
+1 you really want 2.0.2 ;)
Hehe I guess Myfaces 2.0.2 performance
[
https://issues.apache.org/jira/browse/TRINIDAD-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921275#action_12921275
]
Tomas Havelka commented on TRINIDAD-119:
Is there a plan to solve this issue in
On Fri, Oct 15, 2010 at 10:15 AM, Werner Punz werner.p...@gmail.com wrote:
Am 15.10.10 09:26, schrieb Matthias Wessendorf:
Right now it has MyFaces 2.0.1, but I'm soon planning to do the full
integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a
little more efficient on
[
https://issues.apache.org/jira/browse/TRINIDAD-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-744.
-
Resolution: Fixed
Fix Version/s: 2.0.0.4-core
Am 15.10.10 10:19, schrieb Matthias Wessendorf:
On Fri, Oct 15, 2010 at 10:15 AM, Werner Punzwerner.p...@gmail.com wrote:
Am 15.10.10 09:26, schrieb Matthias Wessendorf:
Right now it has MyFaces 2.0.1, but I'm soon planning to do the full
integration of 2.0.2 as per Leonardo's changes. That
I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an
undeploy leak and it took a long time to track it down. The same test
I was using on Mojarra also failed on MyFaces but I haven't had time
to track down the leak in MyFaces.
Maybe this is fixed in 2.0.2? If not maybe
Memory Leak in MyFaces 2.0.1 probably as well in 2.0.2
--
Key: MYFACES-2942
URL: https://issues.apache.org/jira/browse/MYFACES-2942
Project: MyFaces Core
Issue Type: Bug
Affects
Am 15.10.10 14:04, schrieb ssilv...@redhat.com:
I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an
undeploy leak and it took a long time to track it down. The same test I
was using on Mojarra also failed on MyFaces but I haven't had time to
track down the leak in MyFaces.
Thanks Werner. Hope someone can take a look before 2.0.3.
Stan
Quoting Werner Punz werner.p...@gmail.com:
Am 15.10.10 14:04, schrieb ssilv...@redhat.com:
I'm pretty sure 2.0.1 has a memory leak on undeploy. Mojarra had an
undeploy leak and it took a long time to track it down. The same
Using tomcat 7 I get this warning...
SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal
with key of type [java.lang.ThreadLocal] (value
[java.lang.threadlo...@41649a55]) and a value of type
[org.apache.myfaces.config.RuntimeConfig] (value
[
https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921323#action_12921323
]
Bruno Aranda commented on MYFACES-2942:
---
Using tomcat 7 I get this warning...
The ThreadLocal should be cleared upon undeploy, but this does not
cause the memory leak mentioned by Stan.
You will get a PermGen error in about an hour.
The PermGen Error comes when there is not enough heap space to load
classes. I had this problem yesterday when doing a lot of tests with
The permgen error usually is an overload of classes which means if a
class is loaded and loaded and loaded again.
Maybe we have a problem in our way way instantiate classes dynamically
so that they constantly are reregistered in the classloader and never
dropped.
Just a wild guess here.
Quoting Bruno Aranda brunoara...@gmail.com:
Using tomcat 7 I get this warning...
SEVERE: The web application [/editor-2.0-SNAPSHOT] created a ThreadLocal
with key of type [java.lang.ThreadLocal] (value
[java.lang.threadlo...@41649a55]) and a value of type
Stan can you give us some info what the issue in Mojarra was?
It might help us to track our problem down.
My personal guess we that it might the our class instantiation code in
shared, but I am guessing here as well.
Werner
Am 15.10.10 14:04, schrieb ssilv...@redhat.com:
I'm pretty sure
Quoting Jakob Korherr jakob.korh...@gmail.com:
The ThreadLocal should be cleared upon undeploy, but this does not
cause the memory leak mentioned by Stan.
I disagree. That could easily be the cause as was the case with Mojarra.
You will get a PermGen error in about an hour.
The PermGen
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1820
Quoting Werner Punz werner.p...@gmail.com:
Stan can you give us some info what the issue in Mojarra was?
It might help us to track our problem down.
My personal guess we that it might the our class instantiation code in
shared,
Thanks, Stan!
We had a similar issue also in OpenWebBeans. The solution there was to
clear() all ThreadLocals after usage, however not only in the
ServletContextListener, but also in the RequestListener, because
ThreadLocal.clear() only works for the current Thread. Thus we have to
take a look at
Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ?
Looks like I (currently) have to add this:
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions:
I have not used it, but if this is a problem with Servlet 3.0, we
could use the MyFacesContainerInitializer (from implee6) to
automatically add the StartupServletContextListener.
Regards,
Jakob
2010/10/15 Matthias Wessendorf mat...@apache.org:
Has one used jetty-8.0.0.M1 so far, with MyFaces
No I haven't. But it looks like Jetty is not looking in the TLD files
for the context listeners.
Sent from my iPhone
On Oct 15, 2010, at 6:59 AM, Matthias Wessendorf mat...@apache.org wrote:
Has one used jetty-8.0.0.M1 so far, with MyFaces 2.0.2 ?
Looks like I (currently) have to add this:
This sort of thing has been an issue in the past with jetty.
Sometimes it has been intentional, and you have to enable a
configuration parameter to make it work.
On Fri, Oct 15, 2010 at 9:02 AM, Scott O'Bryan darkar...@gmail.com wrote:
No I haven't. But it looks like Jetty is not looking in the
[
https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921373#action_12921373
]
Martin Kočí commented on MYFACES-2942:
--
after 10 deploy-undeploy of same app at
[
https://issues.apache.org/jira/browse/MYFACES-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921377#action_12921377
]
Jakob Korherr commented on MYFACES-2942:
Thanks a lot for this info, Martin!
[
https://issues.apache.org/jira/browse/TRINIDAD-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12921400#action_12921400
]
Andrew Robinson commented on TRINIDAD-946:
--
You will need to provide a test case
You guys might want to check out the utility that Trinidad uses for
registering ThreadLocals for clean up at the end of the request in
org.apache.myfaces.trinidad.util.ThreadLocalUtils.
-- Blake Sullivan
On 10/15/10 5:52 AM, Jakob Korherr wrote:
Thanks, Stan!
We had a similar issue also
Hi
Checking this issue, I think we should just get rid of that ThreadLocal var,
because it is used as a hack to pass the right RuntimeConfig instance.
Before JSF 2.0 this was required because there was not startup FacesContext,
but now it exists, so it is valid to get the current ExternalContext
Thanks for the info, Blake!
Leo, please take a look at my comment + patch on MYFACES-2942. I did
exactly what you just said and I fully agree with you! If there are no
objections to that patch, I'll commit it tomorrow!
Regards,
Jakob
2010/10/15 Leonardo Uribe lu4...@gmail.com:
Hi
Checking
I completely agree that the best solution is to get rid of
ThreadLocals that we don't need.
-- Blake Sullivan
On 10/15/10 11:26 AM, Leonardo Uribe wrote:
Hi
Checking this issue, I think we should just get rid of that
ThreadLocal var, because it is used as a hack to pass the right
[
https://issues.apache.org/jira/browse/TRINIDAD-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson updated TRINIDAD-1920:
--
Resolution: Fixed
Fix Version/s: 1.2.15-core
[
https://issues.apache.org/jira/browse/TRINIDAD-1939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1939.
---
Resolution: Fixed
Fix Version/s: 1.2.15-core
32 matches
Mail list logo
