It is so hard today there are so many standards/libraries for the same
thing ( see about java logging) , everything has advantages was the
other not has and vice versa. You are right, the ideal way is it to
implement james osgi support based on blueprint because it is a
standard, but the ideal way is not ever the way which was gone ( the old
example VHS and VIDEO2000 ). At now i am not familiar with blueprint,
but i don't want ignore this good standard, i try to do my best to find
a solution. I will you inform about my steps of implementing.
Thanks
Martin
Am 27.02.2010 21:42, schrieb David Jencks:
On Feb 27, 2010, at 12:02 PM, Martin Reisenhofer wrote:
Dear David,
blueprint is similar to spring-dm, and also supported by the
spring-dm server. But spring configuration for now has more features
than blueprint. Why do you prefer blueprint instead of spring-dm?
Blueprint is a standard and gives you a choice of platfoms to run on,
such as apache aries. I'm not familiar with the features in spring-dm
that are missing from blueprint: if they aren't too important for
james, I think using the standard would be worthwhile.
From another point of view, my understanding is that Spring positioned
blueprint as the better, standardized version of spring-dm. If it
isn't, better to find out now and start trying to fix the blueprint spec.
thanks
david jencks
thanks
Martin
I watched out now the blueprint. The first i see,
I am also agree that xbean-bluepring is great, but the are
David Jencks wrote:
I still think that if you are going to go to the work of making
james run well under osgi then it is worth the small additional work
of using blueprint instead of spring-dm so as to not be tied to a
proprietary api. I got activemq running under xbean-blueprint and
it basically consisted of removing some unneeded use of obsolete
spring lifecycle interfaces from a few classes and making sure the
spring-isms needed for startup in spring were in a few classes not
needed in blueprint. Translating a plan from spring to blueprint is
pretty easy, there are basically just a few element name changes.
I think xbean-blueprint is great but I know not everyone agrees and
it is certainly experimental at this point.
thanks
david jencks
On Feb 27, 2010, at 10:33 AM, Norman Maurer wrote:
Hi David,
we are talkin about spring-dm (the modules) not the spring-dm-server.
I just think using spring-dm is the easiest way cause we already use
spring for DI.
Bye,
Norman
2010/2/27 David Jencks <[email protected]>:
I'd suggest using blueprint rather than spring-dm as it is a
standard.
If you want to poke into experimental territory you could try
xbean-blueprint which, although it currently only works with aries'
blueprint implementation lets you use a schema adapted to the
beans for
configuration.
thanks
david jencks
On Feb 27, 2010, at 9:21 AM, Martin Reisenhofer wrote:
Dear Norman,
Thanks for the answer, i have cycles to integrate james with
spring-dm,
after i finished i publish the sources.
Best Regards
Martin
Norman Maurer wrote:
Hi Martin,
we using spring as container in current trunk. (development
version).
I would love to see some osgi deployment too (using spring-dm) but
noone had the cycles yet to implement it. Contributions are
welcome of
course :)
Bye,
Norman
2010/2/27 Martin Reisenhofer <[email protected]>:
Dear James development Team,
there are plans to makes james based on spring and osgi in future?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
