August 2007 - 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

16 years, 7 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

16 years, 7 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

16 years, 8 months

9
23
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

16 years, 9 months

4
5
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-967) JBoss Seam - Support authentication from a realm (on Tomcat)

by Bradley Smith (JIRA)

JBoss Seam - Support authentication from a realm (on Tomcat) ------------------------------------------------------------ Key: JBSEAM-967 URL: http://jira.jboss.com/jira/browse/JBSEAM-967 Project: JBoss Seam Issue Type: Feature Request Components: Security Reporter: Bradley Smith Please see discussion in the JBoss forum reference. The idea is to allow the Seam Identity (security) component to get the Principal from the HttpServletRequest and to delegate the hasRole() calls to the HttpServletRequest as well. This is because, in my case, Tomcat has already forced the user to authenticate if necessary and the authentication, authorization information is available in the container's HttpServletRequest impl. Principal userPrincipal = httpServletRequest.getUserPrincipal(); boolean hasRole(String roleName) { return httpServletRequest.isUserInRole(roleName); } public String getUsername() { return httpServletRequest.getRemoteUser(); } public boolean isLoggedIn() { return httpServletRequest.getUserPrincipal() != null; } -- 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

16 years, 9 months

4
14
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1587) page parameters: option to bypass model-based validations

by Hung Tang (JIRA)

page parameters: option to bypass model-based validations --------------------------------------------------------- Key: JBSEAM-1587 URL: http://jira.jboss.com/jira/browse/JBSEAM-1587 Project: JBoss Seam Issue Type: Feature Request Components: Core Affects Versions: 2.0.0.BETA1 Reporter: Hung Tang -- 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

16 years, 10 months

7
21
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1662) seam-gen apps deploying to tomcat

by Matt Drees (JIRA)

seam-gen apps deploying to tomcat --------------------------------- Key: JBSEAM-1662 URL: http://jira.jboss.com/jira/browse/JBSEAM-1662 Project: JBoss Seam Issue Type: Feature Request Affects Versions: 2.0.0.BETA1 Reporter: Matt Drees Priority: Minor Now that tomcat deployment is much easier (by using embedded Jboss), can seam-gen'd build.xml files (1) have a deploy.tomcat target? (2) have an explode.tomcat target? (for hot deploy functionality) -- 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

17 years

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-881) seam-gen suppport for Tomcat

by alberto Gori (JIRA)

seam-gen suppport for Tomcat ----------------------------- Key: JBSEAM-881 URL: http://jira.jboss.com/jira/browse/JBSEAM-881 Project: JBoss Seam Issue Type: Feature Request Components: Tools Affects Versions: 1.1.6.GA Reporter: alberto Gori I would like to see seam-gen support for different AS, expecially Tomcat (and maybe Glassfish...?). -- 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

17 years

3
2
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-994) seam-gen and mutiple foreign keys

by Niels Hoogeveen (JIRA)

seam-gen and mutiple foreign keys --------------------------------- Key: JBSEAM-994 URL: http://jira.jboss.com/jira/browse/JBSEAM-994 Project: JBoss Seam Issue Type: Bug Components: Tools Affects Versions: 1.2.0.GA Environment: JBoss-4.0.5 Reporter: Niels Hoogeveen I have generated a project with seam-gen based on generate-entities. All works fine, except for the generation of the home interfaces. In one of my tables I have two foreign keys to the same table. In the home interface two references are created to the appropriate object, but with the same name (which of course doesn't compile). Here is a simplified example: Table 1 Code: CREATE TABLE test ( id int4 NOT NULL DEFAULT nextval('test_id_seq'::regclass), name varchar, id_test2_1 int4, id_test2_2 int4, CONSTRAINT test_pkey PRIMARY KEY (id), CONSTRAINT test_id_test2_1_fkey FOREIGN KEY (id_test2_1) REFERENCES test2 (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION, CONSTRAINT test_id_test2_2_fkey FOREIGN KEY (id_test2_2) REFERENCES test2 (id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTION ) Table2 Code: CREATE TABLE test2 ( id int4 NOT NULL DEFAULT nextval('test2_id_seq'::regclass), name varchar, CONSTRAINT test2_pkey PRIMARY KEY (id) ) First Entity Code: @Entity @Table(name = "test", schema = "public") public class Test implements java.io.Serializable { private int id; private Test2 test2ByIdTest22; private Test2 test2ByIdTest21; private String name; public Test() { } public Test(int id) { this.id = id; } public Test(int id, Test2 test2ByIdTest22, Test2 test2ByIdTest21, String name) { this.id = id; this.test2ByIdTest22 = test2ByIdTest22; this.test2ByIdTest21 = test2ByIdTest21; this.name = name; } @Id @Column(name = "id", unique = true, nullable = false) @NotNull public int getId() { return this.id; } public void setId(int id) { this.id = id; } @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "id_test2_2") public Test2 getTest2ByIdTest22() { return this.test2ByIdTest22; } public void setTest2ByIdTest22(Test2 test2ByIdTest22) { this.test2ByIdTest22 = test2ByIdTest22; } @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "id_test2_1") public Test2 getTest2ByIdTest21() { return this.test2ByIdTest21; } public void setTest2ByIdTest21(Test2 test2ByIdTest21) { this.test2ByIdTest21 = test2ByIdTest21; } @Column(name = "name", length = 0) @Length(max = 0) public String getName() { return this.name; } public void setName(String name) { this.name = name; } } second entity Code: @Entity @Table(name = "test2", schema = "public") public class Test2 implements java.io.Serializable { private int id; private String name; private Set<Test> testsForIdTest21 = new HashSet<Test>(0); private Set<Test> testsForIdTest22 = new HashSet<Test>(0); public Test2() { } public Test2(int id) { this.id = id; } public Test2(int id, String name, Set<Test> testsForIdTest21, Set<Test> testsForIdTest22) { this.id = id; this.name = name; this.testsForIdTest21 = testsForIdTest21; this.testsForIdTest22 = testsForIdTest22; } @Id @Column(name = "id", unique = true, nullable = false) @NotNull public int getId() { return this.id; } public void setId(int id) { this.id = id; } @Column(name = "name", length = 0) @Length(max = 0) public String getName() { return this.name; } public void setName(String name) { this.name = name; } @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "test2ByIdTest21") public Set<Test> getTestsForIdTest21() { return this.testsForIdTest21; } public void setTestsForIdTest21(Set<Test> testsForIdTest21) { this.testsForIdTest21 = testsForIdTest21; } @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.LAZY, mappedBy = "test2ByIdTest22") public Set<Test> getTestsForIdTest22() { return this.testsForIdTest22; } public void setTestsForIdTest22(Set<Test> testsForIdTest22) { this.testsForIdTest22 = testsForIdTest22; } } Home interface of first entity. Here we have two Test2Home references, both with the name test2Home. Code: @Name("testHome") public class TestHome extends EntityHome<Test> { @In(create = true) Test2Home test2Home; @In(create = true) Test2Home test2Home; public void setTestId(Integer id) { setId(id); } public Integer getTestId() { return (Integer) getId(); } @Override protected Test createInstance() { Test test = new Test(); return test; } public void wire() { Test2 test2ByIdTest22 = test2Home.getDefinedInstance(); if (test2ByIdTest22 != null) { getInstance().setTest2ByIdTest22(test2ByIdTest22); } Test2 test2ByIdTest21 = test2Home.getDefinedInstance(); if (test2ByIdTest21 != null) { getInstance().setTest2ByIdTest21(test2ByIdTest21); } } public boolean isWired() { return true; } public Test getDefinedInstance() { return isIdDefined() ? getInstance() : null; } } BTW. I used the latest seam version from CVS. -- 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

