October 2007 - seam-issues - Jboss List Archives

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1712) Allow options for SMPC per Nested Conversation

by Andy Gibson (JIRA)

Allow options for SMPC per Nested Conversation ---------------------------------------------- Key: JBSEAM-1712 URL: http://jira.jboss.com/jira/browse/JBSEAM-1712 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.BETA1 Environment: Windows XP, Seam 2.0 Beta, JBoss 4.2 Reporter: Andy Gibson I'd like to request the option to specify that a nested conversation gets it's own entity manager instance as opposed to sharing it with it's parent conversation and other nested conversations. The problem with nested conversations is that you can't actually use them to edit multiple entities since when you flush the PC, you flush it for all conversations. This makes nested conversations only really useful for browsing data, and creating new top level conversation to edit items to isolate the flushes. The only alternative is to use a non-Seam managed PC, and make use of the "PC per stateful bean" rule to map a single PC to a single backing bean, but you lose the benefits of a seam managed PC. What might be nice is something like : @Begin(nested=true, newPC=true) and <begin-conversation nested="true" newPC="true"/> which would indicate that this new nested conversation gets it's own entity manager instance. The attribute would be ignored if this wasn't a nested conversation, and obviously, by default, the attribute is set to false, and a shared PC would be used in the nested conversation in such cases. I'm already using one PC per conversation by using top level conversations to edit items, I'd just like to use one PC per nested conversation (where applicable) to get the benefits of nested conversations. There are a couple of posts in the forums where I've touched on some of my problems with this issue : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384 http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113362 -- 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

14 years, 8 months

7
9
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1498) inject JBoss service EJB with @In

by koen handekyn (JIRA)

inject JBoss service EJB with @In --------------------------------- Key: JBSEAM-1498 URL: http://jira.jboss.com/jira/browse/JBSEAM-1498 Project: JBoss Seam Issue Type: Feature Request Components: EJB3 Reporter: koen handekyn Priority: Minor to inject a Service EJB into a seam component, for consistency it would certainly be very nice to be able to inject it within SEAM with @In and optionally adding an @Name attribute to the service class. it would be more consistent and shorter than the standard jboss approach (below) private GlobalConfigurationMBean globalConfiguration; @Depends ("upr:service=globalConfiguration") public void setGlobalConfiguration(final GlobalConfigurationMBean globalConfiguration) { this.globalConfiguration = globalConfiguration; } -- 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

14 years, 8 months

3
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1707) @Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time

by Frits Jalvingh (JIRA)

@Destroy method on APPLICATION scope bean throws IllegalState(no context) at server stop time --------------------------------------------------------------------------------------------- Key: JBSEAM-1707 URL: http://jira.jboss.com/jira/browse/JBSEAM-1707 Project: JBoss Seam Issue Type: Bug Components: Core Affects Versions: 2.0.0.BETA1 Environment: Tomcat 6.0.10, JavaBean mode, Hibernate 3.2.3, HBEM 3.3.1 Reporter: Frits Jalvingh I have a bean defined as follows: @Name("initBean") @Startup() @Scope(ScopeType.APPLICATION) public class InitBean { containing a method: @Destroy public void destroy() { Builder.getInstance().terminate(); BuildBot.getInstance().stop(); } It is meant to shutdown some daemons when the server stops. When the server stops I get an exception: 01:15:39,703 WARN [Component] Exception calling component @Destroy method: initBean java.lang.IllegalStateException: no event context active at org.jboss.seam.web.ServletContexts.instance(ServletContexts.java:40) at org.jboss.seam.web.Parameters.getRequestParameters(Parameters.java:39) at org.jboss.seam.faces.Parameters.getRequestParameters(Parameters.java:64) at org.jboss.seam.Component.injectParameters(Component.java:1334) at org.jboss.seam.Component.inject(Component.java:1304) at org.jboss.seam.core.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:45) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.core.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:42) at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:68) at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:106) at org.jboss.seam.intercept.JavaBeanInterceptor.interceptInvocation(JavaBeanInterceptor.java:151) at org.jboss.seam.intercept.JavaBeanInterceptor.invoke(JavaBeanInterceptor.java:87) at to.etc.saram.beans.InitBean_$$_javassist_0.destroy(InitBean_$$_javassist_0.java) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 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:21) at org.jboss.seam.util.Reflections.invokeAndWrap(Reflections.java:124) at org.jboss.seam.Component.callComponentMethod(Component.java:1957) at org.jboss.seam.Component.callDestroyMethod(Component.java:1888) at org.jboss.seam.Component.destroy(Component.java:1217) at org.jboss.seam.contexts.Contexts.destroy(Contexts.java:251) at org.jboss.seam.contexts.Lifecycle.endApplication(Lifecycle.java:52) at org.jboss.seam.contexts.ServletLifecycle.endApplication(ServletLifecycle.java:121) at org.jboss.seam.servlet.SeamListener.contextDestroyed(SeamListener.java:39) at org.apache.catalina.core.StandardContext.listenerStop(StandardContext.java:3866) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4502) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1068) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448) at org.apache.catalina.core.StandardService.stop(StandardService.java:510) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744) at org.apache.catalina.startup.Catalina.stop(Catalina.java:602) at org.apache.catalina.startup.Catalina.start(Catalina.java:577) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) which seems to be caused by the bean Injector trying to access the request context which of course is no longer there. The bean contains only a single injected thingy which is the entityManager. -- 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

14 years, 8 months

4
6
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1879) Magic mime type detection support

by Christian Bauer (JIRA)

Magic mime type detection support --------------------------------- Key: JBSEAM-1879 URL: http://jira.jboss.com/jira/browse/JBSEAM-1879 Project: JBoss Seam Issue Type: Feature Request Components: Core Reporter: Christian Bauer Priority: Minor A component I can call to find out what mime type a particular byte[] or ByteInputStream is. The only existing solution in Java is http://sourceforge.net/projects/jmimemagic/ but it's basically an unmaintained half-working pile of junk. It's interesting that nobody ever build a simple port of file(1), which you get on every unix box, together with a fantastic (/etc/magic or /usr/share/file/magic on the Mac) database of magic bytes found in file headers. We should just take that database (or the source database from which it is generated) and write our own file(1) for Seam. Search for "mime magic java" with Google and you see why it's needed. Try "file myfile.foo" on every unix box (well, younger than 10 years) and you see how it works. -- 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

14 years, 8 months

2
1
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-769) Per view exception handling

by Peter Muir (JIRA)

Per view exception handling --------------------------- Key: JBSEAM-769 URL: http://jira.jboss.com/jira/browse/JBSEAM-769 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 1.1.6.GA Reporter: Peter Muir Would be useful to be able to handle an exception differently depending on the current view id - especially for foo.page.xml style pages.xml -- 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

14 years, 8 months

6
8
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1898) EntityQuery hints map is defined as <String, String> instead of <String, Object>

by david castannon (JIRA)

EntityQuery hints map is defined as <String, String> instead of <String, Object> -------------------------------------------------------------------------------- Key: JBSEAM-1898 URL: http://jira.jboss.com/jira/browse/JBSEAM-1898 Project: JBoss Seam Issue Type: Bug Reporter: david castannon EntityQuery hints map field is defined as <String, String> instead of <String, Object> used at hibernate method setHint of QueryImpl. So, if you want to set, e.g., "org.hibernate.cacheMode" hint with CacheMode.REFRESH jboss throws exception. -- 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

14 years, 9 months

4
6
0 / 0

[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

14 years, 9 months

4
4
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

14 years, 9 months

10
17
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

14 years, 10 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

14 years, 10 months

7
18
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

seam-issues October 2007