September 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1388) s:fileUpload doesn't work in Portlet

by jarkko Lietolahti (JIRA)

s:fileUpload doesn't work in Portlet ------------------------------------ Key: JBSEAM-1388 URL: http://jira.jboss.com/jira/browse/JBSEAM-1388 Project: JBoss Seam Issue Type: Bug Affects Versions: 1.2.1.GA Reporter: jarkko Lietolahti >From UIFileUpload.java: @Override public void decode(FacesContext context) { super.decode(context); ServletRequest request = (ServletRequest) context.getExternalContext().getRequest(); } In portal/portlet, one gets ActionRequest (which extends PortalRequest) instead of ServletRequest. Nested Exception is java.lang.ClassCastException: com.liferay.portlet.ActionRequestImpl cannot be cast to javax.servlet.ServletRequest at org.jboss.seam.ui.UIFileUpload.decode(UIFileUpload.java:35) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:606) at javax.faces.component.UIForm.processDecodes(UIForm.java:53) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:602) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:135) at org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues(LifecycleImpl.java:219) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:71) at org.apache.myfaces.portlet.MyFacesGenericPortlet.processAction(MyFacesGenericPortlet.java:220) at com.liferay.portal.kernel.servlet.PortletServlet.service(PortletServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at com.liferay.portlet.CachePortlet._invoke(CachePortlet.java:333) at com.liferay.portlet.CachePortlet.processAction(CachePortlet.java:157) at com.liferay.portal.action.LayoutAction._processPortletRequest(LayoutAction.java:269) at com.liferay.portal.action.LayoutAction._processActionRequest(LayoutAction.java:290) at com.liferay.portal.action.LayoutAction.execute(LayoutAction.java:113) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at com.liferay.portal.struts.PortalRequestProcessor.process(PortalRequestProcessor.java:156) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at com.liferay.portal.servlet.MainServlet.callParentService(MainServlet.java:479) at com.liferay.portal.servlet.MainServlet.service(MainServlet.java:877) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.filters.strip.StripFilter.doFilter(StripFilter.java:94) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.filters.secure.SecureFilter.doFilter(SecureFilter.java:143) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.filters.compression.CompressionFilter.doFilter(CompressionFilter.java:115) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.portal.servlet.filters.layoutcache.LayoutCacheFilter.doFilter(LayoutCacheFilter.java:197) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.portal.servlet.filters.autologin.AutoLoginFilter.doFilter(AutoLoginFilter.java:117) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at com.liferay.portal.servlet.filters.virtualhost.VirtualHostFilter.doFilter(VirtualHostFilter.java:169) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at net.hyperic.hq.product.servlet.filter.JMXFilter.doFilter(JMXFilter.java:277) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) 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: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1979) wrong default class for mssql in seam-gen : set as com.microsoft.sqlserver.jdbc.SQLServerDriver instead of com.microsoft.jdbc.sqlserver.SQLServerDriver

by thierry accart (JIRA)

wrong default class for mssql in seam-gen : set as com.microsoft.sqlserver.jdbc.SQLServerDriver instead of com.microsoft.jdbc.sqlserver.SQLServerDriver ------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBSEAM-1979 URL: http://jira.jboss.com/jira/browse/JBSEAM-1979 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 1.2.1.GA Environment: seam-gen build.xml Reporter: thierry accart The build.xml for seam-gen contains a wrong default class for MSSQL driver : it's set with <condition property="hibernate.connection.driver_class.default" value="com.microsoft.sqlserver.jdbc.SQLServerDriver"> <equals arg1="${database.type.new}" arg2="mssql"/> </condition> but the class for miscrosoft sql server is com.microsoft.jdbc.sqlserver.SQLServerDriver -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1532) include jar-versions.xml file

by Dan Allen (JIRA)

include jar-versions.xml file ----------------------------- Key: JBSEAM-1532 URL: http://jira.jboss.com/jira/browse/JBSEAM-1532 Project: JBoss Seam Issue Type: Feature Request Components: Documentation Affects Versions: 1.3.0.ALPHA Environment: seam CVS HEAD Reporter: Dan Allen Priority: Minor It would be so helpful if a jar-versions.xml file could be kept up to date in the root of the seam source code to track the versions of the bundle libraries, in the absence of other solutions. This idea comes from the JBoss AS, which uses this file to communicate the versions of libraries used. Documenting the versions helps: 1. developers, who may find challenge in combining APIs of libraries without knowing the version 2. users who are unable to determine the contents of what they downloaded 3. for legal reasons, just in case there are differences in licenses amongst releases of third party products, to protect seam itself as well as integrators of seam. With all that said, the better solution is to use ant-ivy or maven2 to get the jar files out of the source code. But I digress. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1679) passing callId to callback after async call

by Christoph Aigner (JIRA)