17 years

10
23
0 / 0

[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-1840) Serious nasty problem with ManagedEntityIdentityInterceptor

by Przemyslaw Jaskierski (JIRA)

Serious nasty problem with ManagedEntityIdentityInterceptor ----------------------------------------------------------- Key: JBSEAM-1840 URL: http://jira.jboss.com/jira/browse/JBSEAM-1840 Project: JBoss Seam Issue Type: Bug Components: Core Environment: pure Tomcat 6.0.13 + Hibernate 3.2.4, Seam-managed non-JTA Hibernate transactions, Seam.2.CVS.20.08.2007 Reporter: Przemyslaw Jaskierski Priority: Critical First of all, please do not underestimate problem in this report. It's a tough one, and definitely not a malfunction on my side. This disclaimer is because as a developer I know what a PR without a testcase is - but please bear with me. I've already spent ssooo much time on this issue that my co-workers will shoot my head off :(:(:(. I've tried to modify Seam examples to demonstrate it to you, but gave up due to problems with hibernate2 (not working Tomcat deployment), Booking (cannot log into it on AS) (BTW I understand that it's a BETA, just reporting)... It's 100% reproducible in my application, but I'm not allowed to share it :(:(:(. I have a wizard-like, long-running conversation driven by a jpdl pageflow (flushMode=MANUAL). There is a couple of Conversation-scoped Seam components that backs this wizard. I have some @Entity and List<@Entity> fields (pure Hibernate Annotations, no JPA etc.) in some of them. Problem is that ManagedEntityIdentityInterceptor overwrites valid values of these fields with NULL or ArrayList<NULL> values from time to time. It's quite discrete, and I manged to discover this behavior after a huge amount of time only because I've found this: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112335 and http://jira.jboss.com/jira/browse/JBSEAM-1814. Note that in my situation there is no DataModel-related stuff involved, access to these fields is driven by simple get/setters. There is another strange thing. On Seam debug page I enter my conversation scope and list all pojos. There is, for example, "pojoName" and "pojoName.listName" components listed (I have only pojoName component registered with @Name, but looks like it's some kind of Seam optimization). As long as I enter/exit inspection of pojoName component, it's listName preserves its content as expected. But after clicking "pojoName.listName": 1st time it shows it's content, but after entering pojoName and pojoName.listName after this, this list is replaced by [null, null, null etc.] values. No, I don't do anything unusual there, it's a simple plain getter. I think it's not only limited to view-accessed EL-resolved entities, because even my @In components get nullyfied fields (even during the same unit of work, when doing some complex cross-component processing in a single http request). Non-@Entity fields are left untouched. After looking into ManagedEntityIdentityInterceptor code, I changed my fields to TRANSIENT (to be skipped by ignore(Field) method) and this made everything working OK, like expected. Of course having transient fields is not necessary what you want from you pojos, besides I think that it's a serious problem in ManagedEntityIdentityInterceptor that will ruin some nights of other developer if left unresolved. I will gladly test eventual fixes against my codebase. -- 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

17 years, 1 month

5
7
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 August 2007