July 2008 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1592) <s:graphicImage> should accept raw byte[] without conversion

by Gena Batalski (JIRA)

<s:graphicImage> should accept raw byte[] without conversion ------------------------------------------------------------ Key: JBSEAM-1592 URL: http://jira.jboss.com/jira/browse/JBSEAM-1592 Project: JBoss Seam Issue Type: Feature Request Components: JSF Affects Versions: 2.0.0.BETA1, 1.3.0.ALPHA, 1.2.1.GA Environment: latest from repo Reporter: Gena Batalski Priority: Minor It would be helpful to feed the <s:graphicImage> with raw byte[] (possible also ByteArray - stream) without converting it to BufferedImage or something else. Also the content type could be manually entered. Of course, its in the responsibility of the developer, to take care about the correctness of input. Optional attributes (forceContentType, forceImage or something else) could do this job on the UI side. Background of the request: if i comment out the byte[] handling in Image.class (line 404 method readImage()) as in a following snipplet, i get an expected quality. Otherwise, the image quality decreases significantly, especially for small images (icons, thumbnails). /* byte[] b = (byte[]) input; readImage(new ByteArrayInputStream(b)); */ output = (byte[]) input; I also would have some possibility, to prepare the image on demand. Currently i'm using two servlets: one SeamResource and one for my images. My servlet receives an URI and selects an image LOB from DB, because it isn't necessary to store the images in memory (they could be large) and the images could stay unrequested. What i need is some kind callback (converter?) which asks me for byte[] or stream representation of an image uri. Thanks Gena -- 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

15 years, 4 months

4
4
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2429) converterId in Seam page param not recognised in EAR project structure

by Terry (JIRA)

converterId in Seam page param not recognised in EAR project structure ---------------------------------------------------------------------- Key: JBSEAM-2429 URL: http://jira.jboss.com/jira/browse/JBSEAM-2429 Project: JBoss Seam Issue Type: Bug Affects Versions: 2.0.0.GA Environment: Windows, Project Structure EAR, JBoss 4.2 EAP. Seam2+Sun JSF RI+Facelets+Richfaces. Reporter: Terry In a EAR project structure; assigning converterId in page parameter in .page.xml file is not recognised. Throws errors: javax.faces.FacesException: Expression Error: Named Object: org.jboss.seam.ui.converter.DateTimeConverter not found. <param name="settlementDateFrom" converterId="org.jboss.seam.ui.converter.DateTimeConverter" value="#{paymentReconciliation.settlementDateFrom}"/> See forum issue for more details. -- 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

15 years, 4 months

5
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2759) Seam dist directory structure verification and comparison between releases.

by Jay Balunas (JIRA)

Seam dist directory structure verification and comparison between releases. ----------------------------------------------------------------------------- Key: JBSEAM-2759 URL: http://jira.jboss.com/jira/browse/JBSEAM-2759 Project: JBoss Seam Issue Type: Task Components: Build Affects Versions: 2.1.0.A1, 2.0.1.GA Reporter: Jay Balunas Assigned To: Jay Balunas Seam release directory structure verification and comparison between releases. This can be done through existing tools, and ant scripts. It will provide a information on where risk has been added and also fine issues related structure between releases. May be integrated with CI if able. -- 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

15 years, 4 months

2
3
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1855) FacesMessages.instance().addToControl and Datatable do not work properly

by Andy Bosch (JIRA)

FacesMessages.instance().addToControl and Datatable do not work properly ------------------------------------------------------------------------ Key: JBSEAM-1855 URL: http://jira.jboss.com/jira/browse/JBSEAM-1855 Project: JBoss Seam Issue Type: Bug Components: JSF Affects Versions: 1.2.0.GA Reporter: Andy Bosch It is possible do add FacesMessages via the Seam functionality with FacesMessages.instance().addToControl. In the parameters you have to pass the component id. In the plain JSF way, you can add FacesMessages via FacesContext ... addMessage. In the JSF-way you have to pass the client-id. With normal input components you can use both ways. But when you work with datatables, you MUST work with the client-id, the Seam-way with using only the component-id does NOT work. Explanation: When using a datatable-tag, you only have one component. The renderer generates the various rows. In the component-tree there is yet only one component! If you want to add a FacesMessage to one row, you can only work with client-ids (because you have to include the row-index). My wish: Please change FacesMessages.instance().addToControl. for using with client-ids. -- 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

15 years, 4 months

10
17
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2921) Wiki permission checking sometimes results in "no file extension in servlet path"

by Christian Bauer (JIRA)

