September 2013 - forge-issues - Jboss List Archives

[JBoss JIRA] (FORGE-1208) Furnace test harness should deploy @AddonDependencies only once per @Deployment

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1208?page=com.atlassian.jira.plugin... ] Lincoln Baxter III closed FORGE-1208. ------------------------------------- Fix Version/s: 2.0.0.Alpha13 Resolution: Done > Furnace test harness should deploy @AddonDependencies only once per @Deployment > ------------------------------------------------------------------------------- > > Key: FORGE-1208 > URL: https://issues.jboss.org/browse/FORGE-1208 > Project: Forge > Issue Type: Feature Request > Components: Furnace (Container), Test Harness > Affects Versions: 2.0.0.Alpha12 > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha13 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1208) Furnace test harness should deploy @AddonDependencies only once per @Deployment

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1208?page=com.atlassian.jira.plugin... ] Lincoln Baxter III reassigned FORGE-1208: ----------------------------------------- Assignee: Lincoln Baxter III > Furnace test harness should deploy @AddonDependencies only once per @Deployment > ------------------------------------------------------------------------------- > > Key: FORGE-1208 > URL: https://issues.jboss.org/browse/FORGE-1208 > Project: Forge > Issue Type: Feature Request > Components: Furnace (Container), Test Harness > Affects Versions: 2.0.0.Alpha12 > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1212) REST endpoint findById doesn't handle NoResultException

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1212?page=com.atlassian.jira.plugin... ] George Gastaldi closed FORGE-1212. ---------------------------------- Assignee: George Gastaldi Fix Version/s: 1.4.2.Final Resolution: Done Fixed > REST endpoint findById doesn't handle NoResultException > ------------------------------------------------------- > > Key: FORGE-1212 > URL: https://issues.jboss.org/browse/FORGE-1212 > Project: Forge > Issue Type: Bug > Affects Versions: 1.4.1.Final > Reporter: Antonio Goncalves > Assignee: George Gastaldi > Fix For: 1.4.2.Final > > > When a REST endpoint is generated the {{findById}} method looks like this : > {code} > @GET > @Path("/{id:[0-9][0-9]*}") > @Produces("application/xml") > public Response findById(@PathParam("id") Long id) { > TypedQuery<Book> findByIdQuery = em.createQuery("SELECT DISTINCT b FROM Book b WHERE b.id = :entityId ORDER BY b.id", Book.class); > findByIdQuery.setParameter("entityId", id); > Book entity = findByIdQuery.getSingleResult(); > if (entity == null) { > return Response.status(Status.NOT_FOUND).build(); > } > return Response.ok(entity).build(); > } > {code} > The problem is that when the entity doesn't exist, the {{findByIdQuery.getSingleResult()}} doesn't return {{null}} but throws a {{NoResultException}}. So the {{if (entity == null)}} is never reached. > The generated code should catch the {{NoResultException}} and return the {{return Response.status(Status.NOT_FOUND)}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1212) REST endpoint findById doesn't handle NoResultException

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-1212: ---------------------------------------- Summary: REST endpoint findById doesn't handle NoResultException Key: FORGE-1212 URL: https://issues.jboss.org/browse/FORGE-1212 Project: Forge Issue Type: Bug Affects Versions: 1.4.1.Final Reporter: Antonio Goncalves When a REST endpoint is generated the {{findById}} method looks like this : {code} @GET @Path("/{id:[0-9][0-9]*}") @Produces("application/xml") public Response findById(@PathParam("id") Long id) { TypedQuery<Book> findByIdQuery = em.createQuery("SELECT DISTINCT b FROM Book b WHERE b.id = :entityId ORDER BY b.id", Book.class); findByIdQuery.setParameter("entityId", id); Book entity = findByIdQuery.getSingleResult(); if (entity == null) { return Response.status(Status.NOT_FOUND).build(); } return Response.ok(entity).build(); } {code} The problem is that when the entity doesn't exist, the {{findByIdQuery.getSingleResult()}} doesn't return {{null}} but throws a {{NoResultException}}. So the {{if (entity == null)}} is never reached. The generated code should catch the {{NoResultException}} and return the {{return Response.status(Status.NOT_FOUND)}} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1211) Adding a Reset button to the JSF search pages

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1211?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-1211: ----------------------------------- Fix Version/s: 2.x Future > Adding a Reset button to the JSF search pages > --------------------------------------------- > > Key: FORGE-1211 > URL: https://issues.jboss.org/browse/FORGE-1211 > Project: Forge > Issue Type: Enhancement > Affects Versions: 1.4.1.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > At the moment, when you generate JSF pages, the search.xhtml have a Search and a Create New button : > {code} > <h:panelGroup styleClass="buttons"> > <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> > <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> > </h:panelGroup> > {code} > With long search forms it would be handy to have a Reset button that would clear the form. A simple {{<h:commandButton type="reset" />}} will not work, so you would have to have an extra method that clears the {{example}}, something like : > {code} > <h:panelGroup styleClass="buttons"> > <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> > <h:commandLink value="Reset" action="#{bookBean.reset}" styleClass="btn btn-primary"/> > <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> > </h:panelGroup> > {code} > The {{bookBean.reset}} method could just do a {{new}} on {{example}} (or initialise with default values for example) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1211) Adding a Reset button to the JSF search pages

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/FORGE-1211?page=com.atlassian.jira.plugin... ] George Gastaldi updated FORGE-1211: ----------------------------------- Component/s: Scaffold > Adding a Reset button to the JSF search pages > --------------------------------------------- > > Key: FORGE-1211 > URL: https://issues.jboss.org/browse/FORGE-1211 > Project: Forge > Issue Type: Enhancement > Components: Scaffold > Affects Versions: 1.4.1.Final > Reporter: Antonio Goncalves > Fix For: 2.x Future > > > At the moment, when you generate JSF pages, the search.xhtml have a Search and a Create New button : > {code} > <h:panelGroup styleClass="buttons"> > <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> > <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> > </h:panelGroup> > {code} > With long search forms it would be handy to have a Reset button that would clear the form. A simple {{<h:commandButton type="reset" />}} will not work, so you would have to have an extra method that clears the {{example}}, something like : > {code} > <h:panelGroup styleClass="buttons"> > <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> > <h:commandLink value="Reset" action="#{bookBean.reset}" styleClass="btn btn-primary"/> > <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> > </h:panelGroup> > {code} > The {{bookBean.reset}} method could just do a {{new}} on {{example}} (or initialise with default values for example) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1211) Adding a Reset button to the JSF search pages