passing callId to callback after async call ------------------------------------------- Key: JBSEAM-1679 URL: http://jira.jboss.com/jira/browse/JBSEAM-1679 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Affects Versions: 2.0.0.BETA1 Reporter: Christoph Aigner Assigned To: Shane Bryzak Priority: Trivial passing callId (remote.js / line 732): call.callback(value, context, callId); makes it possible to differentiate between simultanous calls of certain functions, as callId is already returned on function call necessary if options/variables are related to certain backend-calls. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1672) Dependency on JMS

by Ralph Schaer (JIRA)

Dependency on JMS ----------------- Key: JBSEAM-1672 URL: http://jira.jboss.com/jira/browse/JBSEAM-1672 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Affects Versions: 2.0.0.BETA1 Environment: JavaBeans, Hibernate, Tomcat 6.0.13, Java 6, Windows XP Reporter: Ralph Schaer Assigned To: Shane Bryzak Priority: Optional Seam Remoting has a dependency on JMS. The problem is that the RequestHandlerFactory instantiate the PollHandler in the constructor. In a non EE environment like Tomcat I have to put a JMS library into the classpath although the application does not need JMS. Not a big deal, but maybe it's possible to change Seam Remoting that it loads PollHandler only when there is a JMS library in the classpath. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1224) Consider integration of security with App Framework

by Pete Muir (JIRA)

Consider integration of security with App Framework --------------------------------------------------- Key: JBSEAM-1224 URL: http://jira.jboss.com/jira/browse/JBSEAM-1224 Project: JBoss Seam Issue Type: Feature Request Components: Core, Security Affects Versions: 1.2.1.GA Reporter: Pete Muir Assigned To: Shane Bryzak >From the forums: 'One down side to using EntityHome for generic crud is lack of built in security. One needs to be careful when using Homes for crud operations that allow or require RequestParameters. You need to ensure the operation on this ID is valid. You don't want to expose information you shouldn't and you definitely don't want to modify or destroy information you shouldn't. For example, you don't want a user to update or delete another user's entity just by changing an ID in the URL and hitting return. Seam supports entity level security and you can probably extend a Home to double check access restrictions prior to operations. Likewise, you don't want private information available on lets say a user profile screen, to be available to anyone able to modify a URL.' -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

3
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-895) Support re-setting the principal in identity without relogin

by Christian Bauer (JIRA)

Support re-setting the principal in identity without relogin ------------------------------------------------------------ Key: JBSEAM-895 URL: http://jira.jboss.com/jira/browse/JBSEAM-895 Project: JBoss Seam Issue Type: Feature Request Components: Security Reporter: Christian Bauer Assigned To: Shane Bryzak Priority: Minor I'm allow my users to change passwords and usernames while they are logged in. After such a change of credentials, I need to replace the principal in the identity component. This can currently only be done through logout() and login(), manually by the user. I want to do this automatically, and I don't want to destroy the session for that. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1507) Make Identity usable outside of JSF app

by Gavin King (JIRA)

Make Identity usable outside of JSF app --------------------------------------- Key: JBSEAM-1507 URL: http://jira.jboss.com/jira/browse/JBSEAM-1507 Project: JBoss Seam Issue Type: Feature Request Components: Security Reporter: Gavin King Assigned To: Shane Bryzak Fix For: 1.3.0.BETA2 Currently the Identity class has hard dependencies to JSF classes. This really would not be a big deal except that we cant split it into Identity/FacesIdentity, since it is already split into Identity/RuleBasedIdentity. We would need to split some functionality out to another component. (yick) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1634) More customizable hot redeployment

by Christian Bauer (JIRA)

More customizable hot redeployment ---------------------------------- Key: JBSEAM-1634 URL: http://jira.jboss.com/jira/browse/JBSEAM-1634 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor Attachments: flexible_hot_redployment.patch The attached patch adds several things: - ability to specify the hot deployment directory as a servlet context init parameter (seam.HOT_DEPLOY_DIRECTORY) - ability to access the used RedeployableStrategy from the application context (to get the classloader, etc) - an additional descriptor (hot-components.xml) that can be used in the hot deploy directory I use this to boot Seam from an embeddable webserver with a custom parent classloader and to start Embedded JBoss with the same child classloader that Seam is using. I effectively get complete hot redeployment of all Seam components, EJBs, and persistence units. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1471) @Child annotation for GWT

by Gavin King (JIRA)

@Child annotation for GWT ------------------------- Key: JBSEAM-1471 URL: http://jira.jboss.com/jira/browse/JBSEAM-1471 Project: JBoss Seam Issue Type: Feature Request Components: Remoting Reporter: Gavin King Assigned To: Shane Bryzak The EntryPoint class is ugly boilerplate. You should be able to annotate your GWT class with @Child("theId") and it will be automagically added in when the module loads. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 2 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues September 2007