Hi Richard, I tried the scenario you described and from my "experiments" I can say that:
1) We can lookup the PersistenceUnit but not the PersistenceContext, so in this case we can create a new EntityManager, just like you did with injection. And also the code for this lookup is more than one line.

2) We can't publish the entityManager with a protected method, is not part of the no-interface-view, and I sure don't want to publish as public such an internal thing.

3) These "backing-bean" are missing the getById (or findById, depends on your taste), we can think about implementing it and then the code for the anonymous class is really simple:

    @Resource
    SessionContext sessionContext;
    public Converter getConverter() {

        final GroupBean ejbProxy = sessionContext.getBusinessObject(GroupBean.class);

        return new Converter() {
            @Override
            public Object getAsObject(FacesContext context, UIComponent component, String value) {

                return ejbProxy.findById(Long.valueOf(value));
            }

            @Override
            public String getAsString(FacesContext context, UIComponent component, Object value) {
                if (value == null)
                {
                    return "";
                }

                return String.valueOf(((Group) value).getId());
            }
        };
    }

As you yet noticed, no need of EJB services for the getAsString method. That's my 2 cents, let me know what do you think.

Ciao.
L.


2012/8/8 Richard Kennard <richard@kennardconsulting.com>
Luca,

I guess we need to weigh the strengths/weaknesses of each option:

1) It sounds risky to ignore it. However, the advantage of this approach is it's very close to what the 'proper' approach should be (i.e. after JSF 2.2,
you'll simply replace @ManagedBean with @FacesConverter and it should work)

2) Not sure how you would do this, at least without Hibernate-specific APIs. For example, you could perhaps make use of a StatelessSession?

3) It's more than two lines, though. It involved declaring getAsObject/getAsString inside the top-level class, and then calling back into that? So maybe we
could simplify that? For example:

* I don't think getAsString needs to call back into the top-level class (it doesn't need the EntityManager)
* it may look cleaner if the top-level class just had a (protected?) method getEntityManager that the Converter could call, rather than redefining the
whole of getAsObject
* perhaps it would be possible to get the EntityManager directly from the session, or via JNDI?

I think we have thoroughly explored 1, and understand its shortcomings. Maybe you could try refining 3 further and then we can decide which we like best?

Regards,

Richard.

On 8/08/2012 12:40 AM, Luca Masini wrote:
> I did some simple experiments using entityManager.getDelegate() and these are what I observed:
> 1) The Hibernate Session backing the EntityManager for the SessionBean is always the same for the current session of the user
> 2) The Hibernate Session injected into the ManagedBean is always a new Session, of course different from that in use by the container EJB
>
> Now we can choose to:
>
> 1) Ignore this !!
> 2) Don't ignore and try to figure out if this way we can find different object using the find method
> 3) Use the SessionContext to point to the current Hibernate Session of the Stateful EJB (what I proposed, but we are discussing about its complexity)
>
> In my opinion adding two lines of code to the current template to inject the SessionContext and then get the business Interface is comparable to that of
> writing a new managed bean and inject in it a different EntityManager.
>
> What do you think ?
>
>
> 2012/8/7 Richard Kennard <richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>
>
>     No, that's what I meant. But I guess JBoss AS messes up :(
>
>     What did you decide about if it's injecting 'the same Hibernate Session'?
>
>     Regards,
>
>     Richard.
>
>     On 7/08/2012 6:34 PM, Luca Masini wrote:
>     > 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@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
>     <mailto:richard@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@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com>> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
>     >     <mailto:richard@kennardconsulting.com <mailto:richard@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@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com>> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
>     >     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>
>     >     >     <mailto:richard@kennardconsulting.com <mailto:richard@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@kennardconsulting.com <mailto:richard@kennardconsulting.com>
>     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>
>     >     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com>>>
>     >     <mailto:richard@kennardconsulting.com <mailto: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>
>     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com>
>     >     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>>
>     >     >     <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com> <mailto:richard@kennardconsulting.com
>     <mailto:richard@kennardconsulting.com>>>> <mailto:richard@kennardconsulting.com <mailto:richard@kennardconsulting.com>
>     >     <mailto: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> <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 <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>>>> <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 <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> <mailto: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> <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 <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>>>> <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 <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> <mailto: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> <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 <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>>>>
>     >     >     <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
>     <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> <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@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>>> <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 <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
>     >     >     >     >
>     >     >     >     > _______________________________________________
>     >     >     >     >     forge-dev mailing list
>     >     >     >     > 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
>     <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> <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@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>>>
>     >     <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 <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> <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 <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@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
>     >     >
>     >     > _______________________________________________
>     >     >     forge-dev mailing list
>     >     > 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 <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 <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@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@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
****************************************