April 2009 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3572) Seam nested booking example - NoSuchEJBException on undeploy

by Jozef Hartinger (JIRA)

Seam nested booking example - NoSuchEJBException on undeploy ------------------------------------------------------------ Key: JBSEAM-3572 URL: https://jira.jboss.org/jira/browse/JBSEAM-3572 Project: Seam Issue Type: Bug Components: Examples Affects Versions: 2.1.0.GA Environment: JDK 5 JBoss AS 4.2.3 Reporter: Jozef Hartinger I am getting plenty of javax.ejb.NoSuchEJBException-s when undeploying nested booking example. For exceptions to appear preceeding interaction with example is needed. For details see attached log. -- 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

15 years, 11 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4069) Could not aquire lock to update nested set tree in org.jboss.seam.wiki.core.nestedset.listener.NestedSetMonitor

by Francisco Jose Peredo Noguez (JIRA)

Could not aquire lock to update nested set tree in org.jboss.seam.wiki.core.nestedset.listener.NestedSetMonitor --------------------------------------------------------------------------------------------------------------- Key: JBSEAM-4069 URL: https://jira.jboss.org/jira/browse/JBSEAM-4069 Project: Seam Issue Type: Bug Components: Wiki Reporter: Francisco Jose Peredo Noguez Assignee: Christian Bauer I was writing a long answer to a forum thread... I previewed it, it was fine, I clicked to post it and got (and of course lost all my text): HTTP Status 400 - Request failed, please check the application log or contact the administrator (christian.bauer(a)gmail.com): 'java.lang.RuntimeException, Could not aquire lock to update nested set tree in org.jboss.seam.wiki.core.nestedset.listener.NestedSetMonitor@43' type Status report message Request failed, please check the application log or contact the administrator (christian.bauer(a)gmail.com): 'java.lang.RuntimeException, Could not aquire lock to update nested set tree in org.jboss.seam.wiki.core.nestedset.listener.NestedSetMonitor@43' description The request sent by the client was syntactically incorrect (Request failed, please check the application log or contact the administrator (christian.bauer(a)gmail.com): 'java.lang.RuntimeException, Could not aquire lock to update nested set tree in org.jboss.seam.wiki.core.nestedset.listener.NestedSetMonitor@43'). -- 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

15 years, 11 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-3672) JpaPermissionStore throws IAE "Cannot resolve principal name for principal.."

by Stefano Travelli (JIRA)

JpaPermissionStore throws IAE "Cannot resolve principal name for principal.." ------------------------------------------------------------------------------ Key: JBSEAM-3672 URL: https://jira.jboss.org/jira/browse/JBSEAM-3672 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.0.SP1 Environment: JBoss 4.2.2 JVM 1.6.0 Reporter: Stefano Travelli Given the following conditions: - JpaPermissionStore configured with a permission entity having PermissionRole and PermissionUser properties mapped as @ManyToOne relations. - that @ManyToOne relations are lazy - checking a permission for a Class target (resolved by ClassIdentifierStrategy) JpaPermissionStore throws an IllegalStateException "Cannot resolve principal name for principal..". I'm figuring out the reason and working on a patch. -- 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

15 years, 11 months

2
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4080) Problems with Remote EJB as seam component on WebLogic 10.0 MP1/10.3

by Hiroyuki Wada (JIRA)

