[JBoss JIRA] (JBSEAM-5032) Switch off ajax console rendering in Seam-gen/JBDS created projects
by Tomas Remes (JIRA)
Tomas Remes created JBSEAM-5032:
-----------------------------------
Summary: Switch off ajax console rendering in Seam-gen/JBDS created projects
Key: JBSEAM-5032
URL: https://issues.jboss.org/browse/JBSEAM-5032
Project: Seam 2
Issue Type: Enhancement
Components: Tools
Affects Versions: 2.3.0.CR1
Reporter: Tomas Remes
Priority: Minor
Fix For: 2.3.0.Final
In seam-gen/view/layout there is default template.xhtml, which contains following snippet:
{noformat}
<a:log hotkey="D"/>
{noformat}
This is causing that console is rendered. It should be changed to:
{noformat}
<a:log hotkey="D" rendered="false"/>
{noformat}
Probably since Richfaces 4.x is rendered attribute set to true by default.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBSEAM-5031) Seam-gen generated project doesn't get automatically deployed after import to JBDS
by Tomas Remes (JIRA)
Tomas Remes created JBSEAM-5031:
-----------------------------------
Summary: Seam-gen generated project doesn't get automatically deployed after import to JBDS
Key: JBSEAM-5031
URL: https://issues.jboss.org/browse/JBSEAM-5031
Project: Seam 2
Issue Type: Enhancement
Components: Tools
Affects Versions: 2.3.0.CR1
Environment: JBoss AS 7.1.1.Final
Reporter: Tomas Remes
Fix For: 2.3.0.Final
This doesn't work because AS7 deployment scanner works only for archives not directories. So IMO we have two following opportunities:
1) change deployment to deploy EAR/WAR archive
2) update build.xml of generated project to create also "project.war.dodeploy" while copying to deployment directory.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JBSEAM-5033) seam-gen generates build.xml file where purge target is for old JBoss AS
by Immo Benjes (JIRA)
Immo Benjes created JBSEAM-5033:
-----------------------------------
Summary: seam-gen generates build.xml file where purge target is for old JBoss AS
Key: JBSEAM-5033
URL: https://issues.jboss.org/browse/JBSEAM-5033
Project: Seam 2
Issue Type: Bug
Components: Build
Affects Versions: 2.3.0.CR1
Reporter: Immo Benjes
Priority: Minor
The purge target in the build.xml file generated by seam-gen wasn't updated for JBoss AS7. It still uses old path.
{code}
<target name="purge" depends="undeploy" description="Clean out JBoss AS temporary deployment files">
<delete dir="${jboss.home}/server/default/tmp/deploy"/>
<mkdir dir="${jboss.home}/server/default/tmp/deploy/"/>
<delete dir="${jboss.home}/server/default/tmp/sessions"/>
<mkdir dir="${jboss.home}/server/default/tmp/sessions"/>
<delete dir="${jboss.home}/server/default/work/jboss.web/localhost/${project.name}"/>
</target>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4487) Concurrent requests; one invalidates the session, results in recursive loop of session creation
by dave atkins (JIRA)
Concurrent requests; one invalidates the session, results in recursive loop of session creation
-----------------------------------------------------------------------------------------------
Key: JBSEAM-4487
URL: https://jira.jboss.org/jira/browse/JBSEAM-4487
Project: Seam
Issue Type: Bug
Components: Core
Affects Versions: 2.2.0.GA, 2.2.0.CR1, 2.1.2.GA, 2.1.2.CR2, 2.1.2.CR1, 2.1.1.GA
Environment: Jboss 4.2.2 with shipped Tomcat on Linux.
Reporter: dave atkins
I noticed that we had an massive number of sessions on one of our tomcat nodes that hosts our modest Seam app. After some investigation I discovered this in the log
2009-11-25 17:38:02,521 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.security.identity 2009-11-25 17:38:02,522 INFO [org.jboss.seam.contexts.Contexts] starting up: org.jboss.seam.web.session
This is repeated for thousands of lines. After digging around the seam code I realised that if you have two concurrent requests and one invalidates the session before the other is finished, seam goes into an recursive loop of session creation (normally ended by stack overflow). Here's a stack trace showing two recursions.
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:304)
at org.jboss.seam.contexts.Contexts.startup(Contexts.java:278)
at org.jboss.seam.contexts.Lifecycle.beginSession(Lifecycle.java:209)
at org.jboss.seam.contexts.ServletLifecycle.beginSession(ServletLifecycle.java:141)
at org.jboss.seam.servlet.SeamListener.sessionCreated(SeamListener.java:45)
at org.apache.catalina.session.StandardSession.tellNew(StandardSession.java:397)
at org.apache.catalina.session.StandardSession.setId(StandardSession.java:369)
at org.apache.catalina.session.ManagerBase.createSession(ManagerBase.java:828)
at org.apache.catalina.session.StandardManager.createSession(StandardManager.java:291)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2312)
at org.apache.catalina.connector.Request.getSession(Request.java:2075)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at org.apache.catalina.core.ApplicationHttpRequest.getSession(ApplicationHttpRequest.java:545)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)
at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1002)
at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:962)
at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)
at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:189)
at org.jboss.seam.Component.getInstance(Component.java:1949)
at org.jboss.seam.Component.getInstance(Component.java:1944)
at org.jboss.seam.Component.getInstance(Component.java:1924)
at org.jboss.seam.Component.getInstance(Component.java:1919)
at org.jboss.seam.security.Identity.create(Identity.java:101)
at sun.reflect.GeneratedMethodAccessor2896.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.seam.util.Reflections.invoke(Reflections.java:22)
at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:144)
at org.jboss.seam.Component.callComponentMethod(Component.java:2211)
at org.jboss.seam.Component.callCreateMethod(Component.java:2134)
at org.jboss.seam.Component.newInstance(Component.java:2094)
This problem is partially documented here - https://jira.jboss.org/jira/browse/JBSEAM-2888, unfortunately this bugfix didn't solve the root cause of the problem.
The problem is caused by the SessionMap used by ServerConversationContext. Internally the session map uses HttpServletRequest.getSession(true) to retrieve the session, which creates a new session if the one defined on the HttpServletRequest is invalid or null. Unfortunately, when the new session is created session listeners are informed before the session has been set on the HttpServletRequest. Seam is one of these session listeners and creates a new Identity on session creation, which in turn accesses the SessionMap, still before the new Session has been set on the request. This leads to an infinite recursive loop.
The SessionMap used is returned by externalContext.getSessionMap(). One solution could be to implement our own SessionMap that doesn't attempt to create a new session if the current session is invalid or null, although I've no idea how this would impact on other Seam code.
The problem is relatively easy to create. In our application we have a search page that can take quite a while to complete a request. If we log out of the application in another tab before the search has completed the problem arises.
We are using seam 2.1.1.GA. I've looked at the source code for the latest release and it appears that the problem will still occur due to use of SessionMap.
Out current workaround is to add a ThreadLocal to Identity.create that counts recursive calls. If more then two recursive calls are detected an IllegalProcessState exception is thrown. This isn't definitely isn't a permanent solution, but stops our server creating 100,000 sessions.
--
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
13 years, 6 months
[JBoss JIRA] (JBSEAM-5028) Consider removing jboss-seam-jul
by Marek Schmidt (JIRA)
Marek Schmidt created JBSEAM-5028:
-------------------------------------
Summary: Consider removing jboss-seam-jul
Key: JBSEAM-5028
URL: https://issues.jboss.org/browse/JBSEAM-5028
Project: Seam 2
Issue Type: Task
Components: Platform interoperability
Affects Versions: 2.3.0.CR1
Reporter: Marek Schmidt
Assignee: Marek Novotny
Fix For: 2.3.0.Final
The jboss-seam-jul module is probably not needed anymore, as the targeted platforms for 2.3.0 don't need it, AFAIK.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (JBSEAM-4901) Seam reference guide requires set up english locale
by Marek Novotny (JIRA)
Marek Novotny created JBSEAM-4901:
-------------------------------------
Summary: Seam reference guide requires set up english locale
Key: JBSEAM-4901
URL: https://issues.jboss.org/browse/JBSEAM-4901
Project: Seam 2
Issue Type: Bug
Components: Build
Affects Versions: 2.3.0.ALPHA
Environment: CZ locale
Reporter: Marek Novotny
[INFO] --- maven-jdocbook-plugin:2.3.5:generate (jdocbook:generate) @ seam-reference-guide ---
10 [main] INFO org.jboss.jdocbook.render.RendererImpl - Starting rendering en-US/pdf
redirecting output to file [/home/mana/projects/git/seam-svn-git/Seam_2_3/seam-reference-guide/target/docbook/work/log/console-en-US-pdf.log]
Error on line 4 column 17 of file:/home/mana/projects/git/seam-svn-git/Seam_2_3/seam-reference-guide/src/docbook/en-US/master.xml:
Error reported by XML parser: Invalid byte 1 of 1-byte UTF-8 sequence.
{noformat}
--
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
13 years, 7 months
[JBoss JIRA] (JBSEAM-4732) Facelets Classloading Takes Much Longer when jsf-facelets.jar is Deployed in a Common Location
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4732?page=com.atlassian.jira.plugi... ]
Marek Novotny updated JBSEAM-4732:
----------------------------------
> Facelets Classloading Takes Much Longer when jsf-facelets.jar is Deployed in a Common Location
> ----------------------------------------------------------------------------------------------
>
> Key: JBSEAM-4732
> URL: https://issues.jboss.org/browse/JBSEAM-4732
> Project: Seam 2
> Issue Type: Bug
> Reporter: Gary Hu
> Assignee: Marek Novotny
> Attachments: facelets-1.1.15.B1.patch
>
>
> The facelets 1.1.15.B1 is placed under the $JBOSS_HOME/server/$PROFILE/lib folder.
> In EAP 4.3, it takes about 2s to load the facelets library, but in EAP 5.0 it takes about 15s.
> The following facelets code is analyzed, which tells us the slowness comes from the facelets library loading:
>
> public static URL[] search(ClassLoader cl, String prefix, String suffix) throws IOException {
> Enumeration[] e = new Enumeration[] {
> cl.getResources(prefix),
> cl.getResources(prefix + "MANIFEST.MF")
> };
> Set all = new LinkedHashSet();
> URL url;
> URLConnection conn;
> JarFile jarFile;
> for (int i = 0, s = e.length; i < s; ++i) {
> while (e[i].hasMoreElements()) {
> url = (URL) e[i].nextElement();
> conn = url.openConnection();
> conn.setUseCaches(false);
> conn.setDefaultUseCaches(false);
> if (conn instanceof JarURLConnection) {
> jarFile = ((JarURLConnection) conn).getJarFile();
> } else {
> jarFile = getAlternativeJarFile(url);
> }
> if (jarFile != null) {
> searchJar(cl, all, jarFile, prefix, suffix);
> } else {
> boolean searchDone = searchDir(all, new File(URLDecoder.decode(url.getFile(), "UTF-8")), suffix);
> if (!searchDone)
> {
> searchFromURL(all, prefix, suffix, url);
> }
> }
> }
> }
> URL[] urlArray = (URL[]) all.toArray(new URL[all.size()]);
> return urlArray;
> }
> This method is called from com.sun.facelets.compiler.TagLibraryConfig.loadImplicit() with the followign statement:
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> URL[] urls = Classpath.search(cl, "META-INF/", SUFFIX); //SUFFIX is ".taglib.xml"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months
[JBoss JIRA] (JBSEAM-4732) Facelets Classloading Takes Much Longer when jsf-facelets.jar is Deployed in a Common Location
by Marek Novotny (JIRA)
[ https://issues.jboss.org/browse/JBSEAM-4732?page=com.atlassian.jira.plugi... ]
Marek Novotny closed JBSEAM-4732.
---------------------------------
Resolution: Out of Date
> Facelets Classloading Takes Much Longer when jsf-facelets.jar is Deployed in a Common Location
> ----------------------------------------------------------------------------------------------
>
> Key: JBSEAM-4732
> URL: https://issues.jboss.org/browse/JBSEAM-4732
> Project: Seam 2
> Issue Type: Bug
> Reporter: Gary Hu
> Assignee: Marek Novotny
> Attachments: facelets-1.1.15.B1.patch
>
>
> The facelets 1.1.15.B1 is placed under the $JBOSS_HOME/server/$PROFILE/lib folder.
> In EAP 4.3, it takes about 2s to load the facelets library, but in EAP 5.0 it takes about 15s.
> The following facelets code is analyzed, which tells us the slowness comes from the facelets library loading:
>
> public static URL[] search(ClassLoader cl, String prefix, String suffix) throws IOException {
> Enumeration[] e = new Enumeration[] {
> cl.getResources(prefix),
> cl.getResources(prefix + "MANIFEST.MF")
> };
> Set all = new LinkedHashSet();
> URL url;
> URLConnection conn;
> JarFile jarFile;
> for (int i = 0, s = e.length; i < s; ++i) {
> while (e[i].hasMoreElements()) {
> url = (URL) e[i].nextElement();
> conn = url.openConnection();
> conn.setUseCaches(false);
> conn.setDefaultUseCaches(false);
> if (conn instanceof JarURLConnection) {
> jarFile = ((JarURLConnection) conn).getJarFile();
> } else {
> jarFile = getAlternativeJarFile(url);
> }
> if (jarFile != null) {
> searchJar(cl, all, jarFile, prefix, suffix);
> } else {
> boolean searchDone = searchDir(all, new File(URLDecoder.decode(url.getFile(), "UTF-8")), suffix);
> if (!searchDone)
> {
> searchFromURL(all, prefix, suffix, url);
> }
> }
> }
> }
> URL[] urlArray = (URL[]) all.toArray(new URL[all.size()]);
> return urlArray;
> }
> This method is called from com.sun.facelets.compiler.TagLibraryConfig.loadImplicit() with the followign statement:
> ClassLoader cl = Thread.currentThread().getContextClassLoader();
> URL[] urls = Classpath.search(cl, "META-INF/", SUFFIX); //SUFFIX is ".taglib.xml"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 7 months