[server] JSR250...?

[Robert Burrell Donkin <ro...@gmail.com>]

wasted enough time last week trying to make sieve work to finally
motivate me to take on phoenix. i think i'm now making progress. i'm
basically looking for ways to keep phoenix as a platform without such
a strong dependency on the avalon framework. i'm fine with the
excalibur components, and the dependency on avalon through them. i'm
fine with a container which supports avalon components but i want a
choice. i find avalon and phoenix too heavyweight and underdocumented.
i'm fed up of spending a day coding a POJO then another day fighting
with phoenix and avalon.

so, i've been discovering new ways to use an old container

my starting point was JSR 250 (Common Annotations for the Java
Platform) which is used to control service injection in ejb3. i hadn't
really studied in detail before but i took a better look and liked
what i saw. they're lightweight and not too strongly coupled to the
ejb model. it has the advantage of being a standard that plays well
with other containers.

to deploy a mailet (with a service dependency) on james using JSR250,
mark the setters with @Resource for example:

public class SieveMailet extends SieveMailboxMailet {

    @Resource(name="imapserver")
    @Override
    public void setPoster(Poster arg0) {
        super.setPoster(arg0);
    }
}

this would then lookup the "imapserver" service. phoenix blocks have
names so just map imapserver resource -> imapserver block.

i quite like this idea but just doing mailet's isn't enough: the
mailet loader needs access to a service locator to resolve the
resource.

the avalon service manager could be used but has the limitation that
every resource has to be a block provided to James. this is the heart
of my issues so i'd like to avoid this. phoenix supports application
listeners so that can be used to collect every block and make them all
available by name to each mailet. that, i like: it's a lot less work.

this approach runs into a few problems with lifecycle order - events
are generated after service and initialization but that's ok: the same
trick can be used to replace the avalon service and initialization
interfaces. the listener can then init everything once every service
has been loaded from the assembly.xml. for example

@Resource(name="filesystem")
public void setFileSystem(FileSystem fileSystem)

@PostConfig
public void init() {
...
}

could probably approach configuration in a somwhat similar fashion

supporting custom mailets using avalon-based lookups might be tricky, though...

i might copy spoolmanager module so that people can take a look at the
idea in code.

still considering how to integrate with OSGi and spring, though. maybe
more later...

opinions? etc

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] JSR250...?

[Robert Burrell Donkin <ro...@gmail.com>]

On 12/8/08, David Jencks <da...@yahoo.com> wrote:
>
> On Dec 8, 2008, at 10:52 AM, Stefano Bagnara wrote:
>
>> Robert Burrell Donkin ha scritto:
>>> my starting point was JSR 250 (Common Annotations for the Java
>>> Platform) which is used to control service injection in ejb3. i
>>> hadn't
>>> really studied in detail before but i took a better look and liked
>>> what i saw. they're lightweight and not too strongly coupled to the
>>> ejb model. it has the advantage of being a standard that plays well
>>> with other containers.
>>> [...]
>>> opinions? etc
>>
>> jsr250: it's a small java5 api jar. I don't know what containers
>> supports out of the box this api, today. A fast search didn't give me
>> results.
>
> javaee 5 compliant servers support this for ee components, such as
> ejb, servlet, jsp taglib beans, and jsf beans.  I sincerely doubt you
> will find anything supporting this for non-ee components, although
> it's possible spring has some support for this stuff in a non-ee
> context.

Yeh

Having played around with them a little the subset, what I like about
them is that they are a lightweight standard which can be used to
replace the invasive Avalon interfaces. More modern containers would
probably just use ignore them.

> geronimo and openejb use the (geronimo subproject) xbean libraries to
> implement support for this.  xbean does all the hard work for you but
> you need to write a bunch of code to call the xbean libraries and
> relate the annotations to the intende

sound good

> basically you need to  scan the code for annotations and track all of
> them and figure out what they are trying to refer to.  xbean-finder is
> good for this.
>
> Then whenever you create a managed object you need to deal with
> injecting the values for the annotated stuff.  xbean-reflect is good
> for this.

I'll take a look

The good news is that we only need to support @Resource and
@PostConstruct, and we can ignore most of the complex stuff since we
don't need it.

>
>>
>>
>> If no container supports it then it is a simple way to "mark"
>> dependency
>> injection (as an alternative to doclets / xml configurations /
>> enabling
>> interfaces / naming conventions), right?
>
> Marking stuff doesn't do you any good if there is no container
> supporting the markings.

My plan was to make Phoenix support them as a means of migrating away
from Avalon. They happen to do just what I needed.

> Spring is working towards (partly) becoming an osgi standard -- RFC 124

I think James needs to move to OSGi but I think we need a migration
path which allows the phoenix container to retained for a while. I
have some ideas now about running OSGi in Phoenix but I need to bypass
the Avalon lifecycle timing since I'm using a listener.

> If you really like annotations you might look at googles guice,
> although IIUC it has problems dealing with non-singleton components.

Oh well