Problems with Remote EJB as seam component on WebLogic 10.0 MP1/10.3 --------------------------------------------------------------------- Key: JBSEAM-4080 URL: https://jira.jboss.org/jira/browse/JBSEAM-4080 Project: Seam Issue Type: Bug Components: EJB3 Affects Versions: 2.1.1.GA, 2.0.2.SP1 Environment: WebLogic 10.0 MP1/10.3 Reporter: Hiroyuki Wada There are two problems using Remote EJB as Seam Component on WebLogic 10.0 MP0/10.3. 1) Seam Interceptos(BijectionInterceptro etc.) aren't executed. Because of SessionBeanInterceptor can't initizalize Remote EJB on WebLogic 10.0/10.3, seam interceptors aren't executed. so it cause some problems, for example failure of injection by @In. 2) Cannot access to Unserializable Application Context Component from Remote EJB. I don't know why, but when access to ServletContext data in EJB Remote Object on WebLogic, serialize/deserialize is performed. In my reproduce app, there is NotSerializable application context component which injected at Remote EJB Component. so it cause NotSerializableException as follows. -- java.io.NotSerializableException: org.jboss.seam.example.remoteejb.AppData at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at weblogic.common.internal.PassivationUtils.toByteArray(PassivationUtils.java:33) at weblogic.common.internal.PassivationUtils.toByteArray(PassivationUtils.java:24) at weblogic.common.internal.PassivationUtils.copy(PassivationUtils.java:64) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:100) at weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java:52) at weblogic.servlet.internal.AttributesMap.get(AttributesMap.java:62) at weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java:482) at org.jboss.seam.servlet.ServletApplicationMap.get(ServletApplicationMap.java:54) at org.jboss.seam.contexts.BasicContext.get(BasicContext.java:49) at org.jboss.seam.contexts.Contexts.lookupInStatefulContexts(Contexts.java:219) at org.jboss.seam.Component.getInstance(Component.java:1949) at org.jboss.seam.Component.getInstance(Component.java:1944) at org.jboss.seam.Component.getInstanceInAllNamespaces(Component.java:2311) at org.jboss.seam.Component.getValueToInject(Component.java:2263) at org.jboss.seam.Component.injectAttributes(Component.java:1703) at org.jboss.seam.Component.inject(Component.java:1521) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.-- I created a patch for fix these problems. I describe how I fix. Problem 1) In weblogic, it seems that EJB Remote class is generated by weblogic ejb compiler, and InvocationContext#getTarget() return a class which don't have @Name annotation. So SessionBeanInterceptor can't initizalize this class correctly. I found the super class of the generated class has @Name annotation. so I fixed handling target class. Problem 2) I don't know why weblogic serialize/deserialize object when access to ServletContext in EJB Remote Object, it comes from the ContextClassLoader difference. In EJB Remote Object, the ContextClassLoader is EAR ClassLoader. In contrast, WAR ClassLoader is used when accessed from JSF, so I set WAR ClassLoader to ContextClassLoader before calling InvocationContext#proceed(). -- 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

15 years, 11 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4077) Refactor/Redesign org.jboss.seam.navigation.Pages

by Drew Kutchar (JIRA)

Refactor/Redesign org.jboss.seam.navigation.Pages ------------------------------------------------- Key: JBSEAM-4077 URL: https://jira.jboss.org/jira/browse/JBSEAM-4077 Project: Seam Issue Type: Feature Request Components: Core Affects Versions: 2.1.1.GA Reporter: Drew Kutchar Currently org.jboss.seam.navigation.Pages is a major pain point since some of the methods are marked private and some are static (don't know why). For example, selectDataModelRow() is private and it's got this line "if ( index<dataModel.getRowCount() )" in it which I don't think is really necessary. This caused a lot of pain for us when we were trying to integrate it with RichFaces ExtendedDataModel and DataScroller. Basically when you're getting ranges from the database, the RowCount would query the database. So we had to avoid using @DataModel and @DataModelSelection completely. I know I can override installing the Pages component, but then I have to copy/paste pretty much everything from Pages to our CustomPages just to change a line, talk about anti-DRY. I can give you more details on this if you want. In addition, the other not so cool method is "public static String getRequestScheme(FacesContext facesContext)" which determines if a request is secure by looking at the URL. There are scenarios that you would want to override this method. Consider the case when you have an SSL accelerator. The accelerator will terminate the SSL connection and create a new HTTP connection to the app server. Now you have the option to pass an HTTP header when the accelerator decrypts HTTPS packets so you're app server knows that the request was originally secure (so no need to redirect, or anything). This class has not been designed that well for extension and I think it can be improved. -- 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

15 years, 11 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4055) Create <s:requireAll /> tag

by Jakub Janczak (JIRA)

Create <s:requireAll /> tag --------------------------- Key: JBSEAM-4055 URL: https://jira.jboss.org/jira/browse/JBSEAM-4055 Project: Seam Issue Type: Feature Request Components: JSF Controls Reporter: Jakub Janczak Fix For: The future create similar to the s:validateAll tag that sets required=true for all refrenced methods (getters) that have @NotNull or @NotEmpty validation annotation. It could be quite handy but require some reflection work (as you can't get the validators from ClassValidator class). -- 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

15 years, 11 months

3
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4075) Unclosed input stream in org.jboss.seam.remoting.Remoting

by Yannick Lazzari (JIRA)

