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