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