I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like that the implemented interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now interface bean. On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? -- **************************************** http://www.lucamasini.net http://twitter.com/lmasini http://www.linkedin.com/pub/luca-masini/7/10/2b9 **************************************** _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Yes, you could try that. The history to this decision was: 1. The Converter needs to use an EntityManager to load the entity 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would be other approaches, such as looking up the EntityManager via JNDI or something. Regards, Richard. On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > Did you think of separating Converter and backing bean implementation? > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > Thomas > > Am 03.08.2012 11:13, schrieb Luca Masini: >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. >> >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like that the implemented >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. >> >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now interface bean. >> >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. >> >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? >> >> -- >> **************************************** >> http://www.lucamasini.net >> http://twitter.com/lmasini >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 >> **************************************** >> >> >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org <javascript:;> >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <javascript:;> https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, Thanks for your time and help debugging this. I think we need to proceed with caution. We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these hacks are going to get re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as possible. In particular, we must keep the 'semantic complexity' low. The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of 'semantic complexity' for new users to understand? It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current code. Here's one that's not quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: @FacesConverter( forClass = xxx.class ) public static class xxxConverter implements Converter { @Override public Object getAsObject( FacesContext context, UIComponent component, String value ) { // EntityManager injection not reliable on all platforms xxx entity = new xxx(); entity.setId( Long.valueOf( value ) ); return entity; } @Override public String getAsString( FacesContext context, UIComponent component, Object value ) { ... } } Here's a complete example: https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... Regards, Richard. On 3/08/2012 9:17 PM, Luca Masini wrote: > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the jsf client. > > This way it works. > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > Yes, you could try that. The history to this decision was: > > 1. The Converter needs to use an EntityManager to load the entity > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would be other approaches, such as > looking up the EntityManager via JNDI or something. > > Regards, > > Richard. > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > Did you think of separating Converter and backing bean implementation? > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > Thomas > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > >> > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like that the implemented > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > >> > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now interface bean. > >> > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. > >> > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? > >> > >> -- > >> **************************************** > >> http://www.lucamasini.net > >> http://twitter.com/lmasini > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > >> **************************************** > >> > >> > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev(a)lists.jboss.org <javascript:;> > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <javascript:;> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <javascript:;> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, > factory that hide that complexity One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of user's final project. They will see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but then we are essentially creating a Forge-specific, undocumented, unsupported framework on top of EE. Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com? Then I can try and reproduce the errors you're seeing. Regards, Richard. On 6/08/2012 6:56 PM, Luca Masini wrote: > Thank you for your feedback Richard. > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and on the log I can find this line: > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) have been enqueued, but may > not have been displayed. > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid), > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to inject an extended persistence > context inside a client object. > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > What do you think ? > > > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > Luca, > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these hacks are going to get > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as possible. In > particular, we > must keep the 'semantic complexity' low. > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of 'semantic > complexity' for > new users to understand? > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current code. Here's one that's not > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > @FacesConverter( forClass = xxx.class ) > public static class xxxConverter > implements Converter { > > @Override > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > // EntityManager injection not reliable on all platforms > > xxx entity = new xxx(); > entity.setId( Long.valueOf( value ) ); > return entity; > } > > @Override > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > ... > } > } > > Here's a complete example: > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > Regards, > > Richard. > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the jsf client. > > > > This way it works. > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > Yes, you could try that. The history to this decision was: > > > > 1. The Converter needs to use an EntityManager to load the entity > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would be other > approaches, such as > > looking up the EntityManager via JNDI or something. > > > > Regards, > > > > Richard. > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > Did you think of separating Converter and backing bean implementation? > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > Thomas > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > >> > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like that the > implemented > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > > >> > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now interface bean. > > >> > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. > > >> > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? > > >> > > >> -- > > >> **************************************** > > >> http://www.lucamasini.net > > >> http://twitter.com/lmasini > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > >> **************************************** > > >> > > >> > > >> _______________________________________________ > > >> forge-dev mailing list > > >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <javascript:;> > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <javascript:;> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <javascript:;> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, Thank you for your time and patience in working through this with me. I appreciate your enthusiasm and professionalism. I took a look at your sample Test Case. My apologies. The example I linked to was using a runtime version of Metawidget, not a static version. I had underestimated the difference that would make. It seems you need to use an explicit id (eg. @FacesConverter("groupConverter") and <h:selectOneMenu ... converter="groupConverter">). Otherwise JSF cannot automatically determine the variable's type (because we are temporarily storing it in #{requestScope[...]}). However, even this does work 100%. It adds the group but, before you click Save, it is unable to display the group name. So now I am coming around to your idea! However I'd still like to simplify things as much as possible, because this is actually a bug scheduled to be fixed in JSF 2.2 (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763). I have experimented and come up with something a little quirky but not too bad (in my opinion). Sent to your other e-mail address. Please let me know if it works for you, and any improvements you think we could make. Regards, Richard. On 6/08/2012 8:39 PM, Luca Masini wrote: > Great to hear this for me, this philosophy is one of the main reason because I love forge !! > > But I also need, on my side, to make it works under WebLogic and TomEE, so we need a solution to this problem. > > I created and sent you a test case (forgive the package name, I was in a hurry !!), you can reproduce the problem this way: > > 1) Create a group > 2) Go into the Account creation form and try to associate a group to the Account > > The problem is recreated. > > Thank you for your invaluable support. > > L. > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > Luca, > > > factory that hide that complexity > > One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of user's final project. They > will > see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but then we are essentially > creating a Forge-specific, undocumented, unsupported framework on top of EE. > > Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>? Then I can try and > reproduce the errors you're seeing. > > Regards, > > Richard. > > On 6/08/2012 6:56 PM, Luca Masini wrote: > > Thank you for your feedback Richard. > > > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and on the log I can find > this line: > > > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) have been enqueued, but may > > not have been displayed. > > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not > valid), > > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to inject an extended persistence > > context inside a client object. > > > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > > > What do you think ? > > > > > > > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > > Luca, > > > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these hacks are going to get > > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as possible. In > > particular, we > > must keep the 'semantic complexity' low. > > > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of 'semantic > > complexity' for > > new users to understand? > > > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current code. Here's one > that's not > > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > > > @FacesConverter( forClass = xxx.class ) > > public static class xxxConverter > > implements Converter { > > > > @Override > > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > > > // EntityManager injection not reliable on all platforms > > > > xxx entity = new xxx(); > > entity.setId( Long.valueOf( value ) ); > > return entity; > > } > > > > @Override > > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > > > ... > > } > > } > > > > Here's a complete example: > > > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > > > Regards, > > > > Richard. > > > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the jsf client. > > > > > > This way it works. > > > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > > > Yes, you could try that. The history to this decision was: > > > > > > 1. The Converter needs to use an EntityManager to load the entity > > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would be other > > approaches, such as > > > looking up the EntityManager via JNDI or something. > > > > > > Regards, > > > > > > Richard. > > > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > > Did you think of separating Converter and backing bean implementation? > > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > > > Thomas > > > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > > >> > > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like that the > > implemented > > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > > > >> > > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now > interface bean. > > > >> > > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. > > > >> > > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? > > > >> > > > >> -- > > > >> **************************************** > > > >> http://www.lucamasini.net > > > >> http://twitter.com/lmasini > > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > >> **************************************** > > > >> > > > >> > > > >> _______________________________________________ > > > >> forge-dev mailing list > > > >> forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <javascript:;> > > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <javascript:;> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <javascript:;> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > -- > > > **************************************** > > > http://www.lucamasini.net > > > http://twitter.com/lmasini > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > **************************************** > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, Yes I agree, we are mixing sessions here. I was hoping the Converter was doing such a 'lightweight' operation that we'd get away with it. But it would be great if we could avoid that complication. It appears that if you use @ManagedBean you can do all injections as usual. So that may give you some options. For example, what if the top-level class was itself the converter, so it was a @ManagedBean as well as a @Named? Does it then work to do... ... converter="#{groupBean}" ...and therefore reuse the same @PersistenceContext? Regards, Richard. On 7/08/2012 5:45 PM, Luca Masini wrote: > Thank you for the updated, I tested it on JBoss AS 7.1.1 and WebLogic 12c and it works great !! > > I'll take time today to try to TomEE too, but I wanted to answer to you before it's too late on your timezone :) > > But I would like to discuss one implementation choice. In the ManagedBean you inject the entityManager using the @PersistenceContext annotation. > > We need to investigate if this is the same session of the Stateful EJB that is backing the JSF page, otherwise we can have two session and so diffent > view of the same DB data. > > In fact using an extended persistence context on the Stateful EJB has many advantages but raise the bar on difficulty of such simple things. > > What do you think ?? Now I'm doing some experiments to understand if that ManagedBean who is Dependent has the same Conversation scope of the Stateful > and in case if Weld inject the same Hibernate Session. > > Hope to hear your though soon. > > Ciao. > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > Luca, > > Thank you for your time and patience in working through this with me. I appreciate your enthusiasm and professionalism. > > I took a look at your sample Test Case. My apologies. The example I linked to was using a runtime version of Metawidget, not a static version. I had > underestimated the difference that would make. It seems you need to use an explicit id (eg. @FacesConverter("groupConverter") and <h:selectOneMenu ... > converter="groupConverter">). Otherwise JSF cannot automatically determine the variable's type (because we are temporarily storing it in > #{requestScope[...]}). > > However, even this does work 100%. It adds the group but, before you click Save, it is unable to display the group name. > > So now I am coming around to your idea! > > However I'd still like to simplify things as much as possible, because this is actually a bug scheduled to be fixed in JSF 2.2 > (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763). I have experimented and come up with something a little quirky but not too bad (in my > opinion). Sent to your other e-mail address. > > Please let me know if it works for you, and any improvements you think we could make. > > Regards, > > Richard. > > On 6/08/2012 8:39 PM, Luca Masini wrote: > > Great to hear this for me, this philosophy is one of the main reason because I love forge !! > > > > But I also need, on my side, to make it works under WebLogic and TomEE, so we need a solution to this problem. > > > > I created and sent you a test case (forgive the package name, I was in a hurry !!), you can reproduce the problem this way: > > > > 1) Create a group > > 2) Go into the Account creation form and try to associate a group to the Account > > > > The problem is recreated. > > > > Thank you for your invaluable support. > > > > L. > > > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > > Luca, > > > > > factory that hide that complexity > > > > One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of user's final > project. They > > will > > see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but then we are essentially > > creating a Forge-specific, undocumented, unsupported framework on top of EE. > > > > Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;? Then I can try and > > reproduce the errors you're seeing. > > > > Regards, > > > > Richard. > > > > On 6/08/2012 6:56 PM, Luca Masini wrote: > > > Thank you for your feedback Richard. > > > > > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and on the log I can find > > this line: > > > > > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) have been > enqueued, but may > > > not have been displayed. > > > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not > > valid), > > > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > > > > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to inject an extended > persistence > > > context inside a client object. > > > > > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > > > > > What do you think ? > > > > > > > > > > > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com&lt;mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt; > > > > > > Luca, > > > > > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > > > > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these hacks are > going to get > > > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as possible. In > > > particular, we > > > must keep the 'semantic complexity' low. > > > > > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of 'semantic > > > complexity' for > > > new users to understand? > > > > > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current code. > Here's one > > that's not > > > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > > > > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > > > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > > > > > @FacesConverter( forClass = xxx.class ) > > > public static class xxxConverter > > > implements Converter { > > > > > > @Override > > > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > > > > > // EntityManager injection not reliable on all platforms > > > > > > xxx entity = new xxx(); > > > entity.setId( Long.valueOf( value ) ); > > > return entity; > > > } > > > > > > @Override > > > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > > > > > ... > > > } > > > } > > > > > > Here's a complete example: > > > > > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > > > > > Regards, > > > > > > Richard. > > > > > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the jsf client. > > > > > > > > This way it works. > > > > > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > > > > > Yes, you could try that. The history to this decision was: > > > > > > > > 1. The Converter needs to use an EntityManager to load the entity > > > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would be other > > > approaches, such as > > > > looking up the EntityManager via JNDI or something. > > > > > > > > Regards, > > > > > > > > Richard. > > > > > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > > > Did you think of separating Converter and backing bean implementation? > > > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > > > > > Thomas > > > > > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > > > >> > > > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's like > that the > > > implemented > > > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > > > > >> > > > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of the now > > interface bean. > > > > >> > > > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. > > > > >> > > > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? > > > > >> > > > > >> -- > > > > >> **************************************** > > > > >> http://www.lucamasini.net > > > > >> http://twitter.com/lmasini > > > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > >> **************************************** > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> forge-dev mailing list > > > > >> forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <javascript:;> > > > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <javascript:;> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > <javascript:;> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > -- > > > > **************************************** > > > > http://www.lucamasini.net > > > > http://twitter.com/lmasini > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > **************************************** > > > > > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > -- > > > **************************************** > > > http://www.lucamasini.net > > > http://twitter.com/lmasini > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > **************************************** > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