Wiki permission checking sometimes results in "no file extension in servlet path" --------------------------------------------------------------------------------- Key: JBSEAM-2921 URL: http://jira.jboss.com/jira/browse/JBSEAM-2921 Project: Seam Issue Type: Bug Components: Wiki Reporter: Christian Bauer Assigned To: Christian Bauer I've seen this in the live log sometimes, couldn't reproduce it until now: Trigger a @Factory method on a page, the component that has the @Factory method has @Create public void create() { if (!Identity.instance().hasPermission("User", "isAdmin", (User)Component.getInstance("currentUser") ) ) { throw new AuthorizationException("You don't have permission for this operation"); } } This is from AdminHome.java. So for example try to access 'systemPreferenceEntities' variable without being an admin. This will result in a permission exception which is hidden and obscured by another exception in the exception handling phase: >>> 12:45:02,053 DEBUG [org.jboss.seam.contexts.FacesLifecycle] >>> Begin exception recovery >>> 12:45:02,055 DEBUG [org.jboss.seam.core.Manager] No stored conversation, or concurrent call to the stored conversation >>> 12:45:02,059 DEBUG [org.jboss.seam.exception.Exceptions] reading exception mappings from /WEB-INF/pages.xml >>> 12:45:02,064 DEBUG [org.jboss.seam.faces.Navigator] redirecting to: /wiki.xhtml >>> 12:45:02,064 DEBUG [org.jboss.seam.contexts.FacesLifecycle] After render response, destroying contexts >>> 12:45:02,066 DEBUG [org.jboss.seam.contexts.FacesLifecycle] <<< End JSF request for /wiki/ >>> 12:45:02,066 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/wiki].[default]] Servlet.service() for servlet default threw exception java.lang.IllegalArgumentException: no file extension in servlet path: / at org.jboss.seam.mock.MockViewHandler.getActionURL(MockViewHandler.java:44) at org.jboss.seam.jsf.SeamViewHandler.getActionURL(SeamViewHandler.java:74) at org.jboss.seam.faces.FacesManager.redirect(FacesManager.java:162) at org.jboss.seam.faces.Navigator.redirect(Navigator.java:50) at org.jboss.seam.exception.RedirectHandler.handle(RedirectHandler.java:51) at org.jboss.seam.exception.Exceptions.handle(Exceptions.java:76) at org.jboss.seam.web.ExceptionFilter.endWebRequestAfterException(ExceptionFilter.java:114) at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:70) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281) 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.LoggingFilter.doFilter(LoggingFilter.java:58) 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:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446) at java.lang.Thread.run(Thread.java:613) -- 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

15 years, 4 months

5
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1572) Make s:decorate behave more similarly to ui:decorate (h:panelGrid-friendly)

by Alex Savitsky (JIRA)

Make s:decorate behave more similarly to ui:decorate (h:panelGrid-friendly) --------------------------------------------------------------------------- Key: JBSEAM-1572 URL: http://jira.jboss.com/jira/browse/JBSEAM-1572 Project: JBoss Seam Issue Type: Feature Request Components: JSF Reporter: Alex Savitsky Priority: Minor ui:decorate preserves its children, while s:decorate groups them as one instead. This makes s:decorate unusable for form fields laid out using h:panelGrid, as there's no way to separate the field label from the field itself (they are grouped together). -- 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

15 years, 5 months

9
23
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2093) Optimize getting Id in Seam code for better performance

by Mikhail Grushinskiy (JIRA)

Optimize getting Id in Seam code for better performance ------------------------------------------------------- Key: JBSEAM-2093 URL: http://jira.jboss.com/jira/browse/JBSEAM-2093 Project: JBoss Seam Issue Type: Feature Request Reporter: Mikhail Grushinskiy This sequence of calls (used in PersistenceProvider) is quite slow Entity.forClass(bean.getClass()).getIdentifier(bean); 1) Entity.forClass() is reading annotations using JDK 5 methods (JDK 5 annotation reading is not that fast). Can it be cached? 2) JDK 5 reflection is used to get bean id (which is slower than optmized reflection with cglib) 3) There could be other reasons as well. I think repetitive calling of this sequence under profiler will give better picture. from PersistenceProvider.java /** * Get the value of the entity identifier attribute. * * @param bean a managed entity instance */ public Object getId(Object bean, EntityManager entityManager) { return Entity.forClass( bean.getClass() ).getIdentifier(bean); } /** * Get the name of the entity * * @param bean * @param entityManager */ public String getName(Object bean, EntityManager entityManager) { return Entity.forClass(bean.getClass()).getName(); } /** * Get the value of the entity version attribute. * * @param bean a managed entity instance */ public Object getVersion(Object bean, EntityManager entityManager) { return Entity.forClass( bean.getClass() ).getVersion(bean); } -- 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

