From issues at jboss.org Wed Sep 2 08:16:07 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:07 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (SEAMREST-6) ExceptionMapper classes should be moved to api to support only relying on api jar at compile time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SEAMREST-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned SEAMREST-6: -------------------------------------- Assignee: (was: Jozef Hartinger) > ExceptionMapper classes should be moved to api to support only relying on api jar at compile time > ------------------------------------------------------------------------------------------------- > > Key: SEAMREST-6 > URL: https://issues.jboss.org/browse/SEAMREST-6 > Project: Seam REST > Issue Type: Bug > Components: Client > Affects Versions: 3.0.0.Alpha1 > Reporter: Jason Porter > Fix For: Future > > > Currently SeamExceptionMapper and ValidationExceptionMapper are in the impl class. Unless we provide our own Application subclass (which should also be in the api jar) users can subclass and add to our classes they must include the impl jar as a runtime dependency. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:07 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:07 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-3938) Seam's Resteasy implementation does not support tagged interfaces, nor classes that implement them. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned JBSEAM-3938: --------------------------------------- Assignee: (was: Jozef Hartinger) > Seam's Resteasy implementation does not support tagged interfaces, nor classes that implement them. > --------------------------------------------------------------------------------------------------- > > Key: JBSEAM-3938 > URL: https://issues.jboss.org/browse/JBSEAM-3938 > Project: Seam 2 > Issue Type: Bug > Components: WS > Affects Versions: 2.1.1.GA > Environment: SEAM 2.1.1.GA with seam-resteasy patch described in https://jira.jboss.org/jira/browse/JBSEAM-3449, and RestEasy 1.0.1.GA. > Reporter: John Sublette > Priority: Minor > Labels: RestEasy > > Seam's Resteasy implementation does not support tagged interfaces, nor classes that implement them as described in RestEasy's documentation (section 28.2 - Sharing an interface...). An interface with tagged @Path throws an exception when it is registered - because an interface doesn't have a constructor. > See org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap Line 112 through 138 for how RestEasy handles this by default - (using Scannotation) -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:08 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:08 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (SOLDER-258) Test Seam Servlet in an EAR with multiple web apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SOLDER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned SOLDER-258: -------------------------------------- Assignee: (was: Jozef Hartinger) > Test Seam Servlet in an EAR with multiple web apps > -------------------------------------------------- > > Key: SOLDER-258 > URL: https://issues.jboss.org/browse/SOLDER-258 > Project: Solder > Issue Type: Feature Request > Components: Compliance, Servlet, Test Suite > Reporter: Dan Allen > Fix For: Future > > > We want to verify that we haven't broken any assumptions, such as whether the correct ServletContext is injected. Should be relatively easy to solve with Arquillian. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:08 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:08 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4809) seam-resteasy integration conflicts with resteasy deployer on JBoss AS 6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned JBSEAM-4809: --------------------------------------- Assignee: (was: Jozef Hartinger) > seam-resteasy integration conflicts with resteasy deployer on JBoss AS 6 > ------------------------------------------------------------------------ > > Key: JBSEAM-4809 > URL: https://issues.jboss.org/browse/JBSEAM-4809 > Project: Seam 2 > Issue Type: Bug > Components: WS > Affects Versions: 2.2.2.Final > Reporter: Jozef Hartinger > Fix For: The future > > > As a result of auto-scanning performed by the resteasy-deployer, resources not intended to be registered are registered within RESTEasy which causes redirect loops breaking the entire application. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:08 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:08 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (SEAMREST-26) Less verbose configuration of exception mapping rules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SEAMREST-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned SEAMREST-26: --------------------------------------- Assignee: (was: Jozef Hartinger) > Less verbose configuration of exception mapping rules > ----------------------------------------------------- > > Key: SEAMREST-26 > URL: https://issues.jboss.org/browse/SEAMREST-26 > Project: Seam REST > Issue Type: Feature Request > Components: Configuration, Examples, Exception handling > Affects Versions: 3.0.0.Beta1 > Reporter: Jozef Hartinger > Priority: Minor > > Currently we have: > > > > > Requested resource (#{uriInfo.path}) does not exist. > > > > > > > > > > > we could make it to > > > > > Requested resource (#{uriInfo.path}) does not exist. > > > > > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:09 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:09 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-3988) Support for mapping RESTful XHTML resource representations with Facelets templates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-3988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned JBSEAM-3988: --------------------------------------- Assignee: (was: Jozef Hartinger) > Support for mapping RESTful XHTML resource representations with Facelets templates > ---------------------------------------------------------------------------------- > > Key: JBSEAM-3988 > URL: https://issues.jboss.org/browse/JBSEAM-3988 > Project: Seam 2 > Issue Type: Feature Request > Components: WS > Reporter: Christian Bauer > Fix For: The future > > > What I wrote a while ago about this feature: > I'm thinking about a special provider that can marshal an object graph into an XHTML (not just XML) response body and back from an XHTML request body to an object graph. This is about the "connectedness" of resources, see the O'Reilly REST book. As a developer I should write a Facelets XHTML template that defines the transformation. Imagine that you write it the same way you write a JSF template today, with bidirectional binding using EL expressions, from object getter/setter pair to XML attribute or element value. We can even have built-in Facelets "widgets" that render certain microformats. Seam has some machinery for this already but we might need an extra interceptor on resource methods to trigger the transformation. Or we use Seams pages.xml navigation rules ("when this resource method finishes, render this template"). > Later I did some prototype experiments - note that this only considers uni-directional mapping for GET, handling POST/PUT resource representation is more difficult: > package org.jboss.seam.resteasy; > import java.lang.annotation.*; > /** > * @author Christian Bauer > */ > @Target({ElementType.METHOD}) > @Retention(RetentionPolicy.RUNTIME) > @Documented > @Inherited > public @interface FaceletsXhtmlResponse { > String template(); > } > package org.jboss.seam.resteasy; > import org.jboss.seam.core.Interpolator; > import org.jboss.seam.faces.Renderer; > import org.jboss.seam.log.Log; > import org.jboss.seam.log.Logging; > import javax.ws.rs.ProduceMime; > import javax.ws.rs.core.MediaType; > import javax.ws.rs.core.MultivaluedMap; > import javax.ws.rs.ext.MessageBodyWriter; > import javax.ws.rs.ext.Provider; > import java.io.IOException; > import java.io.OutputStream; > import java.lang.annotation.Annotation; > import java.lang.reflect.Type; > /** > * @author Christian Bauer > */ > @Provider > @ProduceMime("application/xhtml+xml") > public class FaceletsXhtmlProvider implements MessageBodyWriter { > Log log = Logging.getLog(FaceletsXhtmlProvider.class); > public boolean isWriteable(Class type, Type genericType, Annotation[] annotations) { > for (Annotation annotation : annotations) { > if (annotation.annotationType().equals(FaceletsXhtmlResponse.class)) { > return true; > } > } > return false; > } > public long getSize(Object o) { > return -1; > } > public void writeTo(Object o, Class type, Type genericType, Annotation[] annotations, > MediaType mediaType, MultivaluedMap httpHeaders, OutputStream entityStream) > throws IOException { > log.debug("writing XHTML response for entity type: " + type.getName()); > FaceletsXhtmlResponse respAnnotation = null; > for (Annotation annotation : annotations) { > if (annotation.annotationType().equals(FaceletsXhtmlResponse.class)) > respAnnotation = (FaceletsXhtmlResponse) annotation; > } > if (respAnnotation == null) throw new IllegalStateException("@FaceletsXhtmlResponse annotation disappeared"); > String template = getTemplatePath(respAnnotation); > log.debug("rendering XHTML template: " + template); > String output = Renderer.instance().render(template); > entityStream.write(output.getBytes()); > } > protected String getTemplatePath(FaceletsXhtmlResponse annotation) { > return isTemplatePathInterpolated() > ? Interpolator.instance().interpolate(annotation.template()) > : annotation.template(); > } > protected boolean isTemplatePathInterpolated() { > return true; > } > } > @Name("customerResource") > @Path("/customer") > public class CustomerResource { > @GET > @ProduceMime("application/xhtml+xml") > @FaceletsXhtmlResponse( > template = "#{somePath}/customerTemplate.xhtml" > ) > @Out(value = "customers", scope = ScopeType.EVENT) > public List getCustomers() { > return mockCustomers(); > } > } > > xmlns:t="http://java.sun.com/jsf/facelets" > xmlns:h="http://java.sun.com/jsf/html" > xmlns:f="http://java.sun.com/jsf/core"> > > Customers > > >
    > >
  • > >
    • >     >