No, that's what I meant. But I guess JBoss AS messes up :( What did you decide about if it's injecting 'the same Hibernate Session'? Regards, Richard. On 7/08/2012 6:34 PM, Luca Masini wrote: > I yet tried this and it works with WLS 12c, but then on JBoss AS it starts thinking that the Converter interface is also the EJB Local interface and the > JSF layer is unable to find any business method of the no-interface view. > > Or do you mean something else ? > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > Luca, > > Yes I agree, we are mixing sessions here. I was hoping the Converter was doing such a 'lightweight' operation that we'd get away with it. > > But it would be great if we could avoid that complication. It appears that if you use @ManagedBean you can do all injections as usual. So that may > give you > some options. For example, what if the top-level class was itself the converter, so it was a @ManagedBean as well as a @Named? Does it then work to do... > > ... converter="#{groupBean}" > > ...and therefore reuse the same @PersistenceContext? > > Regards, > > Richard. > > On 7/08/2012 5:45 PM, Luca Masini wrote: > > Thank you for the updated, I tested it on JBoss AS 7.1.1 and WebLogic 12c and it works great !! > > > > I'll take time today to try to TomEE too, but I wanted to answer to you before it's too late on your timezone :) > > > > But I would like to discuss one implementation choice. In the ManagedBean you inject the entityManager using the @PersistenceContext annotation. > > > > We need to investigate if this is the same session of the Stateful EJB that is backing the JSF page, otherwise we can have two session and so diffent > > view of the same DB data. > > > > In fact using an extended persistence context on the Stateful EJB has many advantages but raise the bar on difficulty of such simple things. > > > > What do you think ?? Now I'm doing some experiments to understand if that ManagedBean who is Dependent has the same Conversation scope of the Stateful > > and in case if Weld inject the same Hibernate Session. > > > > Hope to hear your though soon. > > > > Ciao. > > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > > Luca, > > > > Thank you for your time and patience in working through this with me. I appreciate your enthusiasm and professionalism. > > > > I took a look at your sample Test Case. My apologies. The example I linked to was using a runtime version of Metawidget, not a static version. > I had > > underestimated the difference that would make. It seems you need to use an explicit id (eg. @FacesConverter("groupConverter") and > <h:selectOneMenu ... > > converter="groupConverter">). Otherwise JSF cannot automatically determine the variable's type (because we are temporarily storing it in > > #{requestScope[...]}). > > > > However, even this does work 100%. It adds the group but, before you click Save, it is unable to display the group name. > > > > So now I am coming around to your idea! > > > > However I'd still like to simplify things as much as possible, because this is actually a bug scheduled to be fixed in JSF 2.2 > > (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763). I have experimented and come up with something a little quirky but not too bad > (in my > > opinion). Sent to your other e-mail address. > > > > Please let me know if it works for you, and any improvements you think we could make. > > > > Regards, > > > > Richard. > > > > On 6/08/2012 8:39 PM, Luca Masini wrote: > > > Great to hear this for me, this philosophy is one of the main reason because I love forge !! > > > > > > But I also need, on my side, to make it works under WebLogic and TomEE, so we need a solution to this problem. > > > > > > I created and sent you a test case (forgive the package name, I was in a hurry !!), you can reproduce the problem this way: > > > > > > 1) Create a group > > > 2) Go into the Account creation form and try to associate a group to the Account > > > > > > The problem is recreated. > > > > > > Thank you for your invaluable support. > > > > > > L. > > > > > > 2012/8/6 Richard Kennard <richard(a)kennardconsulting.com&lt;mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt; > > > > > > Luca, > > > > > > > factory that hide that complexity > > > > > > One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of user's final > > project. They > > > will > > > see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but then we are > essentially > > > creating a Forge-specific, undocumented, unsupported framework on top of EE. > > > > > > Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>? Then I can try and > > > reproduce the errors you're seeing. > > > > > > Regards, > > > > > > Richard. > > > > > > On 6/08/2012 6:56 PM, Luca Masini wrote: > > > > Thank you for your feedback Richard. > > > > > > > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and on the log I > can find > > > this line: > > > > > > > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) have been > > enqueued, but may > > > > not have been displayed. > > > > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: Validation Error: > Value is not > > > valid), > > > > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > > > > > > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to inject an extended > > persistence > > > > context inside a client object. > > > > > > > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > > > > > > > What do you think ? > > > > > > > > > > > > > > > > 2012/8/6 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>>> > > > > > > > > Luca, > > > > > > > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > > > > > > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these hacks are > > going to get > > > > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as > possible. In > > > > particular, we > > > > must keep the 'semantic complexity' low. > > > > > > > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of > 'semantic > > > > complexity' for > > > > new users to understand? > > > > > > > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current code. > > Here's one > > > that's not > > > > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > > > > > > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > > > > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > > > > > > > @FacesConverter( forClass = xxx.class ) > > > > public static class xxxConverter > > > > implements Converter { > > > > > > > > @Override > > > > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > > > > > > > // EntityManager injection not reliable on all platforms > > > > > > > > xxx entity = new xxx(); > > > > entity.setId( Long.valueOf( value ) ); > > > > return entity; > > > > } > > > > > > > > @Override > > > > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > > > > > > > ... > > > > } > > > > } > > > > > > > > Here's a complete example: > > > > > > > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > > > > > > > Regards, > > > > > > > > Richard. > > > > > > > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > > > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > > > > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > > > > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > > > > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the > jsf client. > > > > > > > > > > This way it works. > > > > > > > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > > > > > > > Yes, you could try that. The history to this decision was: > > > > > > > > > > 1. The Converter needs to use an EntityManager to load the entity > > > > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > > > > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there would > be other > > > > approaches, such as > > > > > looking up the EntityManager via JNDI or something. > > > > > > > > > > Regards, > > > > > > > > > > Richard. > > > > > > > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > > > > Did you think of separating Converter and backing bean implementation? > > > > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > > > > > > > Thomas > > > > > > > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > > > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > > > > >> > > > > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing method, it's > like > > that the > > > > implemented > > > > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > > > > > >> > > > > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of > the now > > > interface bean. > > > > > >> > > > > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter interface. > > > > > >> > > > > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but whichi ? > > > > > >> > > > > > >> -- > > > > > >> **************************************** > > > > > >> http://www.lucamasini.net > > > > > >> http://twitter.com/lmasini > > > > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > >> **************************************** > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> forge-dev mailing list > > > > > >> forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <javascript:;> > > > > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > forge-dev mailing list > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <javascript:;> > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > <javascript:;> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > -- > > > > > **************************************** > > > > > http://www.lucamasini.net > > > > > http://twitter.com/lmasini > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > **************************************** > > > > > > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > -- > > > > **************************************** > > > > http://www.lucamasini.net > > > > http://twitter.com/lmasini > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > **************************************** > > > > > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > -- > > > **************************************** > > > http://www.lucamasini.net > > > http://twitter.com/lmasini > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > **************************************** > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, I guess we need to weigh the strengths/weaknesses of each option: 1) It sounds risky to ignore it. However, the advantage of this approach is it's very close to what the 'proper' approach should be (i.e. after JSF 2.2, you'll simply replace @ManagedBean with @FacesConverter and it should work) 2) Not sure how you would do this, at least without Hibernate-specific APIs. For example, you could perhaps make use of a StatelessSession? 3) It's more than two lines, though. It involved declaring getAsObject/getAsString inside the top-level class, and then calling back into that? So maybe we could simplify that? For example: * I don't think getAsString needs to call back into the top-level class (it doesn't need the EntityManager) * it may look cleaner if the top-level class just had a (protected?) method getEntityManager that the Converter could call, rather than redefining the whole of getAsObject * perhaps it would be possible to get the EntityManager directly from the session, or via JNDI? I think we have thoroughly explored 1, and understand its shortcomings. Maybe you could try refining 3 further and then we can decide which we like best? Regards, Richard. On 8/08/2012 12:40 AM, Luca Masini wrote: > I did some simple experiments using entityManager.getDelegate() and these are what I observed: > 1) The Hibernate Session backing the EntityManager for the SessionBean is always the same for the current session of the user > 2) The Hibernate Session injected into the ManagedBean is always a new Session, of course different from that in use by the container EJB > > Now we can choose to: > > 1) Ignore this !! > 2) Don't ignore and try to figure out if this way we can find different object using the find method > 3) Use the SessionContext to point to the current Hibernate Session of the Stateful EJB (what I proposed, but we are discussing about its complexity) > > In my opinion adding two lines of code to the current template to inject the SessionContext and then get the business Interface is comparable to that of > writing a new managed bean and inject in it a different EntityManager. > > What do you think ? > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > No, that's what I meant. But I guess JBoss AS messes up :( > > What did you decide about if it's injecting 'the same Hibernate Session'? > > Regards, > > Richard. > > On 7/08/2012 6:34 PM, Luca Masini wrote: > > I yet tried this and it works with WLS 12c, but then on JBoss AS it starts thinking that the Converter interface is also the EJB Local interface > and the > > JSF layer is unable to find any business method of the no-interface view. > > > > Or do you mean something else ? > > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > > Luca, > > > > Yes I agree, we are mixing sessions here. I was hoping the Converter was doing such a 'lightweight' operation that we'd get away with it. > > > > But it would be great if we could avoid that complication. It appears that if you use @ManagedBean you can do all injections as usual. So that may > > give you > > some options. For example, what if the top-level class was itself the converter, so it was a @ManagedBean as well as a @Named? Does it then > work to do... > > > > ... converter="#{groupBean}" > > > > ...and therefore reuse the same @PersistenceContext? > > > > Regards, > > > > Richard. > > > > On 7/08/2012 5:45 PM, Luca Masini wrote: > > > Thank you for the updated, I tested it on JBoss AS 7.1.1 and WebLogic 12c and it works great !! > > > > > > I'll take time today to try to TomEE too, but I wanted to answer to you before it's too late on your timezone :) > > > > > > But I would like to discuss one implementation choice. In the ManagedBean you inject the entityManager using the @PersistenceContext annotation. > > > > > > We need to investigate if this is the same session of the Stateful EJB that is backing the JSF page, otherwise we can have two session and so > diffent > > > view of the same DB data. > > > > > > In fact using an extended persistence context on the Stateful EJB has many advantages but raise the bar on difficulty of such simple things. > > > > > > What do you think ?? Now I'm doing some experiments to understand if that ManagedBean who is Dependent has the same Conversation scope of the > Stateful > > > and in case if Weld inject the same Hibernate Session. > > > > > > Hope to hear your though soon. > > > > > > Ciao. > > > > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com&lt;mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt; > > > > > > Luca, > > > > > > Thank you for your time and patience in working through this with me. I appreciate your enthusiasm and professionalism. > > > > > > I took a look at your sample Test Case. My apologies. The example I linked to was using a runtime version of Metawidget, not a static > version. > > I had > > > underestimated the difference that would make. It seems you need to use an explicit id (eg. @FacesConverter("groupConverter") and > > <h:selectOneMenu ... > > > converter="groupConverter">). Otherwise JSF cannot automatically determine the variable's type (because we are temporarily storing it in > > > #{requestScope[...]}). > > > > > > However, even this does work 100%. It adds the group but, before you click Save, it is unable to display the group name. > > > > > > So now I am coming around to your idea! > > > > > > However I'd still like to simplify things as much as possible, because this is actually a bug scheduled to be fixed in JSF 2.2 > > > ( http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763). I have experimented and come up with something a little quirky but not too bad > > (in my > > > opinion). Sent to your other e-mail address. > > > > > > Please let me know if it works for you, and any improvements you think we could make. > > > > > > Regards, > > > > > > Richard. > > > > > > On 6/08/2012 8:39 PM, Luca Masini wrote: > > > > Great to hear this for me, this philosophy is one of the main reason because I love forge !! > > > > > > > > But I also need, on my side, to make it works under WebLogic and TomEE, so we need a solution to this problem. > > > > > > > > I created and sent you a test case (forgive the package name, I was in a hurry !!), you can reproduce the problem this way: > > > > > > > > 1) Create a group > > > > 2) Go into the Account creation form and try to associate a group to the Account > > > > > > > > The problem is recreated. > > > > > > > > Thank you for your invaluable support. > > > > > > > > L. > > > > > > > > 2012/8/6 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>>> > > > > > > > > Luca, > > > > > > > > > factory that hide that complexity > > > > > > > > One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of user's final > > > project. They > > > > will > > > > see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but then we are > > essentially > > > > creating a Forge-specific, undocumented, unsupported framework on top of EE. > > > > > > > > Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt;? Then I can try and > > > > reproduce the errors you're seeing. > > > > > > > > Regards, > > > > > > > > Richard. > > > > > > > > On 6/08/2012 6:56 PM, Luca Masini wrote: > > > > > Thank you for your feedback Richard. > > > > > > > > > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and on the > log I > > can find > > > > this line: > > > > > > > > > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) have been > > > enqueued, but may > > > > > not have been displayed. > > > > > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: Validation Error: > > Value is not > > > > valid), > > > > > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > > > > > > > > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to inject an > extended > > > persistence > > > > > context inside a client object. > > > > > > > > > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > > > > > > > > > What do you think ? > > > > > > > > > > > > > > > > > > > > 2012/8/6 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>> > > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt;&gt;&gt; > > > > > > > > > > Luca, > > > > > > > > > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > > > > > > > > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these > hacks are > > > going to get > > > > > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as > > possible. In > > > > > particular, we > > > > > must keep the 'semantic complexity' low. > > > > > > > > > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds like a lot of > > 'semantic > > > > > complexity' for > > > > > new users to understand? > > > > > > > > > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the current > code. > > > Here's one > > > > that's not > > > > > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > > > > > > > > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > > > > > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > > > > > > > > > @FacesConverter( forClass = xxx.class ) > > > > > public static class xxxConverter > > > > > implements Converter { > > > > > > > > > > @Override > > > > > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > > > > > > > > > // EntityManager injection not reliable on all platforms > > > > > > > > > > xxx entity = new xxx(); > > > > > entity.setId( Long.valueOf( value ) ); > > > > > return entity; > > > > > } > > > > > > > > > > @Override > > > > > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > > > > > > > > > ... > > > > > } > > > > > } > > > > > > > > > > Here's a complete example: > > > > > > > > > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > > > > > > > > > Regards, > > > > > > > > > > Richard. > > > > > > > > > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > > > > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > > > > > > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > > > > > > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > > > > > > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is returned to the > > jsf client. > > > > > > > > > > > > This way it works. > > > > > > > > > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > > > > > > > > > Yes, you could try that. The history to this decision was: > > > > > > > > > > > > 1. The Converter needs to use an EntityManager to load the entity > > > > > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > > > > > > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However there > would > > be other > > > > > approaches, such as > > > > > > looking up the EntityManager via JNDI or something. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Richard. > > > > > > > > > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > > > > > Did you think of separating Converter and backing bean implementation? > > > > > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > > > > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > > > > > >> > > > > > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing > method, it's > > like > > > that the > > > > > implemented > > > > > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface itself. > > > > > > >> > > > > > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are method of > > the now > > > > interface bean. > > > > > > >> > > > > > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter > interface. > > > > > > >> > > > > > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but > whichi ? > > > > > > >> > > > > > > >> -- > > > > > > >> **************************************** > > > > > > >> http://www.lucamasini.net > > > > > > >> http://twitter.com/lmasini > > > > > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > > >> **************************************** > > > > > > >> > > > > > > >> > > > > > > >> _______________________________________________ > > > > > > >> forge-dev mailing list > > > > > > >> forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; > > > > <javascript:;> > > > > > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > forge-dev mailing list > > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; > > > > <javascript:;> > > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > _______________________________________________ > > > > > > forge-dev mailing list > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > <javascript:;> > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > **************************************** > > > > > > http://www.lucamasini.net > > > > > > http://twitter.com/lmasini > > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > > **************************************** > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > forge-dev mailing list > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > **************************************** > > > > > http://www.lucamasini.net > > > > > http://twitter.com/lmasini > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > **************************************** > > > > > > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > -- > > > > **************************************** > > > > http://www.lucamasini.net > > > > http://twitter.com/lmasini > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > **************************************** > > > > > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > -- > > > **************************************** > > > http://www.lucamasini.net > > > http://twitter.com/lmasini > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > **************************************** > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Luca, Ah yes, that is looking much nicer. Could we maybe refactor the existing retrieve() method to make use of findById? Also, I think the @ManagedBean approach saves us a few lines over the anonymous inner-class approach? So something like: @ManagedBean( name = "groupConverter" ) public static class GroupConverter implements Converter { @Resource private SessionContext sessionContext; @Override public Object getAsObject( FacesContext context, UIComponent component, String value ) { return sessionContext.getBusinessObject(GroupBean.class).findById(Long.valueOf(value)); } @Override public String getAsString( FacesContext context, UIComponent component, Object value ) { if (value == null) { return ""; } return String.valueOf(((Group) value).getId()); } } On 8/08/2012 6:05 PM, Luca Masini wrote: > Hi Richard, I tried the scenario you described and from my "experiments" I can say that: > 1) We can lookup the PersistenceUnit but not the PersistenceContext, so in this case we can create a new EntityManager, just like you did with injection. > And also the code for this lookup is more than one line. > > 2) We can't publish the entityManager with a protected method, is not part of the no-interface-view, and I sure don't want to publish as public such an > internal thing. > > 3) These "backing-bean" are missing the getById (or findById, depends on your taste), we can think about implementing it and then the code for the > anonymous class is really simple: > > @Resource > SessionContext sessionContext; > public Converter getConverter() { > > final GroupBean ejbProxy = sessionContext.getBusinessObject(GroupBean.class); > > return new Converter() { > @Override > public Object getAsObject(FacesContext context, UIComponent component, String value) { > > return ejbProxy.findById(Long.valueOf(value)); > } > > @Override > public String getAsString(FacesContext context, UIComponent component, Object value) { > if (value == null) > { > return ""; > } > > return String.valueOf(((Group) value).getId()); > } > }; > } > > As you yet noticed, no need of EJB services for the getAsString method. That's my 2 cents, let me know what do you think. > > Ciao. > L. > > > 2012/8/8 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > Luca, > > I guess we need to weigh the strengths/weaknesses of each option: > > 1) It sounds risky to ignore it. However, the advantage of this approach is it's very close to what the 'proper' approach should be (i.e. after JSF 2.2, > you'll simply replace @ManagedBean with @FacesConverter and it should work) > > 2) Not sure how you would do this, at least without Hibernate-specific APIs. For example, you could perhaps make use of a StatelessSession? > > 3) It's more than two lines, though. It involved declaring getAsObject/getAsString inside the top-level class, and then calling back into that? So > maybe we > could simplify that? For example: > > * I don't think getAsString needs to call back into the top-level class (it doesn't need the EntityManager) > * it may look cleaner if the top-level class just had a (protected?) method getEntityManager that the Converter could call, rather than redefining the > whole of getAsObject > * perhaps it would be possible to get the EntityManager directly from the session, or via JNDI? > > I think we have thoroughly explored 1, and understand its shortcomings. Maybe you could try refining 3 further and then we can decide which we like best? > > Regards, > > Richard. > > On 8/08/2012 12:40 AM, Luca Masini wrote: > > I did some simple experiments using entityManager.getDelegate() and these are what I observed: > > 1) The Hibernate Session backing the EntityManager for the SessionBean is always the same for the current session of the user > > 2) The Hibernate Session injected into the ManagedBean is always a new Session, of course different from that in use by the container EJB > > > > Now we can choose to: > > > > 1) Ignore this !! > > 2) Don't ignore and try to figure out if this way we can find different object using the find method > > 3) Use the SessionContext to point to the current Hibernate Session of the Stateful EJB (what I proposed, but we are discussing about its complexity) > > > > In my opinion adding two lines of code to the current template to inject the SessionContext and then get the business Interface is comparable to > that of > > writing a new managed bean and inject in it a different EntityManager. > > > > What do you think ? > > > > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > > No, that's what I meant. But I guess JBoss AS messes up :( > > > > What did you decide about if it's injecting 'the same Hibernate Session'? > > > > Regards, > > > > Richard. > > > > On 7/08/2012 6:34 PM, Luca Masini wrote: > > > I yet tried this and it works with WLS 12c, but then on JBoss AS it starts thinking that the Converter interface is also the EJB Local interface > > and the > > > JSF layer is unable to find any business method of the no-interface view. > > > > > > Or do you mean something else ? > > > > > > 2012/8/7 Richard Kennard <richard(a)kennardconsulting.com&lt;mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt; > > > > > > Luca, > > > > > > Yes I agree, we are mixing sessions here. I was hoping the Converter was doing such a 'lightweight' operation that we'd get away with it. > > > > > > But it would be great if we could avoid that complication. It appears that if you use @ManagedBean you can do all injections as usual. So > that may > > > give you > > > some options. For example, what if the top-level class was itself the converter, so it was a @ManagedBean as well as a @Named? Does it then > > work to do... > > > > > > ... converter="#{groupBean}" > > > > > > ...and therefore reuse the same @PersistenceContext? > > > > > > Regards, > > > > > > Richard. > > > > > > On 7/08/2012 5:45 PM, Luca Masini wrote: > > > > Thank you for the updated, I tested it on JBoss AS 7.1.1 and WebLogic 12c and it works great !! > > > > > > > > I'll take time today to try to TomEE too, but I wanted to answer to you before it's too late on your timezone :) > > > > > > > > But I would like to discuss one implementation choice. In the ManagedBean you inject the entityManager using the @PersistenceContext > annotation. > > > > > > > > We need to investigate if this is the same session of the Stateful EJB that is backing the JSF page, otherwise we can have two session > and so > > diffent > > > > view of the same DB data. > > > > > > > > In fact using an extended persistence context on the Stateful EJB has many advantages but raise the bar on difficulty of such simple > things. > > > > > > > > What do you think ?? Now I'm doing some experiments to understand if that ManagedBean who is Dependent has the same Conversation scope > of the > > Stateful > > > > and in case if Weld inject the same Hibernate Session. > > > > > > > > Hope to hear your though soon. > > > > > > > > Ciao. > > > > > > > > 2012/8/7 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>>> > > > > > > > > Luca, > > > > > > > > Thank you for your time and patience in working through this with me. I appreciate your enthusiasm and professionalism. > > > > > > > > I took a look at your sample Test Case. My apologies. The example I linked to was using a runtime version of Metawidget, not a static > > version. > > > I had > > > > underestimated the difference that would make. It seems you need to use an explicit id (eg. @FacesConverter("groupConverter") and > > > <h:selectOneMenu ... > > > > converter="groupConverter">). Otherwise JSF cannot automatically determine the variable's type (because we are temporarily storing it in > > > > #{requestScope[...]}). > > > > > > > > However, even this does work 100%. It adds the group but, before you click Save, it is unable to display the group name. > > > > > > > > So now I am coming around to your idea! > > > > > > > > However I'd still like to simplify things as much as possible, because this is actually a bug scheduled to be fixed in JSF 2.2 > > > > ( http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-763). I have experimented and come up with something a little quirky but > not too bad > > > (in my > > > > opinion). Sent to your other e-mail address. > > > > > > > > Please let me know if it works for you, and any improvements you think we could make. > > > > > > > > Regards, > > > > > > > > Richard. > > > > > > > > On 6/08/2012 8:39 PM, Luca Masini wrote: > > > > > Great to hear this for me, this philosophy is one of the main reason because I love forge !! > > > > > > > > > > But I also need, on my side, to make it works under WebLogic and TomEE, so we need a solution to this problem. > > > > > > > > > > I created and sent you a test case (forgive the package name, I was in a hurry !!), you can reproduce the problem this way: > > > > > > > > > > 1) Create a group > > > > > 2) Go into the Account creation form and try to associate a group to the Account > > > > > > > > > > The problem is recreated. > > > > > > > > > > Thank you for your invaluable support. > > > > > > > > > > L. > > > > > > > > > > 2012/8/6 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>> > > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt;&gt;&gt; > > > > > > > > > > Luca, > > > > > > > > > > > factory that hide that complexity > > > > > > > > > > One of the main challenges we have is that there *is* nowhere to 'hide that complexity'. Everything we generate is part of > user's final > > > > project. They > > > > > will > > > > > see it, and therefore will need to understand and maintain it. We *did* originally try creating base classes/factories, but > then we are > > > essentially > > > > > creating a Forge-specific, undocumented, unsupported framework on top of EE. > > > > > > > > > > Could you please ZIP up your sample app and send it to me at richard(a)kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt; > > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>>>? Then I can try and > > > > > reproduce the errors you're seeing. > > > > > > > > > > Regards, > > > > > > > > > > Richard. > > > > > > > > > > On 6/08/2012 6:56 PM, Luca Masini wrote: > > > > > > Thank you for your feedback Richard. > > > > > > > > > > > > I tried your proposal and it breaks something else because the annotated class is used everywhere to convert the POJO, and > on the > > log I > > > can find > > > > > this line: > > > > > > > > > > > > 10:45:46,485 INFO [javax.enterprise.resource.webcontainer.jsf.renderkit] (http--127.0.0.1-8080-2) WARNING: FacesMessage(s) > have been > > > > enqueued, but may > > > > > > not have been displayed. > > > > > > sourceId=create:accountBeanAccountGroupsSelect[severity=(ERROR 2), summary=(create:accountBeanAccountGroupsSelect: > Validation Error: > > > Value is not > > > > > valid), > > > > > > detail=(create:accountBeanAccountGroupsSelect: Validation Error: Value is not valid)] > > > > > > > > > > > > Regarding the solution I proposed, I agree that generated code must be simple, but I really can't figure another way to > inject an > > extended > > > > persistence > > > > > > context inside a client object. > > > > > > > > > > > > In case we factor out the converter and write an util class with a factory that hide that complexity. > > > > > > > > > > > > What do you think ? > > > > > > > > > > > > > > > > > > > > > > > > 2012/8/6 Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>> > > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>>> > > > > > <mailto:richard@kennardconsulting.com<mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com> > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt;&gt;&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com> <mailto: richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> > > > <mailto:richard@kennardconsulting.com <mailto: richard(a)kennardconsulting.com&gt; <mailto:richard@kennardconsulting.com > <mailto:richard@kennardconsulting.com>>>>>>> > > > > > > > > > > > > Luca, > > > > > > > > > > > > Thanks for your time and help debugging this. I think we need to proceed with caution. > > > > > > > > > > > > We're basically talking about hacks to work around bugs in the app server/shortcomings in the EE spec. The problem is these > > hacks are > > > > going to get > > > > > > re-generated for every domain entity (potentially dozens of times). It's critical we try to keep our generated code as clean as > > > possible. In > > > > > > particular, we > > > > > > must keep the 'semantic complexity' low. > > > > > > > > > > > > The solution you're suggesting (injecting a SessionContext, taking EJBObject using getBusinessInterface etc) sounds > like a lot of > > > 'semantic > > > > > > complexity' for > > > > > > new users to understand? > > > > > > > > > > > > It's really important we try to find the cleanest approach. We tried/rejected a lot of variations when developing the > current > > code. > > > > Here's one > > > > > that's not > > > > > > quite as nice as the current one, but may work properly across TomEE/Weblogic/JBoss. Could you try it for me? > > > > > > > > > > > > 1. Remove all references in the generated Facelets code to: converter="#{foo.converter}" > > > > > > 2. Remove the 'getConverter()' method inside each xxxBean and replace with a static inner class that looks like: > > > > > > > > > > > > @FacesConverter( forClass = xxx.class ) > > > > > > public static class xxxConverter > > > > > > implements Converter { > > > > > > > > > > > > @Override > > > > > > public Object getAsObject( FacesContext context, UIComponent component, String value ) { > > > > > > > > > > > > // EntityManager injection not reliable on all platforms > > > > > > > > > > > > xxx entity = new xxx(); > > > > > > entity.setId( Long.valueOf( value ) ); > > > > > > return entity; > > > > > > } > > > > > > > > > > > > @Override > > > > > > public String getAsString( FacesContext context, UIComponent component, Object value ) { > > > > > > > > > > > > ... > > > > > > } > > > > > > } > > > > > > > > > > > > Here's a complete example: > > > > > > > > > > > > https://github.com/metawidget/metawidget/blob/master/integration-tests/fa... > > > > > > > > > > > > Regards, > > > > > > > > > > > > Richard. > > > > > > > > > > > > On 3/08/2012 9:17 PM, Luca Masini wrote: > > > > > > > The fact is that we have an extended persistente unit bound to the stateful ejb, so can't be injected or looked up. > > > > > > > > > > > > > > I've found a solution working on my three target App Server (TomEE, Weblogic, JBoss). > > > > > > > > > > > > > > Inject a SessionContext and take the EJBObject using the getBusinessInterface method. > > > > > > > > > > > > > > For some strange reason SessionContext and his Ejb have different lifecycle so we need to take it before it is > returned to the > > > jsf client. > > > > > > > > > > > > > > This way it works. > > > > > > > > > > > > > > Il giorno venerdì 3 agosto 2012, Richard Kennard ha scritto: > > > > > > > > > > > > > > Yes, you could try that. The history to this decision was: > > > > > > > > > > > > > > 1. The Converter needs to use an EntityManager to load the entity > > > > > > > 2. For some reason you cannot (yet) inject EntityManagers into FacesConverters > > > > > > > > > > > > > > So I made the Converter an inner class of the xxxBean, so that it could access the bean's EntityManager. However > there > > would > > > be other > > > > > > approaches, such as > > > > > > > looking up the EntityManager via JNDI or something. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Richard. > > > > > > > > > > > > > > On 3/08/2012 8:15 PM, Thomas Frühbeck wrote: > > > > > > > > Did you think of separating Converter and backing bean implementation? > > > > > > > > AFAIK the backing bean _provides_ a converter e.g.: #{xxxxxBean.converter} but should not implement Converter itself? > > > > > > > > > > > > > > > > Thomas > > > > > > > > > > > > > > > > Am 03.08.2012 11:13, schrieb Luca Masini: > > > > > > > >> I'm going crazy to let the generated faces scaffolding run on both WLS and JBoss. > > > > > > > >> > > > > > > > >> Infact if I let the Bean implements the Converter interface then WLS works but JBoss complaints about missing > > method, it's > > > like > > > > that the > > > > > > implemented > > > > > > > >> interface is the Local interface for the bean and no other method is found but those in the Converter interface > itself. > > > > > > > >> > > > > > > > >> So I remove the interface and everything work without the getConverter method, getAsObject and getAsString are > method of > > > the now > > > > > interface bean. > > > > > > > >> > > > > > > > >> On the counter side WLS is unable to call methods from the EL into faces files that are not part of the Converter > > interface. > > > > > > > >> > > > > > > > >> So I'm in a deadlock. I'm unable to let it works on both the Java EE 6 server. I'm sure that a solution exist, but > > whichi ? > > > > > > > >> > > > > > > > >> -- > > > > > > > >> **************************************** > > > > > > > >> http://www.lucamasini.net > > > > > > > >> http://twitter.com/lmasini > > > > > > > >> http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > > > >> **************************************** > > > > > > > >> > > > > > > > >> > > > > > > > >> _______________________________________________ > > > > > > > >> forge-dev mailing list > > > > > > > >> forge-dev(a)lists.jboss.org&lt;mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>>>> > > > > > <javascript:;> > > > > > > > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > forge-dev mailing list > > > > > > > > forge-dev(a)lists.jboss.org&lt;mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>>>> > > > > > <javascript:;> > > > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > _______________________________________________ > > > > > > > forge-dev mailing list > > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>>> > > > > <javascript:;> > > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > **************************************** > > > > > > > http://www.lucamasini.net > > > > > > > http://twitter.com/lmasini > > > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > > > **************************************** > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > forge-dev mailing list > > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org >> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt;&gt; > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>>> > > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > _______________________________________________ > > > > > > forge-dev mailing list > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>>> > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > **************************************** > > > > > > http://www.lucamasini.net > > > > > > http://twitter.com/lmasini > > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > > **************************************** > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > forge-dev mailing list > > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt;&gt;&gt; > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>>> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > **************************************** > > > > > http://www.lucamasini.net > > > > > http://twitter.com/lmasini > > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > > **************************************** > > > > > > > > > > > > > > > _______________________________________________ > > > > > forge-dev mailing list > > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org > <mailto:forge-dev@lists.jboss.org>> <mailto: forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto: forge-dev(a)lists.jboss.org > <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > > > > > > -- > > > > **************************************** > > > > http://www.lucamasini.net > > > > http://twitter.com/lmasini > > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > > **************************************** > > > > > > > > > > > > _______________________________________________ > > > > forge-dev mailing list > > > > forge-dev(a)lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt; <mailto:forge-dev@lists.jboss.org <mailto: forge-dev(a)lists.jboss.org&gt;&gt; > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > > > > > > -- > > > **************************************** > > > http://www.lucamasini.net > > > http://twitter.com/lmasini > > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > > **************************************** > > > > > > > > > _______________________________________________ > > > forge-dev mailing list > > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> <mailto:forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org>> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > > > > > -- > > **************************************** > > http://www.lucamasini.net > > http://twitter.com/lmasini > > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > > **************************************** > > > > > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > **************************************** > http://www.lucamasini.net > http://twitter.com/lmasini > http://www.linkedin.com/pub/luca-masini/7/10/2b9 > **************************************** > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev