[forge-dev] JBoss and WebLogic

Luca Masini luca.masini.mailing.list at gmail.com
Mon Aug 6 06:39:48 EDT 2012


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 at 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 at 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 at kennardconsulting.com <mailto:
> richard at 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 at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> <javascript:;>
> >     >     >> https://lists.jboss.org/mailman/listinfo/forge-dev
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > forge-dev mailing list
> >     >     > forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> <javascript:;>
> >     >     > https://lists.jboss.org/mailman/listinfo/forge-dev
> >     >
> >     >     _______________________________________________
> >     >     forge-dev mailing list
> >     > forge-dev at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >     _______________________________________________
> >     forge-dev mailing list
> >     forge-dev at lists.jboss.org <mailto:forge-dev at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/forge-dev
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at 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
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20120806/09f20dc8/attachment.html 


More information about the forge-dev mailing list