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