On Jun 16, 2008, at 3:45 AM, Stefano Bagnara wrote:
David Jencks ha scritto:
I've been hoping for a Geronimo-JAMES integration since the start
of the Geronimo project. Two fairly recent developments in JAMES
have now made this a relatively simple task: the maven build and
the spring integration code.
[...]
Instructions:
1. Apply patches for JAMES-840, 841, and 842 to james trunk. Get
all the jars needed for the build into the private stage repository
(JAMES-840). (I realize these instructions are unclear but they
are the best I have at the moment)
I really hope we can tweak them and apply all of them. I commented
each issue on JIRA.
2. Build JAMES with maven
mvn clean install -Plocal
If the maven build is not acceptable to our PMC another approach
could be to add a maven repository install script to the ant build.
Of course I would prefer if our PMC accept that people may prefer
maven to build our products.
3. Build geronimo trunk (I haven't checked to see if sufficiently
up to date geronimo snapshots are available. We also have some
private repo issues that may make at least one local build of
geronimo necessary).
Interesting.
4. check out
svn co https://svn.apache.org/repos/asf/geronimo/plugins/james/trunk
I see there are 3 modules for that project:
geronimo-james/
james/
james-server/
can you explain (I don't know anything about "car" module type) ?
geronimo-james has the java integration code
james builds a geronimo plugin, using that code. When you build it
it's installed in your local geronimo plugin repository (i.e. the
local maven repo + listed in a geronimo metadata file). At this point
it's available to the geronimo plugin system, so you can add it to an
existing server using the admin console or command line tools. or...
james-server is a minimal server assembly that has the geroniimo
kernel, a bit of other supporting stuff, and the james plugin.
Is there anything you think should be moved to james project instead
of geronimo?
It would be great if the james project wanted to take over this
plugin, but I think we should make sure it works and is stable and
doesn't have too many issues with deploying on different geronimo
versions first.
5. build james plugin
mvn clean install -Pwith-assembly
6. Fire up the sample server
cd james-server/target
tar xzf james-server-1.0-SNAPSHOT-bin.tar.gz
./james-server-1.0-SNAPSHOT/bin/gsh geronimo/start-server
I've put the james config files in a geronimo-standard location of
var/james/config. I changed the ports so the server would start
without superuser permissions. So far I just know the server
starts without errors: I haven't figure out how to test if it can
actually do anything.
Cool!
It looks like really simple!
-----------------------------------
Future directions
Even in its current state this plugin/integration is only viable if
the JAMES community
- works to resolve the issues noted in JAMES-840, 841, 842
- continues to maintain the maven build
+1
Currently there is minimal integration between geronimo and
JAMES. One really obvious integration point would be to use
geroniimo supplied datasources. However glancing at the code there
appears to be a certain amount of fishing for configuration rather
than dependency injection. I'm wondering whether there is any
interest in moving to JPA based database access, and whether this
would be significantly harder than just changing the datasource
source. Obviously this would imply moving JAMES to java 5.
+1
Moving to java 5 IMHO is no more an issue: as soon as a feature will
require java 5 we should simply stop declaring 1.4 compatibility: I
don't know anyone using an 1.4 jvm at this point.
Another issue I came across is use of com.sun mail classes (I
started by trying to use the geronimo mail provider before I
understood why the stage repo wasn't working for me). Is this
intentional? Are you interested in also supporting the geronimo
mail implementation?
It is intentional. Last time I checked it geronimo mail
implementation was not enough for our delivery needs. There is a lot
to change and we would probably stop using javamail at all, instead
of supporting geronimo implementation for the remote delivery task.
This is only my opinion, of course.
When did you look :-) ? I think its had a lot of bugs fixed and a lot
more stuff implemented but I haven't followed it closely.
Finally I came across some comments that DNS is needed (as you can
probably tell I know almost nothing about mail). I wondered if any
thought had been given to using apacheds in-vm for this.
We don't need a DNS server, just DNS lookup capabilities. We don't
use the JVM built-in DNS lookup mechanism because of issues in the
caching and expiration support. apacheds does not provide a dns
client library.
At the moment the geronimo-james integration is simply a single
gbean for the whole james application: do you think it would be hard
to support 1 gbean per function? JAMES is composed by api modules,
library modules and function modules. functions only depends on
libraries and api, libraries only on apis, and api have no internal
dependencies.
deployments simply aggregate functions. Is it possible to create
separate GBean for functions only when functions depends on shared
services or the only solution is to publish 1 gbean for each of our
services? I don't know geronimo, but it would be a great deployment
alternative if it allow us to undeploy 1 single function (e.g: the
spoolmanager), alter its configuration and redeploy it without
stopping the smtp/pop3 servers.
This was the original idea I had when I first looked into this
integration several years ago. However I don't think it will be
practical until James adopts a more conventional IOC approach in which
the components have their properties configured by the IOC container
rather than through a initialize(configuration) method. I could have
seriously misjudged the situation however.
I have basically no idea of the internal threading structure of
James. Is adding and removing components reasonably possible to do in
a thread-safe way without a large synchronization overhead?
thanks
david jencks
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
