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@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@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@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/faces/forge/src/main/java/com/test/view/PersonBean.java
>
>     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@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <javascript:;>
>     >     >> https://lists.jboss.org/mailman/listinfo/forge-dev
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > forge-dev mailing list
>     >     > forge-dev@lists.jboss.org <mailto:forge-dev@lists.jboss.org> <javascript:;>
>     >     > https://lists.jboss.org/mailman/listinfo/forge-dev
>     >
>     >     _______________________________________________
>     >     forge-dev mailing list
>     > 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@lists.jboss.org <mailto:forge-dev@lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/forge-dev
>
>     _______________________________________________
>     forge-dev mailing list
>     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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________
forge-dev mailing list
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
****************************************