Upgrade to Geronimo 1.1 and M2 conversion

[Dain Sundstrom]

Geronimo 1.1
------------
I've created a branch for geronimo 1.1 integration.  I think the  
integration is complete, but I haven't fully tested it yet.  I'm gong  
to try using this in openejb 3 and will patch as needed.

Even after I test this, I'm not sure we should apply this to trunk.  
The geronimo 1.1 work manager needs a GeronimoExecutor passed to the  
constructor.  The means that we must include the geronimo-core and  
geronimo-system jars.  I'm going to try to get this removed in  
geronimo 1.1.1, but they may not go for it.

M2 Conversion
-------------
I've also converted the build to m2 because m1 pisses me off.  I  
spent some time cleaning up the dependencies, but I think we need to  
make a clear decision what is core to this project and tag all other  
dependencies as optional and document which deps a user will need to  
get an optional part to work.


All JAR
-------
The -all jar is still in place.  The src/assemble/all.xml file has an  
explicit list of dependencies we include in this jar, which helps us  
to avoid the maven transitive problems.


Factory Beans
-------------
Some FactoryBeans set default properties in afterPropertiesSet and  
some set it in the getter.  I think we should choose a style and  
stick with it.

Some FactoryBeans dig through the applicationContext to find  
dependencies which weren't set via setters (poor man's auto wiring).  
This seems like bad form.  Should we keep this code?  If so, should  
we change all beans to "dig" for dependencies as a last resort?

-dain

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[James.Strachan]

All that sounds cool...

On 7/18/06, Dain Sundstrom <dain@...> wrote:

> Geronimo 1.1
> ------------
> I've created a branch for geronimo 1.1 integration.  I think the
> integration is complete, but I haven't fully tested it yet.  I'm gong
> to try using this in openejb 3 and will patch as needed.
>
> Even after I test this, I'm not sure we should apply this to trunk.
> The geronimo 1.1 work manager needs a GeronimoExecutor passed to the
> constructor.  The means that we must include the geronimo-core and
> geronimo-system jars.  I'm going to try to get this removed in
> geronimo 1.1.1, but they may not go for it.
>
> M2 Conversion
> -------------
> I've also converted the build to m2 because m1 pisses me off.  I
> spent some time cleaning up the dependencies, but I think we need to
> make a clear decision what is core to this project and tag all other
> dependencies as optional and document which deps a user will need to
> get an optional part to work.
>
>
> All JAR
> -------
> The -all jar is still in place.  The src/assemble/all.xml file has an
> explicit list of dependencies we include in this jar, which helps us
> to avoid the maven transitive problems.
>
>
> Factory Beans
> -------------
> Some FactoryBeans set default properties in afterPropertiesSet and
> some set it in the getter.  I think we should choose a style and
> stick with it.
>
> Some FactoryBeans dig through the applicationContext to find
> dependencies which weren't set via setters (poor man's auto wiring).
> This seems like bad form.  Should we keep this code?  If so, should
> we change all beans to "dig" for dependencies as a last resort?

Yeah - we should generally use DI for everything. Though I've found
myself of late making some POJOs which allow complete DI but if folks
forget to specify stuff they create useful defaults which I think is
OK. Though POJOs shouldn't have to lookup in the applicationContext
particularly much.

The one case I can think of in Jencks where this is not the case is
for MDPs; where we use the applicationContext to look up POJOs for
instances of endpoints. i.e. we actually use the applicationContext as
a factory of instances of a MessageListener for each physical
endpoint.

Are there other cases where we lookup stuff in the applicationContext?
--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Barry Kaplan]

I have had lots of problems with the factory bean and circular
references when converting to spring 2.0. The factories do all kinds of
lookups in the context which I simply could not get to work. I would be
really nice these were internally simplified.

What I ended up having to do is below. Essentially I looked thru the
factories and ensured that each had everything it needed so it never did
a lookup by type in the context.

-barry


    <bean id="txn.jencks.transactionManagerImpl"
       
class="org.apache.geronimo.transaction.manager.TransactionManagerImpl">
        <constructor-arg index="0" value="600"/>
        <constructor-arg index="1">
            <bean
class="org.apache.geronimo.transaction.log.UnrecoverableLog"/>
        </constructor-arg>
        <constructor-arg index="2"><null/></constructor-arg>
    </bean>
   
    <bean id="tnx.jencks.transactionContextManager"
        class="org.jencks.factory.TransactionContextManagerFactoryBean">
        <property name="transactionManager"
ref="txn.jencks.transactionManagerImpl"/>
        <property name="xidImporter"
ref="txn.jencks.transactionManagerImpl"/>
    </bean>
       
    <bean id="txn.jencks.transactionSupport"
        class="org.jencks.factory.XATransactionFactoryBean">
        <property name="useTransactionCaching" value="true" />
        <property name="useThreadCaching" value="false" />
    </bean>

    <bean id="txn.jta.userTransactionManager"
        class="org.jencks.factory.GeronimoTransactionManagerFactoryBean">
        <property name="transactionContextManager"
ref="tnx.jencks.transactionContextManager"/>
    </bean>

    <bean id="txn.jta.platformTransactionManager" lazy-init="true"
        class="org.springframework.transaction.jta.JtaTransactionManager">
        <property name="userTransaction"
ref="txn.jta.userTransactionManager" />
    </bean>
   

> Factory Beans
> -------------
> Some FactoryBeans set default properties in afterPropertiesSet and
> some set it in the getter.  I think we should choose a style and stick
> with it.
>
> Some FactoryBeans dig through the applicationContext to find
> dependencies which weren't set via setters (poor man's auto wiring).  
> This seems like bad form.  Should we keep this code?  If so, should we
> change all beans to "dig" for dependencies as a last resort?
>
> -dain
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email