15 years, 5 months

7
18
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2255) Undeploying multiple wars inside an ear causes IllegalStateException.

by Richard Teviotdale (JIRA)

Undeploying multiple wars inside an ear causes IllegalStateException. --------------------------------------------------------------------- Key: JBSEAM-2255 URL: http://jira.jboss.com/jira/browse/JBSEAM-2255 Project: JBoss Seam Issue Type: Bug Affects Versions: 2.0.0.GA Environment: Debian GNU/Linux x86_64 2.6.18-4 SMP, Java 1.5.0_12, JBoss 4.2.1.GA, Seam 2.0.0.GA. Reporter: Richard Teviotdale When undeploying an ear that contains two wars an IllegalStateException is generated. I have not checked for more than two wars but I suspect an exception would be generated for each undeploying war after the first. This exception does not prevent the server from undeploying and redeploying the ear, it just produces an error and stacktrace in the server log. Here's how to duplicate. - make a generic seam-gen project called test deployed as an ear - ant explode - go to $JBOSS_HOME/default/deploy/test.ear - recursive copy test.war directory to test2.war - edit META-INF/application.xml and create deploy entry for test2.war - run server - touch META-INF/application.xml see server log for following stack trace: 15:05:11,798 INFO [TomcatDeployer] undeploy, ctxPath=/test2, warUrl=.../deploy/test.ear/test2.war/ 15:05:12,067 INFO [TomcatDeployer] undeploy, ctxPath=/test, warUrl=.../deploy/test.ear/test.war/ 15:05:12,068 ERROR [[/test]] Session event listener threw exception java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36) at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:220) at org.jboss.seam.contexts.ServletLifecycle.endSession(ServletLifecycle.java:129) at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:49) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:702) at org.apache.catalina.session.StandardSession.expire(StandardSession.java:660) snip... 15:05:12,276 ERROR [[/test]] Exception sending context destroyed event to listener instance of class org.jboss.seam.servlet.SeamListener java.lang.IllegalStateException: Attempted to invoke a Seam component outside the an initialized application at org.jboss.seam.contexts.Lifecycle.getApplication(Lifecycle.java:36) at org.jboss.seam.contexts.Lifecycle.endApplication(Lifecycle.java:50) at org.jboss.seam.contexts.ServletLifecycle.endApplication(ServletLifecycle.java:118) at org.jboss.seam.servlet.SeamListener.contextDestroyed(SeamListener.java:39) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3893) -- 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

15 years, 6 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1486) Posibility to configure session scope type when in portlet environment

by ivica c (JIRA)

Posibility to configure session scope type when in portlet environment ---------------------------------------------------------------------- Key: JBSEAM-1486 URL: http://jira.jboss.com/jira/browse/JBSEAM-1486 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 1.3.0.ALPHA Reporter: ivica c Fix For: 1.3.0.GA It would be nice to have a possibility to define the session scope type in the portlet environment: portlet scope or application scope. It affects not only seam session scope but also the conversation scope because the conversation scope internally uses the session scope. Now, seam components can be saved only in the portlet session scope so it is not possible to share data between portlets. If there is possibility to set components can be saved in the application scope, then data will be able to be shared between portlets in the same war. -- 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

15 years, 6 months

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2579) Messages.properties do not work as expected with multiple WARs inside multiple Seam EARs

by Reind D (JIRA)

Messages.properties do not work as expected with multiple WARs inside multiple Seam EARs ---------------------------------------------------------------------------------------- Key: JBSEAM-2579 URL: http://jira.jboss.com/jira/browse/JBSEAM-2579 Project: JBoss Seam Issue Type: Bug Components: JSF Integration Affects Versions: 2.0.1.GA Environment: JBoss 4.2.2 Reporter: Reind D When 2 Seam apps are deployed, both with multiple WARs each of which as a WEB-INF/classes/messages.properties file, the messages for one of the web contexts will not work. Instead, the messages for the other WAR in the same EAR will be displayed. I've attached a sample application that demonstrates this behavior. It is modified from the "Registration" example. Steps: 1) Untar the archive 2) Copy to the app server's deploy directory 3) Go to the following URLs: http://localhost:8080/a/register.seam http://localhost:8080/b/register.seam http://localhost:8080/c/register.seam http://localhost:8080/d/register.seam The 'expected' and 'actual' fields should always match, but they won't in 1 case. -- 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

15 years, 6 months

3
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues July 2008