Unclosed input stream in org.jboss.seam.remoting.Remoting --------------------------------------------------------- Key: JBSEAM-4075 URL: https://jira.jboss.org/jira/browse/JBSEAM-4075 Project: Seam Issue Type: Bug Components: Remoting Affects Versions: 2.1.1.GA Reporter: Yannick Lazzari Assignee: Shane Bryzak Priority: Trivial In the writeResource method of the org.jboss.seam.remoting.Remoting class, an InputStream is opened by accessing a resource from the ClassLoader but the stream is never closed. This causes a WARNING on redeploy on GlassFish (and possibly other application servers). Here's the stack trace: [#|2009-04-02T15:51:57.198-0400|WARNING|sun-appserver9.1|javax.enterprise.system.core.classloading|_ThreadID=19;_ThreadName=Timer-7;_RequestID=8a50203b-a5f7-4e68-947d-6a1cabd7a73b;|Input stream has been finalized or forced closed without being explicitly closed; stream instantiation reported in following stack tr java.lang.Throwable at com.sun.enterprise.loader.EJBClassLoader$SentinelInputStream.<init>(EJBClassLoader.java:1165) at com.sun.enterprise.loader.EJBClassLoader$InternalJarURLConnection.getInputStream(EJBClassLoader.java:1258) at java.net.URL.openStream(URL.java:1009) at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1170) at com.sun.enterprise.loader.EJBClassLoader.getResourceAsStream(EJBClassLoader.java:795) at org.jboss.seam.remoting.Remoting.writeResource(Remoting.java:168) at org.jboss.seam.remoting.Remoting.getResource(Remoting.java:123) at org.jboss.seam.servlet.SeamResourceServlet.service(SeamResourceServlet.java:80) at javax.servlet.http.HttpServlet.service(HttpServlet.java:831) at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:317) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:390) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:517) at org.jboss.seam.web.Ajax4jsfFilter.doFilter(Ajax4jsfFilter.java:56) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.HotDeployFilter.doFilter(HotDeployFilter.java:53) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.mcgill.moxxi.filter.PresentationContextFilter.doFilter(PresentationContextFilter.java:55) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:198) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:288) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568) at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263) at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214) at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265) at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:116) -- 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

15 years, 11 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4071) Seam does not seem to honor import declarations for EJB3 components.

by Arshad Mahmood (JIRA)

Seam does not seem to honor import declarations for EJB3 components. -------------------------------------------------------------------- Key: JBSEAM-4071 URL: https://jira.jboss.org/jira/browse/JBSEAM-4071 Project: Seam Issue Type: Bug Components: EJB3 Affects Versions: 2.1.1.GA Environment: Windows Vista x64, JBoss 5.1.0.GA Reporter: Arshad Mahmood Under seam one name component like @Name("org.acme.components.SuperAction") and then use an import statement in components.xml like <import>org.acme.components</import>. This allows the views to use "SuperAction" without the full name. It's a nice feature as it stops component developers from polluting the namespace, but still allows users to use a simple name for the action. This works OK for basic Seam components, but not for EJB3 components. For these the import declaration seems to be ignored. -- 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

15 years, 11 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4074) Internet Explorer 7.0 session cache not cleaned

by Shervin Asgari (JIRA)

Internet Explorer 7.0 session cache not cleaned ----------------------------------------------- Key: JBSEAM-4074 URL: https://jira.jboss.org/jira/browse/JBSEAM-4074 Project: Seam Issue Type: Bug Components: Security Affects Versions: 2.1.1.GA Environment: Windows XP Internet Explorer 7.0 Reporter: Shervin Asgari Our test developer found something quite strange. We have a page, which is restricted with a admin role. This is what he did to find the error: 1. Login as admin 2. Click on some of the admin stuff (creating users, listing users etc) 3. Copy url of the admin page 4. Logout 5. Login as user 6. Paste url of admin page Now in opera and firefox under Linux this didnt work. You got the error page with limited restriction message. However on windows and Internet Explorer 7, when pasting the url, you can view ALL the admin pages through the url. Listing the users, creating users, the home page of the admin etc. So seams like the cache of Internet Explorer is not properly cleaned. Now is this a bug in Seam or is the security in Internet Explorer? -- 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

15 years, 11 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-4073) Hot deployment broken with JBoss 5.0.1.GA

by Jozef Hartinger (JIRA)

Hot deployment broken with JBoss 5.0.1.GA ----------------------------------------- Key: JBSEAM-4073 URL: https://jira.jboss.org/jira/browse/JBSEAM-4073 Project: Seam Issue Type: Bug Components: Hot Deploy Environment: JBoss 5.0.1 GA JDK 5 update 16 Seam trunk Reporter: Jozef Hartinger Assignee: Pete Muir Priority: Critical Fix For: 2.1.2.CR1 Hot deployment does not seem to work. I am using seam-gen to create a war packaged application and deploy it on JBoss 5.0.1 GA. It deploys fine, but: a) deployment of XHTML template modified facelet templates are not being picked up b) deployment of action Java Bean I run new-action to create a ping action component and run "explode" target. Component does not deploy. There is nothing in the server log that would indicate that server is even trying to load the component. All mentioned above works fine on JBoss 4.2.3 and JBoss 5.0.0 -- 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

15 years, 11 months

3
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues April 2009