Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: domain of rickmcg@gmail.com designates
 74.125.44.30 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=HY+fudNwFvstMv7NYL9mY2fh6+Rmzb2qpK//cXh81PekTJF9Hpj3qVR8q4EOeQIuXI
         /wVAWKwPrBw7u3gt6pc7KPozGXMP01GxfMZlILn7+xnIghww3PvkUifJJmKWzEkzHCo3
         QnVDUGN/V4qHnUoDUD1txhpjvXcoqgL8qtJwQ=
Message-ID: <4856A96A.4010806@gmail.com>
Date: Mon, 16 Jun 2008 13:56:58 -0400
From: Rick McGuire <rickmcg@gmail.com>
Reply-To: rickmcg@gmail.com
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Geronimo-JAMES integration
References: <883C57DD-78F2-4950-894D-64036E853EC2@yahoo.com>
 <9071978.1367771213613148198.JavaMail.root@elysia.void.it>
In-Reply-To: <9071978.1367771213613148198.JavaMail.root@elysia.void.it>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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) ?
>
> Is there anything you think should be moved to james project instead 
> of geronimo?
>
>> 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 was the last time you checked?  The Geronimo javamail 
implementation has underdone quite a bit of upgrade over the last couple 
of years.  We now have support for POP3, IMAP, NNTP (Store and 
Transport).  We also take requests, if there are particular features 
missing.  It's difficult for us to add those when we don't even know 
people think there's something missing.

Rick


>
>> 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.
>
> Stefano
>
>