by Antonio Goncalves (JIRA)

Antonio Goncalves created FORGE-1211: ---------------------------------------- Summary: Adding a Reset button to the JSF search pages Key: FORGE-1211 URL: https://issues.jboss.org/browse/FORGE-1211 Project: Forge Issue Type: Enhancement Affects Versions: 1.4.1.Final Reporter: Antonio Goncalves At the moment, when you generate JSF pages, the search.xhtml have a Search and a Create New button : {code} <h:panelGroup styleClass="buttons"> <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> </h:panelGroup> {code} With long search forms it would be handy to have a Reset button that would clear the form. A simple {{<h:commandButton type="reset" />}} will not work, so you would have to have an extra method that clears the {{example}}, something like : {code} <h:panelGroup styleClass="buttons"> <h:commandLink value="Search" action="#{bookBean.paginate}" styleClass="btn btn-primary"/> <h:commandLink value="Reset" action="#{bookBean.reset}" styleClass="btn btn-primary"/> <h:commandLink value="Create New" action="#{bookBean.create}" styleClass="btn btn-primary"/> </h:panelGroup> {code} The {{bookBean.reset}} method could just do a {{new}} on {{example}} (or initialise with default values for example) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1210) PostStartup and PreShutdown should be fired to all addons, and include the addon being started/stopped.

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created FORGE-1210: ----------------------------------------- Summary: PostStartup and PreShutdown should be fired to all addons, and include the addon being started/stopped. Key: FORGE-1210 URL: https://issues.jboss.org/browse/FORGE-1210 Project: Forge Issue Type: Feature Request Components: Furnace (Container) Affects Versions: 2.0.0.Alpha12 Reporter: Lincoln Baxter III -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1206) Imported<?>.get() has a different behavior compared to iterator()

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1206?page=com.atlassian.jira.plugin... ] Lincoln Baxter III closed FORGE-1206. ------------------------------------- Assignee: Lincoln Baxter III Fix Version/s: 2.0.0.Alpha13 (was: 2.x Future) Resolution: Done > Imported<?>.get() has a different behavior compared to iterator() > ----------------------------------------------------------------- > > Key: FORGE-1206 > URL: https://issues.jboss.org/browse/FORGE-1206 > Project: Forge > Issue Type: Bug > Components: Furnace (Container) > Affects Versions: 2.0.0.Alpha12 > Reporter: George Gastaldi > Assignee: Lincoln Baxter III > Fix For: 2.0.0.Alpha13 > > > Given: > {code:java} > public interface MyInterface {} > {code} > and > {code:java} > public class Foo implements MyInterface {} > {code} > Trying to retrieve it from the Imported object from AddonRegistry: > {code:java} > Imported<MyInterface> imported = addonRegistry.getServices(MyInterface.class); > {code} > The following statements are observed: > # imported.get() returns instance of Foo > # imported.iterator().hasNext() returns false. > Since no {{@Exported}} is placed in {{MyInterface}}, I believe the first statement is a bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (FORGE-1206) Imported<?>.get() has a different behavior compared to iterator()

by Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/FORGE-1206?page=com.atlassian.jira.plugin... ] Lincoln Baxter III commented on FORGE-1206: ------------------------------------------- We have decided to remove the @Exported annotation and perform service lookup implicitly based on calculated classloader boundaries. This effectively means that the AddonRegistry getImported() queries will provide whatever the aggregate ServiceRegistry instances are willing to produce. Essentially, what is a service and what is not is now solely up to the implementing ServiceRegistry. This resolves consistency issues with attempting to @Inject a Type vs getImported() vs Imported.get(). They now all behave the same, and now all resolve anything in the ServiceRegistries. > Imported<?>.get() has a different behavior compared to iterator() > ----------------------------------------------------------------- > > Key: FORGE-1206 > URL: https://issues.jboss.org/browse/FORGE-1206 > Project: Forge > Issue Type: Bug > Components: Furnace (Container) > Affects Versions: 2.0.0.Alpha12 > Reporter: George Gastaldi > Fix For: 2.x Future > > > Given: > {code:java} > public interface MyInterface {} > {code} > and > {code:java} > public class Foo implements MyInterface {} > {code} > Trying to retrieve it from the Imported object from AddonRegistry: > {code:java} > Imported<MyInterface> imported = addonRegistry.getServices(MyInterface.class); > {code} > The following statements are observed: > # imported.get() returns instance of Foo > # imported.iterator().hasNext() returns false. > Since no {{@Exported}} is placed in {{MyInterface}}, I believe the first statement is a bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

forge-issues September 2013