> > -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:09 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:09 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4779) Session not invalidated after failed authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned JBSEAM-4779: --------------------------------------- Assignee: (was: Jozef Hartinger) > Session not invalidated after failed authentication > --------------------------------------------------- > > Key: JBSEAM-4779 > URL: https://issues.jboss.org/browse/JBSEAM-4779 > Project: Seam 2 > Issue Type: Bug > Components: WS > Affects Versions: 2.2.1.Final > Reporter: Jozef Hartinger > > When the "anemic session" options is enabled, the session is not be invalidated under following circumstances: > - authentication (such as HTTP Basic authentication provided by seam security) is unsuccessful - an exception is thrown outside of seam-resteasy - we cannot invalidate the session -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:09 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:09 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (SEAMREST-49) String response not rendered by @ResponseTemplate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SEAMREST-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned SEAMREST-49: --------------------------------------- Assignee: (was: Jozef Hartinger) > String response not rendered by @ResponseTemplate > ------------------------------------------------- > > Key: SEAMREST-49 > URL: https://issues.jboss.org/browse/SEAMREST-49 > Project: Seam REST > Issue Type: Bug > Components: Templating > Affects Versions: 3.0.0.Final, 3.1.0.Beta3, 3.1.0.Final > Reporter: Jozef Hartinger > > {code:JAVA} > @Path("string") > @GET > @Produces("text/plain") > @ResponseTemplate("/string.ftl") > public String string() > { > return "Jozef"; > } > {code} > won't be rendered. "Jozef" is returned instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Wed Sep 2 08:16:09 2015 From: issues at jboss.org (Jozef Hartinger (JIRA)) Date: Wed, 2 Sep 2015 08:16:09 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (SEAMREST-19) ValidationInterceptor not triggered on GF In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SEAMREST-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jozef Hartinger reassigned SEAMREST-19: --------------------------------------- Assignee: (was: Jozef Hartinger) > ValidationInterceptor not triggered on GF > ----------------------------------------- > > Key: SEAMREST-19 > URL: https://issues.jboss.org/browse/SEAMREST-19 > Project: Seam REST > Issue Type: Bug > Components: Bean Validation > Affects Versions: 3.0.0.Alpha3 > Environment: GF 3.1b37 > JDK6U23 > Reporter: Jozef Hartinger > Fix For: Future > > > Seam Tasks example - the ValidationInterceptor is not triggered. Probably a bug in GF. Need to write a test for that. -- This message was sent by Atlassian JIRA (v6.3.15#6346) From issues at jboss.org Sun Sep 27 09:10:00 2015 From: issues at jboss.org (Sreenath Reddy (JIRA)) Date: Sun, 27 Sep 2015 09:10:00 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4480) Sometimes JSF lifecycle not completing which leaves conversation in locked state causing concurrent conversation error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112734#comment-13112734 ] Sreenath Reddy commented on JBSEAM-4480: ---------------------------------------- Is this issue still exist in Seam 2.3.1. I am facing similar issue. > Sometimes JSF lifecycle not completing which leaves conversation in locked state causing concurrent conversation error > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBSEAM-4480 > URL: https://issues.jboss.org/browse/JBSEAM-4480 > Project: Seam 2 > Issue Type: Bug > Components: Core, JSF Integration > Affects Versions: 2.2.0.GA > Environment: Linux > Reporter: Ross Mills > Labels: concurrent, conversation > Attachments: concurrent-conv-err.log, concurrent-conv-error-2.log > > > I have an Seam app that has a left menu on every page. When the user selects an item from the menu, it ends the current conversation and starts a new one. However, once in a while, I get a concurrent conversation exception. I have an automated test that does the following: > (1) Logs the user in. > (2) 10 seconds later, the user selects an item from the left hand menu (which ends the current conversation and begins a new one). This causes a seach form to appear. > (3) 10 seconds later, the user fills in the form and submits. The search results are displayed. > (4) 10 seconds later, the user navigates through the search results and drills down. > (5) 10 seconds later, the user returns to step (2) by selecting the same item from the left hand menu and repeats the above steps. > The user is able to cycle through these steps anywhere from a few seconds to several minutes until the concurrent conversation error occurs. When the error occurs, it is when the user attempts to submit the search form. > The logs indicate that when the search form is displayed, the JSF lifecycle is not progressing beyond the RESTORE_VIEW phase. This causes the conversation to remain locked. Then when the user attempts to submit the form, the new thread finds the conversation locked and generated the concurrent conversation exception. > My company policy may not allow me to provide you with code that you can use to duplicate the problem. But snippets of the logs can be found in the JBoss forum reference I am including. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 28 14:22:00 2015 From: issues at jboss.org (Tiago Peruzzo (JIRA)) Date: Mon, 28 Sep 2015 14:22:00 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4854) countQuery not correcly generated when group by is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112983#comment-13112983 ] Tiago Peruzzo commented on JBSEAM-4854: --------------------------------------- [~mnovotny] this change has affected my queries that have group by. Now the count returns without the distinct and appears a number of different records than return the select with group by. Sample: select min (e.birthYear), count (*) from Person p group by p.birthYear The correct count should be: select count (distinct p.birthYear) from Person p https://github.com/seam2/jboss-seam/commit/a73ff489e9f62fcacf6c9593889018599ebd925b > countQuery not correcly generated when group by is used > ------------------------------------------------------- > > Key: JBSEAM-4854 > URL: https://issues.jboss.org/browse/JBSEAM-4854 > Project: Seam 2 > Issue Type: Bug > Components: Framework > Affects Versions: 2.3.0.ALPHA > Reporter: Sergio Angelo > Assignee: Marek Novotny > Fix For: 2.3.0.BETA1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When an EntityQuery contains a group-by, then the select statement of the count-query is not correctly generated. > Example query for reproducing the problem: > select min(e.receivedDate), count(*) > from Entity e > where ... > groupby date_trunc('year', e.receivedDate), date_trunc('quarter', e.receivedDate) > The count-query becomes as follows (which generates an exception when run): > select distinct date_trunc('year', l.receivedDate), date_trunc('quarter', e.receivedDate) > from etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 04:31:00 2015 From: issues at jboss.org (Marek Novotny (JIRA)) Date: Tue, 29 Sep 2015 04:31:00 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4480) Sometimes JSF lifecycle not completing which leaves conversation in locked state causing concurrent conversation error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113100#comment-13113100 ] Marek Novotny commented on JBSEAM-4480: --------------------------------------- very probably yes as this issue is not closed. > Sometimes JSF lifecycle not completing which leaves conversation in locked state causing concurrent conversation error > ---------------------------------------------------------------------------------------------------------------------- > > Key: JBSEAM-4480 > URL: https://issues.jboss.org/browse/JBSEAM-4480 > Project: Seam 2 > Issue Type: Bug > Components: Core, JSF Integration > Affects Versions: 2.2.0.GA > Environment: Linux > Reporter: Ross Mills > Labels: concurrent, conversation > Attachments: concurrent-conv-err.log, concurrent-conv-error-2.log > > > I have an Seam app that has a left menu on every page. When the user selects an item from the menu, it ends the current conversation and starts a new one. However, once in a while, I get a concurrent conversation exception. I have an automated test that does the following: > (1) Logs the user in. > (2) 10 seconds later, the user selects an item from the left hand menu (which ends the current conversation and begins a new one). This causes a seach form to appear. > (3) 10 seconds later, the user fills in the form and submits. The search results are displayed. > (4) 10 seconds later, the user navigates through the search results and drills down. > (5) 10 seconds later, the user returns to step (2) by selecting the same item from the left hand menu and repeats the above steps. > The user is able to cycle through these steps anywhere from a few seconds to several minutes until the concurrent conversation error occurs. When the error occurs, it is when the user attempts to submit the search form. > The logs indicate that when the search form is displayed, the JSF lifecycle is not progressing beyond the RESTORE_VIEW phase. This causes the conversation to remain locked. Then when the user attempts to submit the form, the new thread finds the conversation locked and generated the concurrent conversation exception. > My company policy may not allow me to provide you with code that you can use to duplicate the problem. But snippets of the logs can be found in the JBoss forum reference I am including. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 04:37:00 2015 From: issues at jboss.org (Marek Novotny (JIRA)) Date: Tue, 29 Sep 2015 04:37:00 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4854) countQuery not correcly generated when group by is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113106#comment-13113106 ] Marek Novotny commented on JBSEAM-4854: --------------------------------------- [~peruzzo] why don't you set useWildcardAsCountQuerySubject to false in your query? > countQuery not correcly generated when group by is used > ------------------------------------------------------- > > Key: JBSEAM-4854 > URL: https://issues.jboss.org/browse/JBSEAM-4854 > Project: Seam 2 > Issue Type: Bug > Components: Framework > Affects Versions: 2.3.0.ALPHA > Reporter: Sergio Angelo > Assignee: Marek Novotny > Fix For: 2.3.0.BETA1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When an EntityQuery contains a group-by, then the select statement of the count-query is not correctly generated. > Example query for reproducing the problem: > select min(e.receivedDate), count(*) > from Entity e > where ... > groupby date_trunc('year', e.receivedDate), date_trunc('quarter', e.receivedDate) > The count-query becomes as follows (which generates an exception when run): > select distinct date_trunc('year', l.receivedDate), date_trunc('quarter', e.receivedDate) > from etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 29 07:21:00 2015 From: issues at jboss.org (Tiago Peruzzo (JIRA)) Date: Tue, 29 Sep 2015 07:21:00 -0400 (EDT) Subject: [seam-issues] [JBoss JIRA] (JBSEAM-4854) countQuery not correcly generated when group by is used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBSEAM-4854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113211#comment-13113211 ] Tiago Peruzzo commented on JBSEAM-4854: --------------------------------------- [~manaRH] I'm upgrading multiple projects (more than 40 projects in all) using the seam 2.2 to 2.3, have many classes with group by using EntityQuery that worked in version 2.2. It would be too costly and risky to find all places where I have a sql with group by and change to set useWildcardAsCountQuerySubject to false. Another issue is that the sql referenced in the bug is not wrong. The method makes the count properly, what do happens is that some providers do not support multiple distincts in the count or have a different semantics. Mysql: select count(distinct year(e.receivedDate), quarter(e.receivedDate)) from Entity e; Oracle: select count (distinct trunc(e.receivedDate, 'year') || trunc(e.receivedDate, 'Q')) from Entity e; > countQuery not correcly generated when group by is used > ------------------------------------------------------- > > Key: JBSEAM-4854 > URL: https://issues.jboss.org/browse/JBSEAM-4854 > Project: Seam 2 > Issue Type: Bug > Components: Framework > Affects Versions: 2.3.0.ALPHA > Reporter: Sergio Angelo > Assignee: Marek Novotny > Fix For: 2.3.0.BETA1 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > When an EntityQuery contains a group-by, then the select statement of the count-query is not correctly generated. > Example query for reproducing the problem: > select min(e.receivedDate), count(*) > from Entity e > where ... > groupby date_trunc('year', e.receivedDate), date_trunc('quarter', e.receivedDate) > The count-query becomes as follows (which generates an exception when run): > select distinct date_trunc('year', l.receivedDate), date_trunc('quarter', e.receivedDate) > from etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)