Robert
>
> thanks
> david jencks
>
>>
>>
>>> the avalon service manager could be used but has the limitation that
>>> every resource has to be a block provided to James. this is the heart
>>> of my issues so i'd like to avoid this. phoenix supports application
>>> listeners so that can be used to collect every block and make them
>>> all
>>> available by name to each mailet. that, i like: it's a lot less work.
>>
>>> this approach runs into a few problems with lifecycle order - events
>>> are generated after service and initialization but that's ok: the
>>> same
>>> trick can be used to replace the avalon service and initialization
>>> interfaces. the listener can then init everything once every service
>>> has been loaded from the assembly.xml. for example
>>
>>
>> I guess your always talking of the *phoenix* service manager (avalon
>> service manager is simple and has not knowledge of "blocks").
>>
>> About phoenix application listeners, I never used it, but if you think
>> they can be used to build our own "dependency injecting spoolmanager"
>> let's see a POC! it seems interesting to gradually move away from
>> phoenix schemas.
>>
>> Stefano
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] JSR250...?

[David Jencks <da...@yahoo.com>]

On Dec 8, 2008, at 10:52 AM, Stefano Bagnara wrote:

> Robert Burrell Donkin ha scritto:
>> my starting point was JSR 250 (Common Annotations for the Java
>> Platform) which is used to control service injection in ejb3. i  
>> hadn't
>> really studied in detail before but i took a better look and liked
>> what i saw. they're lightweight and not too strongly coupled to the
>> ejb model. it has the advantage of being a standard that plays well
>> with other containers.
>> [...]
>> opinions? etc
>
> jsr250: it's a small java5 api jar. I don't know what containers
> supports out of the box this api, today. A fast search didn't give me
> results.

javaee 5 compliant servers support this for ee components, such as  
ejb, servlet, jsp taglib beans, and jsf beans.  I sincerely doubt you  
will find anything supporting this for non-ee components, although  
it's possible spring has some support for this stuff in a non-ee  
context.

geronimo and openejb use the (geronimo subproject) xbean libraries to  
implement support for this.  xbean does all the hard work for you but  
you need to write a bunch of code to call the xbean libraries and  
relate the annotations to the intended targets.

basically you need to  scan the code for annotations and track all of  
them and figure out what they are trying to refer to.  xbean-finder is  
good for this.

Then whenever you create a managed object you need to deal with  
injecting the values for the annotated stuff.  xbean-reflect is good  
for this.

>
>
> If no container supports it then it is a simple way to "mark"  
> dependency
> injection (as an alternative to doclets / xml configurations /  
> enabling
> interfaces / naming conventions), right?

Marking stuff doesn't do you any good if there is no container  
supporting the markings.

Spring is working towards (partly) becoming an osgi standard -- RFC 124

If you really like annotations you might look at googles guice,  
although IIUC it has problems dealing with non-singleton components.

thanks
david jencks

>
>
>> the avalon service manager could be used but has the limitation that
>> every resource has to be a block provided to James. this is the heart
>> of my issues so i'd like to avoid this. phoenix supports application
>> listeners so that can be used to collect every block and make them  
>> all
>> available by name to each mailet. that, i like: it's a lot less work.
>
>> this approach runs into a few problems with lifecycle order - events
>> are generated after service and initialization but that's ok: the  
>> same
>> trick can be used to replace the avalon service and initialization
>> interfaces. the listener can then init everything once every service
>> has been loaded from the assembly.xml. for example
>
>
> I guess your always talking of the *phoenix* service manager (avalon
> service manager is simple and has not knowledge of "blocks").
>
> About phoenix application listeners, I never used it, but if you think
> they can be used to build our own "dependency injecting spoolmanager"
> let's see a POC! it seems interesting to gradually move away from
> phoenix schemas.
>
> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: [server] JSR250...?

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> my starting point was JSR 250 (Common Annotations for the Java
> Platform) which is used to control service injection in ejb3. i hadn't
> really studied in detail before but i took a better look and liked
> what i saw. they're lightweight and not too strongly coupled to the
> ejb model. it has the advantage of being a standard that plays well
> with other containers.
> [...]
> opinions? etc

jsr250: it's a small java5 api jar. I don't know what containers
supports out of the box this api, today. A fast search didn't give me
results.

If no container supports it then it is a simple way to "mark" dependency
injection (as an alternative to doclets / xml configurations / enabling
interfaces / naming conventions), right?

> the avalon service manager could be used but has the limitation that
> every resource has to be a block provided to James. this is the heart
> of my issues so i'd like to avoid this. phoenix supports application
> listeners so that can be used to collect every block and make them all
> available by name to each mailet. that, i like: it's a lot less work.

> this approach runs into a few problems with lifecycle order - events
> are generated after service and initialization but that's ok: the same
> trick can be used to replace the avalon service and initialization
> interfaces. the listener can then init everything once every service
> has been loaded from the assembly.xml. for example


I guess your always talking of the *phoenix* service manager (avalon
service manager is simple and has not knowledge of "blocks").

About phoenix application listeners, I never used it, but if you think
they can be used to build our own "dependency injecting spoolmanager"
let's see a POC! it seems interesting to gradually move away from
phoenix schemas.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org