You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by David Woldrich <da...@woldrich.com> on 2007/02/01 09:46:21 UTC
James deployed as plugin on Geronimo!
Do I have your attention yet? :) I just installed ApacheDS, which is
the new Apache LDAP java server, in about 50 seconds as a plugin INSIDE
my Geronimo server using the deployer tool and a .car file I downloaded
from http://geronimoplugins.com. The mind boggling implications of this
new development are just too much for me to reckon properly right now.
EJB, JMS, and now LDAP all in one JavaVM! I have literally been
dreaming of this for years, and the ApacheDS install was so painless. I
am seeing the future. But, I'll be the first to admit it, I am greedy
and I want a lot more. I want mail and news servers in Geronimo too,
and I want mailets that can call local EJB's that I can redeploy at will
(or perhaps even make local EJB's that are themselves mailets.) Hot
redeployable mailets would be something nifty. Practically everything I
care about running with are apache projects, and maybe over time they
start converging on and sharing dependencies within the Geronimo
server. Total memory footprint goes down. Another big win for Apache.
I understand there are architectural thingies in James to consider and
phoenix and whatnot. I understand that there's a lot of time and
investment in the existing architecture. And I'm not suggesting that
James should not be able to run standalone, but I would like to be able
to optionally deploy James to Geronimo as a plugin. Has someone in the
know put any thoughts together on what it would take for this type of
deployment of James? What showstoppers are there?
Perhaps we can organize a "James Bug Day" some Saturday similar to what
the Parrot people are doing. Every month or so a bug day is organized
where anyone who's interested in Parrot can get together on an IRC
server and chat with the experts. I've personally taken todos off their
list, knowing nothing ahead of time about Parrot, and worked on code and
bugs with their help. Official committers on the project took my
patches, reviewed them, and committed them for me. If there was ever an
official James bug day, I would love to get involved, make some new
friends, and (especially) do some work towards the James-As-Plugin end...
Cheers,
Dave Woldrich
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> On 2/2/07, Danny Angus <da...@apache.org> wrote:
>> On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>>
>> > Unfortunately I think that hot redeployable mailets are far away,
>>
>> the biggest issue is that you would have to move all "in process"
>> messages to a save point that you know will allow them to continue
>> after you have changed the whole processing pipeline beyond
>> recognition. This means that it is probably never going to be possible
>> to have live config changes, but what we should look at is the ability
>> to restart the spoolmanager without blocking inbound traffic.
>
> i think that should be possible to do this with the SEDA without
> blocking inbound traffic:
>
> 1. put a task marked as no concurrency on the main worker task loop
> 2. this tasks will only be executed once all other tasks have completed
> 3. once scheduled, this performs the hot redeployment and recreation
> of the entire processing pipeline
> 4. once completed, subsequent tasks are free to execute
>
> of course, no processing of inbound traffic would be possible during
> this period, just decoding
>
> - robert
my 2 cents:
in current architecture no one depends on the spoolmanager. The
spoolmanager is a service that could be stopped at all and restarted or
added a new spoolmanager with different configuration on the fly.
This will not stop incoming traffic because this is all done via spool
queue that do not depend on the spoolmanager.
You can already do this by adding a component to stop/start the
spoolmanager and to reload it. Maybe phoenix provide something.
If the container allow you to dispose the spoolmanager component and
inject a new/updated spoolmanager then there are no limits on the james
side (for this specific issue).
If you look at the assembly.xml it will be more clear the dependency
tree and what can be stopped without stopping the application.
As an example you will see that no one depends on JamesSpoolManager and
only the SpoolManager depends on MatcherLoader and MailetLoader.
The key component is "James" (mailetcontext/mailserver): almost everyone
depend on this component and this cannot be redeployed without stopping
many places.
Hope this helps,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/2/07, Danny Angus <da...@apache.org> wrote:
> On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> > Unfortunately I think that hot redeployable mailets are far away,
>
> the biggest issue is that you would have to move all "in process"
> messages to a save point that you know will allow them to continue
> after you have changed the whole processing pipeline beyond
> recognition. This means that it is probably never going to be possible
> to have live config changes, but what we should look at is the ability
> to restart the spoolmanager without blocking inbound traffic.
i think that should be possible to do this with the SEDA without
blocking inbound traffic:
1. put a task marked as no concurrency on the main worker task loop
2. this tasks will only be executed once all other tasks have completed
3. once scheduled, this performs the hot redeployment and recreation
of the entire processing pipeline
4. once completed, subsequent tasks are free to execute
of course, no processing of inbound traffic would be possible during
this period, just decoding
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> Unfortunately I think that hot redeployable mailets are far away,
the biggest issue is that you would have to move all "in process"
messages to a save point that you know will allow them to continue
after you have changed the whole processing pipeline beyond
recognition. This means that it is probably never going to be possible
to have live config changes, but what we should look at is the ability
to restart the spoolmanager without blocking inbound traffic.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
> Hey Stefano,
> > Maybe this helps:
> > http://wiki.apache.org/james/Embedded
> > Maybe the spring integration stuff make it even simpler by skipping
> > phoenix at all.
> > I don't remember specific showstoppers, but feel free to submit them
> > if you try and find something.
> >
> I often hear Spring discussed in connection with J2EE, so that could be
> a good starting point. I will investigate. I think I don't know enough
> about James nor Geronimo to be able to make recommendations at this
> point, but as I learn more I will try to contribute.
> > I'm often in #james channel on FreeNode, but I suggest to post your
> > questions/proposals here.
> >
> > Stefano
> >
> Thanks for making yourself available!
>
> FYI, Robert, I found this informational little blurb on Geronimo
> Plugins. http://www.infoq.com/news/Inside-Look-Geronimo-Plugins
>
> The article talks about how JPA and ServiceMix (ESB) plugins are
> currently under development!
yeh - they're here at apache
<snip>
> Can you imagine deploying mailets deployed "as part of a J2EE
> application"??
definitely - just needs a volunteer to step up and take a lead :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Hey Stefano,
> Maybe this helps:
> http://wiki.apache.org/james/Embedded
> Maybe the spring integration stuff make it even simpler by skipping
> phoenix at all.
> I don't remember specific showstoppers, but feel free to submit them
> if you try and find something.
>
I often hear Spring discussed in connection with J2EE, so that could be
a good starting point. I will investigate. I think I don't know enough
about James nor Geronimo to be able to make recommendations at this
point, but as I learn more I will try to contribute.
> I'm often in #james channel on FreeNode, but I suggest to post your
> questions/proposals here.
>
> Stefano
>
Thanks for making yourself available!
FYI, Robert, I found this informational little blurb on Geronimo
Plugins. http://www.infoq.com/news/Inside-Look-Geronimo-Plugins
The article talks about how JPA and ServiceMix (ESB) plugins are
currently under development! The quartz scheduler plugin they've
already done looks especially interesting to me. I am starting quartz
in an adhoc manner now with my app (http://cardmeeting.com) and having
it deployed as a first-class doodad in Geronimo would be a much better
way to go if other systems are going to use quartz. They talk about how
quartz jobs could be deployed "as part of a J2EE application". Ok, now
we're cooking with gas!
Can you imagine deploying mailets deployed "as part of a J2EE
application"?? I mean, it sounds like they've got this whole Geronimo
thing planned out as a plugin ecosystem that apps can tap into. This is
going to be so much better than JBoss, oh my goodness.
Cheers,
Dave Woldrich
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
David Woldrich wrote:
> [...]
> EJB, JMS, and now LDAP all in one JavaVM! I have literally been
> dreaming of this for years, and the ApacheDS install was so painless. I
> am seeing the future. But, I'll be the first to admit it, I am greedy
> and I want a lot more. I want mail and news servers in Geronimo too,
> and I want mailets that can call local EJB's that I can redeploy at will
> (or perhaps even make local EJB's that are themselves mailets.) Hot
> redeployable mailets would be something nifty. Practically everything I
> care about running with are apache projects, and maybe over time they
> start converging on and sharing dependencies within the Geronimo
> server. Total memory footprint goes down. Another big win for Apache.
Unfortunately I think that hot redeployable mailets are far away, but
for embedding the full james people did it with JBoss, I'm sure it
should not be so difficult to do the same with Geronimo.
If this helps you can even try some of the spring-integration code that
have been committed in sandbox. It does provide a different entry point
that does not need phoenix (by providing some sort of spring-avalon
integration)
> I understand there are architectural thingies in James to consider and
> phoenix and whatnot. I understand that there's a lot of time and
> investment in the existing architecture. And I'm not suggesting that
> James should not be able to run standalone, but I would like to be able
> to optionally deploy James to Geronimo as a plugin. Has someone in the
> know put any thoughts together on what it would take for this type of
> deployment of James? What showstoppers are there?
Maybe this helps:
http://wiki.apache.org/james/Embedded
Maybe the spring integration stuff make it even simpler by skipping
phoenix at all.
I don't remember specific showstoppers, but feel free to submit them if
you try and find something.
> Perhaps we can organize a "James Bug Day" some Saturday similar to what
> the Parrot people are doing. Every month or so a bug day is organized
> where anyone who's interested in Parrot can get together on an IRC
> server and chat with the experts. I've personally taken todos off their
> list, knowing nothing ahead of time about Parrot, and worked on code and
> bugs with their help. Official committers on the project took my
> patches, reviewed them, and committed them for me. If there was ever an
> official James bug day, I would love to get involved, make some new
> friends, and (especially) do some work towards the James-As-Plugin end...
>
> Cheers,
> Dave Woldrich
I'm often in #james channel on FreeNode, but I suggest to post your
questions/proposals here.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
>> robert burrell donkin wrote:
>> > but just running probably isn't enough. probably want to be able to
>> > integrate other services and this is where things become a little more
>> > difficult. ATM the database implementation uses torque. you'd probably
>> > want to hack a alternative implementation using JPA POJOs for the data
>> > binding. maybe could talk to OpenJPA over in the incubator.
>>
>> Currenlty the database implementation is plain JDBC via
>> excalibur/cornerstone-datasource services.
>>
>> Torque is only currently used in trunk as an experimental mailbox
>> manager backend component.
>
> the spools and so on should be only of interest to james internally.
> so there should be no interoperability issues there. yes, mailet
> components in the container may want to be fed mail from the spool for
> processing and other components may want to post mail onto a spool to
> be processed but that should all be black box and so data sources
> would be fine.
>
> ISTM that the substantive issue is sharing mailboxes. in other words,
> allowing access to a mailbox (a collection of emails for example a
> user INBOX) from both james and other container based components. it
> would be possible to share objects at the data access level but
> perhaps it might be better to expose an interface to allow requests to
> be correct scheduled.
>
> - robert
I think I don't have understood your message, sorry. I add some more
information: hope this make sense.
What I wanted to explain was that torque is only used in an experimental
module of the trunk version of james. 2.3.0 does not include torque.
We have file or db implementations of the MailRepository and
SpoolRepository interfaces that are used to spool and store the messages
for later POP3 access.
The file implementation is done using cornerstone store object and its
stream/object file repositories. THe db implementation is custom james
code and uses direct JDBC code (JDBCMailRepository/JDBCSpoolRepository).
This is what we have in james now and what we released. (It was not an
opinion but a fact).
My opinion: the spools and the mail repositories are 2 core items, they
both deserve public interfaces. I proposed to remove the MailRepository
interface in favor of the MessageRepository many times but we delayed
the issue waiting for the first experiments on the IMAP storage stuff,
as we knew our current interfaces was not enough for IMAP, so we
preffered to first find something that worked with IMAP and then decide
what should have been part of the new MessageRepository object.
FWIW I already wrote avalon components that I deploy within james and
manage mailboxes and spools using the James apis (Store component,
MailRepository, SpoolRepository). Unfortunately withing phoenix we can't
export a service outside of the container.
If you use the spring integration code then you simply can use
context.getBean("store") and retrieve the needed
MailRepository/SpoolRepository from there.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin wrote:
> > but just running probably isn't enough. probably want to be able to
> > integrate other services and this is where things become a little more
> > difficult. ATM the database implementation uses torque. you'd probably
> > want to hack a alternative implementation using JPA POJOs for the data
> > binding. maybe could talk to OpenJPA over in the incubator.
>
> Currenlty the database implementation is plain JDBC via
> excalibur/cornerstone-datasource services.
>
> Torque is only currently used in trunk as an experimental mailbox
> manager backend component.
the spools and so on should be only of interest to james internally.
so there should be no interoperability issues there. yes, mailet
components in the container may want to be fed mail from the spool for
processing and other components may want to post mail onto a spool to
be processed but that should all be black box and so data sources
would be fine.
ISTM that the substantive issue is sharing mailboxes. in other words,
allowing access to a mailbox (a collection of emails for example a
user INBOX) from both james and other container based components. it
would be possible to share objects at the data access level but
perhaps it might be better to expose an interface to allow requests to
be correct scheduled.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> but just running probably isn't enough. probably want to be able to
> integrate other services and this is where things become a little more
> difficult. ATM the database implementation uses torque. you'd probably
> want to hack a alternative implementation using JPA POJOs for the data
> binding. maybe could talk to OpenJPA over in the incubator.
Currenlty the database implementation is plain JDBC via
excalibur/cornerstone-datasource services.
Torque is only currently used in trunk as an experimental mailbox
manager backend component.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
> Hi Robert,
> > <snip>
> >>
> >> and I want a lot more. I want mail and news servers in Geronimo too,
> >> and I want mailets that can call local EJB's that I can redeploy at will
> >> (or perhaps even make local EJB's that are themselves mailets.)
> >
> > mailets that are EJB sounds better than calling EJBs from mailets
> >
> > but POJOs with context sound even better (cool to mix in with service
> > buses etc) bit like activication specification message beans (mail is
> > just another message, after all)
> >
> Ah, I'm not sure what you are getting at here? "Service Bus" like an
> ESB? That would be nifty - they are great at shuttling messages about.
yeh
all a mailet does is process mail. mailets are similar structurally to
MDBs of the activation specification kind
> Ok, what about using JMS throughout James instead of going the ESB
> route?
from a mailet's perspective, it just wants mail messages. whether the
mail arrives through JMS, web service or SMPT should be the
intergrator's problem. ESBs thrive on this. no reason to unnecessarily
restrict to JMS.
> One useful thing about JMS is that it builds your threadpools
> implicitly. One other useful thing is JMS would allow you to modularize
> and distribute pieces of James into separate plugins and improve
> scalability.
we need full blown SEDA, JMS just isn't good enough
but it should be possible for an integrator to pipe JMS through to an
internal spool.
> If there isn't one already, making
> administration/configuration JMX or web consoles for James would be a
> nifty deal as well and being integrated with Geronimo would really spur
> that development.
AIUI james already has some JMX but it's in need of improvement
> I have to say one more thing about how well the ApacheDS integrated with
> Geronimo. The Geronimo deployer tool went out to ibiblio, downloaded
> dependencies, organized everything in the repository folder, AND started
> the ldap server before finishing! All of the custom LDAP database files
> were automagically created and are stored in the new geronimo/var/ldap
> folder. God, it's all so dang slick. I want my james folder under
> var!! :)
> >> Hot redeployable mailets would be something nifty.
> >
> > +1
> >
> > some sort of mailet packaging would be very cool (but i was saving
> > this subject for another day)
> Well, this is why I was suggesting EJB for that role and you wouldn't
> have to reinvent the redeployment plumbing. A mailet EJB could just
> implement some Mailet interface, and the James config could just take a
> JNDI name. At runtime, James could cache the home and create local or
> remote instances for invocation, and then cast to
> org.apache.james.Mailet for calling. Auto retry logic in getting the
> home could handle the redeployment scenarios when/if the cached home
> becomes stale. After the home creates them, Local EJB's are pretty much
> a pojo performance-wise if you disable EJB transactions and security.
> With the new annotations, they're a breeze to build in Eclipse too, I've
> been having a lot of fun with that.
IMHO mailets aren't really all that similar to session beans. they are
structurally similar to message driven beans which take a particular
kind of payload. they are very similar to activation specification
message beans.
probably more natural to integrate using the resource adapter specifications
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
Noel,
I'm in favour of a JCA deployment option because it would let people
embed mail functionality in J2EE applications making it available to
systems assembled from J2EE components.
The big win this would have would be that administrators wouldn't have
to get right out of their comfort zone, the email functionality could
be monitored and operated through the same administration toolsets
they currently use for managing their *other* J2EE applications.
The cost of ownership of James isn't all about through-put and
hardware, it is also about the cost of administering applications and
training, and retaining, specialist administrators. If James
installations could be administered by people with a commonly
available skills profile, and tools which are already in place, it
would be a real benefit.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
>
> > > It might make sense to revisit some of it using JCA, but we have very
> > > specific needs, and an overly general approach of reusing JEE is not
> likely
> > > to give us the performance that we need.
>
> > the use case i was thinking about was a JEE application requiring deep
> > email integration
>
> You need to elaborate.
example use case: application wants to creates emails which clients
will download through POP3 (say). ATM this requires out-of-container
interactions to a separate email server. running JAMES in-container
would allow messages to be fed directly to JAMES without needing to
run SMTP.
> > running james in container using JCA for integration with the JEE
> > application should be more performant than the application using
> > existing protocols to communicate via sockets. it would also be more
> > flexible.
>
> More performant for what? For the JEE app, or for the mainstream JAMES
> server which needs to get faster, not slower.
JEE application
in the above example, the JEE application would create an email
message and then push it into a connector. the bus would route this to
an appropriate JAMES processing spool. these would then be served over
POP3 by the existing JAMES code.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: James deployed as plugin on Geronimo!
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> > It might make sense to revisit some of it using JCA, but we have very
> > specific needs, and an overly general approach of reusing JEE is not
likely
> > to give us the performance that we need.
> the use case i was thinking about was a JEE application requiring deep
> email integration
You need to elaborate.
> running james in container using JCA for integration with the JEE
> application should be more performant than the application using
> existing protocols to communicate via sockets. it would also be more
> flexible.
More performant for what? For the JEE app, or for the mainstream JAMES
server which needs to get faster, not slower.
> for james, JCA would just be another protocol to support
Not quite. For one thing, JCA isn't a protocol. But your goal is
comparable.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 3/10/07, Noel J. Bergman <no...@devtech.com> wrote:
> robert burrell donkin wrote:
>
> > for connectivity to the JAMES service, this is where i think that
> > service bus and JCA ideas are powerful. rather than thinking about
> > an EJB, multiple transport mechanisms would be powerful: EJB, WS,
> > JMS, JCA and so on. adopting a bus might give a lot of benefits
> > for very little effort.
>
> It might make sense to revisit some of it using JCA, but we have very
> specific needs, and an overly general approach of reusing JEE is not likely
> to give us the performance that we need.
the use case i was thinking about was a JEE application requiring deep
email integration
running james in container using JCA for integration with the JEE
application should be more performant than the application using
existing protocols to communicate via sockets. it would also be more
flexible.
for james, JCA would just be another protocol to support
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Bernd Fondermann <be...@googlemail.com>.
On 2/15/07, robert burrell donkin <ro...@gmail.com> wrote:
> On 2/15/07, David Woldrich <da...@woldrich.com> wrote:
> > Robert,
> >
> > Ok, fair enough. Well, honestly for starters, I would love to deploy
> > James as a monolithic Enterprise App or Web App if we could work out the
> > lifecycle issues (meaning System.exit() isn't the only way to achieve
> > orderly server shutdown.) It's been awhile since I looked deep enough
> > at that code to say whether that problem has already been solved or
> > not. So, if I could get that, it would totally solve my short term
> > itch. If you think that that's a rabbit hole not worth diving into, I
> > will trust your judgement. But, if it is, I'd like to tackle that first
> > and get it overwith.
>
> i really think that the best approach would be to deploy JAMES as a
> service available to enterprise applications rather than as an
> enterprise application. so, i prefer the idea of deployment as a
> plugin but i'm not a geronimo guru. i think that the first step should
> be to ask the geronimo team whether this would be the best approach.
> this probably means posting something appropriate to the dev list.
All Geronimo-deployed objects are wrapped as GBeans, so G. can handle
the object lifecycle, inter-dependencies and all that. For a native
integration with G. we would need to hack some sort of GBean wrapper
around James. Maybe a look at how other G.-integrations have been done
(for example Tomcat) may give an idea how this could be done.
http://cwiki.apache.org/GMOxKB/what-on-earth-is-a-gbean-why-are-they-different-from-mbeans.html
G. also has some sort of integration with Spring. Maybe this is a way
to go without GBeans, but I never looked more deeply into this.
http://cwiki.apache.org/GMOxDOC10/spring.html
>
> for connectivity to the JAMES service, this is where i think that
> service bus and JCA ideas are powerful. rather than thinking about an
> EJB, multiple transport mechanisms would be powerful: EJB, WS, JMS,
> JCA and so on. adopting a bus might give a lot of benefits for very
> little effort.
JCA would be the standardized way to deploy any kind of service which
is not an enterprise application (EAR) or web application (WAR) into
any J2EE server.
For this, you would also need to detach James' components from the
current container and boot the whole James component ecosystem
independent from the container. To me this seems more complicated than
"simply" deploying components in a Geronimo-dependent way.
I am very excited to see any sort of integration :-) . It's a pitty I
cannot get my hands dirty with that, currently, because lack of time
:-(
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: James deployed as plugin on Geronimo!
Posted by "Noel J. Bergman" <no...@devtech.com>.
robert burrell donkin wrote:
> for connectivity to the JAMES service, this is where i think that
> service bus and JCA ideas are powerful. rather than thinking about
> an EJB, multiple transport mechanisms would be powerful: EJB, WS,
> JMS, JCA and so on. adopting a bus might give a lot of benefits
> for very little effort.
It might make sense to revisit some of it using JCA, but we have very
specific needs, and an overly general approach of reusing JEE is not likely
to give us the performance that we need.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/15/07, David Woldrich <da...@woldrich.com> wrote:
> Robert,
>
> Ok, fair enough. Well, honestly for starters, I would love to deploy
> James as a monolithic Enterprise App or Web App if we could work out the
> lifecycle issues (meaning System.exit() isn't the only way to achieve
> orderly server shutdown.) It's been awhile since I looked deep enough
> at that code to say whether that problem has already been solved or
> not. So, if I could get that, it would totally solve my short term
> itch. If you think that that's a rabbit hole not worth diving into, I
> will trust your judgement. But, if it is, I'd like to tackle that first
> and get it overwith.
i really think that the best approach would be to deploy JAMES as a
service available to enterprise applications rather than as an
enterprise application. so, i prefer the idea of deployment as a
plugin but i'm not a geronimo guru. i think that the first step should
be to ask the geronimo team whether this would be the best approach.
this probably means posting something appropriate to the dev list.
for connectivity to the JAMES service, this is where i think that
service bus and JCA ideas are powerful. rather than thinking about an
EJB, multiple transport mechanisms would be powerful: EJB, WS, JMS,
JCA and so on. adopting a bus might give a lot of benefits for very
little effort.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/15/07, Danny Angus <da...@apache.org> wrote:
> On 2/15/07, David Woldrich <da...@woldrich.com> wrote:
>
> > Past that, it sounds like from past conversations that the deployment of
> > James as a Geronimo plugin might be made more worthwhile if we did the
> > refactoring to make multiple independent sub-systems out of what is
> > currently in James.
>
> +1 I think if we do this then we'll get the deployment options as a
> beneficial side-effect.
> If we go straight for deployment options we may end up dividing at the
> wrong points of inflexion or inadvertently coding round specific
> deployment issues within the bits and bobs.
+1
> > Perhaps I could take each sub-system at a time and
> > try to get it to deploy as a plugin?
>
> Sounds like a plan.
+1
we don't need to complete the modularisation, just modularise the
subsystem to be deployed on geronimo. if you have a few cycles this
weekend then maybe you could help pull out a suitable subsystem.
opinions on the best subsystem to choose?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/15/07, David Woldrich <da...@woldrich.com> wrote:
> Past that, it sounds like from past conversations that the deployment of
> James as a Geronimo plugin might be made more worthwhile if we did the
> refactoring to make multiple independent sub-systems out of what is
> currently in James.
+1 I think if we do this then we'll get the deployment options as a
beneficial side-effect.
If we go straight for deployment options we may end up dividing at the
wrong points of inflexion or inadvertently coding round specific
deployment issues within the bits and bobs.
> Perhaps I could take each sub-system at a time and
> try to get it to deploy as a plugin?
Sounds like a plan.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Robert,
Ok, fair enough. Well, honestly for starters, I would love to deploy
James as a monolithic Enterprise App or Web App if we could work out the
lifecycle issues (meaning System.exit() isn't the only way to achieve
orderly server shutdown.) It's been awhile since I looked deep enough
at that code to say whether that problem has already been solved or
not. So, if I could get that, it would totally solve my short term
itch. If you think that that's a rabbit hole not worth diving into, I
will trust your judgement. But, if it is, I'd like to tackle that first
and get it overwith.
Past that, it sounds like from past conversations that the deployment of
James as a Geronimo plugin might be made more worthwhile if we did the
refactoring to make multiple independent sub-systems out of what is
currently in James. Perhaps I could take each sub-system at a time and
try to get it to deploy as a plugin?
Cheers,
Dave
robert burrell donkin wrote:
> On 2/14/07, David Woldrich <da...@woldrich.com> wrote:
>> Hey Robert,
>>
>> I'm still here! ALRIGHT! Let's do this. Give me some tasks or
>> guidance and I will see what I can get done for you.
>
> i'm going to throw this back at you: what's your itch?
>
> i think that there are two broad parts to this question: running JAMES
> within Geronimo and integration JAMES with enterprise systems. pick a
> place to start :-)
>
>> My free time is
>> mostly on the weekends, so I'll try to batch up my questions for the
>> list on friday so that I am most productive.
>
> sounds good
>
> - robert
>
> ---------------------------------------------------------------------
> 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: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/14/07, David Woldrich <da...@woldrich.com> wrote:
> Hey Robert,
>
> I'm still here! ALRIGHT! Let's do this. Give me some tasks or
> guidance and I will see what I can get done for you.
i'm going to throw this back at you: what's your itch?
i think that there are two broad parts to this question: running JAMES
within Geronimo and integration JAMES with enterprise systems. pick a
place to start :-)
> My free time is
> mostly on the weekends, so I'll try to batch up my questions for the
> list on friday so that I am most productive.
sounds good
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Hey Robert,
I'm still here! ALRIGHT! Let's do this. Give me some tasks or
guidance and I will see what I can get done for you. My free time is
mostly on the weekends, so I'll try to batch up my questions for the
list on friday so that I am most productive.
Cheers,
Dave
robert burrell donkin wrote:
> On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
>> Hi Robert,
>> > <snip>
>> >>
>> >> and I want a lot more. I want mail and news servers in Geronimo too,
>> >> and I want mailets that can call local EJB's that I can redeploy
>> at will
>> >> (or perhaps even make local EJB's that are themselves mailets.)
>> >
>> > mailets that are EJB sounds better than calling EJBs from mailets
>> >
>> > but POJOs with context sound even better (cool to mix in with service
>> > buses etc) bit like activication specification message beans (mail is
>> > just another message, after all)
>> >
>> Ah, I'm not sure what you are getting at here? "Service Bus" like an
>> ESB? That would be nifty - they are great at shuttling messages about.
>> Ok, what about using JMS throughout James instead of going the ESB
>> route? One useful thing about JMS is that it builds your threadpools
>> implicitly. One other useful thing is JMS would allow you to modularize
>> and distribute pieces of James into separate plugins and improve
>> scalability. If there isn't one already, making
>> administration/configuration JMX or web consoles for James would be a
>> nifty deal as well and being integrated with Geronimo would really spur
>> that development.
>
> still around dave?
>
> we've now made a start on the modularization and i've had time to
> think about this
>
> there is some really stuff which would be done in this area. not sure
> whether i'll find the cycles to hack it myself right now if you're
> still around and interested, maybe we could work together.
>
> WDYS?
>
> - robert
>
> ---------------------------------------------------------------------
> 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: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
> Hi Robert,
> > <snip>
> >>
> >> and I want a lot more. I want mail and news servers in Geronimo too,
> >> and I want mailets that can call local EJB's that I can redeploy at will
> >> (or perhaps even make local EJB's that are themselves mailets.)
> >
> > mailets that are EJB sounds better than calling EJBs from mailets
> >
> > but POJOs with context sound even better (cool to mix in with service
> > buses etc) bit like activication specification message beans (mail is
> > just another message, after all)
> >
> Ah, I'm not sure what you are getting at here? "Service Bus" like an
> ESB? That would be nifty - they are great at shuttling messages about.
> Ok, what about using JMS throughout James instead of going the ESB
> route? One useful thing about JMS is that it builds your threadpools
> implicitly. One other useful thing is JMS would allow you to modularize
> and distribute pieces of James into separate plugins and improve
> scalability. If there isn't one already, making
> administration/configuration JMX or web consoles for James would be a
> nifty deal as well and being integrated with Geronimo would really spur
> that development.
still around dave?
we've now made a start on the modularization and i've had time to
think about this
there is some really stuff which would be done in this area. not sure
whether i'll find the cycles to hack it myself right now if you're
still around and interested, maybe we could work together.
WDYS?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Hi Robert,
> <snip>
>>
>> and I want a lot more. I want mail and news servers in Geronimo too,
>> and I want mailets that can call local EJB's that I can redeploy at will
>> (or perhaps even make local EJB's that are themselves mailets.)
>
> mailets that are EJB sounds better than calling EJBs from mailets
>
> but POJOs with context sound even better (cool to mix in with service
> buses etc) bit like activication specification message beans (mail is
> just another message, after all)
>
Ah, I'm not sure what you are getting at here? "Service Bus" like an
ESB? That would be nifty - they are great at shuttling messages about.
Ok, what about using JMS throughout James instead of going the ESB
route? One useful thing about JMS is that it builds your threadpools
implicitly. One other useful thing is JMS would allow you to modularize
and distribute pieces of James into separate plugins and improve
scalability. If there isn't one already, making
administration/configuration JMX or web consoles for James would be a
nifty deal as well and being integrated with Geronimo would really spur
that development.
I have to say one more thing about how well the ApacheDS integrated with
Geronimo. The Geronimo deployer tool went out to ibiblio, downloaded
dependencies, organized everything in the repository folder, AND started
the ldap server before finishing! All of the custom LDAP database files
were automagically created and are stored in the new geronimo/var/ldap
folder. God, it's all so dang slick. I want my james folder under
var!! :)
>> Hot redeployable mailets would be something nifty.
>
> +1
>
> some sort of mailet packaging would be very cool (but i was saving
> this subject for another day)
Well, this is why I was suggesting EJB for that role and you wouldn't
have to reinvent the redeployment plumbing. A mailet EJB could just
implement some Mailet interface, and the James config could just take a
JNDI name. At runtime, James could cache the home and create local or
remote instances for invocation, and then cast to
org.apache.james.Mailet for calling. Auto retry logic in getting the
home could handle the redeployment scenarios when/if the cached home
becomes stale. After the home creates them, Local EJB's are pretty much
a pojo performance-wise if you disable EJB transactions and security.
With the new annotations, they're a breeze to build in Eclipse too, I've
been having a lot of fun with that.
> <snip>
>> to optionally deploy James to Geronimo as a plugin. Has someone in the
>> know put any thoughts together on what it would take for this type of
>> deployment of James? What showstoppers are there?
>
> not sure there are really architectural issues with the container: the
> advantage of using an IoC container such as pheonix is that it's
> relatively easy to adapt to new envionments.
>
> but just running probably isn't enough. probably want to be able to
> integrate other services and this is where things become a little more
> difficult. ATM the database implementation uses torque. you'd probably
> want to hack a alternative implementation using JPA POJOs for the data
> binding. maybe could talk to OpenJPA over in the incubator.
>
> may need to think about threading and thread pooling
>
JMS is one way, like I was saying. Any ESB would implicitly thread pool
for you as well, I assume. I knew nothing about OpenJPA before your
response here. I went and looked at the spec and came away wondering.
What is the data binding you're discussing used for? Persisting
messages to the file system?
On a separate but related topic, I don't yet understand the whole GBean
thing and plugins and how the repository folder system works in
Geronimo. But, it seems to me like Maven and Geronimo have similar
repository schemes, I almost feel like Geronimo could be a target for
Maven builds. If that's the case, perhaps someone has already done our
torque embedding work for us? I found this...
http://mvnrepository.com/artifact/org.apache.db.torque/torque-maven-plugin/3.3-RC1
<snip>
>> bugs with their help. Official committers on the project took my
>> patches, reviewed them, and committed them for me. If there was ever an
>> official James bug day, I would love to get involved, make some new
>> friends, and (especially) do some work towards the James-As-Plugin
>> end...
>
> we'll review patches whether it's a bug day or not ;-)
>
> plan on being at the hackathon at apacheconEU?
>
hee hee, well, the Parrot Bug Day format worked well for me because I
could schedule my time around it, and it happens often enough that I
feel like I can actually achieve something significant with the help of
the experts guiding me. (And in Parrot, there are only a few experts,
so it's good to get them all online chatting and thinking through issues
and helping newbs like me with enhancements they have planned.) At the
Parrot bug day, they keep a wiki updated with people's progress and
projects, it's fun to watch it change throughout the day.
I've thought about going to an apachecon before, I'm in the states, so
an EU apachecon won't work for me unless I make a European backpacking
trip out of it. :) Hackathons sound like just what I am looking for,
do I need to be there in person to participate in one? If you do one
specifically for James, please announce it on both the list and solicit
us moochers, erm, I mean USERS for help! :)
Thanks,
Dave Woldrich
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
> Do I have your attention yet? :)
you have mine
i'm not an expert but i'll try an initial response
> I just installed ApacheDS, which is
> the new Apache LDAP java server, in about 50 seconds as a plugin INSIDE
> my Geronimo server using the deployer tool and a .car file I downloaded
> from http://geronimoplugins.com. The mind boggling implications of this
> new development are just too much for me to reckon properly right now.
>
> EJB, JMS, and now LDAP all in one JavaVM! I have literally been
> dreaming of this for years, and the ApacheDS install was so painless. I
> am seeing the future. But, I'll be the first to admit it, I am greedy
> and I want a lot more. I want mail and news servers in Geronimo too,
> and I want mailets that can call local EJB's that I can redeploy at will
> (or perhaps even make local EJB's that are themselves mailets.)
mailets that are EJB sounds better than calling EJBs from mailets
but POJOs with context sound even better (cool to mix in with service
buses etc) bit like activication specification message beans (mail is
just another message, after all)
> Hot redeployable mailets would be something nifty.
+1
some sort of mailet packaging would be very cool (but i was saving
this subject for another day)
> Practically everything I
> care about running with are apache projects, and maybe over time they
> start converging on and sharing dependencies within the Geronimo
> server. Total memory footprint goes down. Another big win for Apache.
>
> I understand there are architectural thingies in James to consider and
> phoenix and whatnot. I understand that there's a lot of time and
> investment in the existing architecture. And I'm not suggesting that
> James should not be able to run standalone, but I would like to be able
> to optionally deploy James to Geronimo as a plugin. Has someone in the
> know put any thoughts together on what it would take for this type of
> deployment of James? What showstoppers are there?
not sure there are really architectural issues with the container: the
advantage of using an IoC container such as pheonix is that it's
relatively easy to adapt to new envionments.
but just running probably isn't enough. probably want to be able to
integrate other services and this is where things become a little more
difficult. ATM the database implementation uses torque. you'd probably
want to hack a alternative implementation using JPA POJOs for the data
binding. maybe could talk to OpenJPA over in the incubator.
may need to think about threading and thread pooling
> Perhaps we can organize a "James Bug Day" some Saturday similar to what
> the Parrot people are doing. Every month or so a bug day is organized
> where anyone who's interested in Parrot can get together on an IRC
> server and chat with the experts. I've personally taken todos off their
> list, knowing nothing ahead of time about Parrot, and worked on code and
> bugs with their help. Official committers on the project took my
> patches, reviewed them, and committed them for me. If there was ever an
> official James bug day, I would love to get involved, make some new
> friends, and (especially) do some work towards the James-As-Plugin end...
we'll review patches whether it's a bug day or not ;-)
plan on being at the hackathon at apacheconEU?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> On 2/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>> I prefer maven2 for modular builds. Imho make things more clear.
>>
>> On the other side I think that who *does* stuff have a special choice on
>> how to do this, so I'm +1 *if* you'll take care of this.
>
> a reorganisation along these lines would be build system agnostic: the
> standard modules would be laid out using the standard jakarta
> conventions upon which maven was based, the deployment module(s) would
> use the current trunk layout.
I fully agree! And this explain my +1 ;-)
>> (I'm not +1, but -0, on a general choice for ant based multi-module
>> build system: I still prefer maven2, expecially for a multi-module build)
>
> IMO it's best to separate choice of build system from modularization.
> ant 1.7 is good at multi module builds and so is maven 2 (early
> versions of both systems had their flaws). the module code should not
> need major reorganisation to switch from ant to maven but ant would
> still be the primary build system for james.
>
> - robert
I agree that build system choice is a religious issue, like many other
technology choices. I don't know ant 1.7, so looking at your work I will
also learn something new. And if I won't like at all the ant stuff
(unlikely) be sure I will make a concrete proposal for maven2 ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> robert burrell donkin wrote:
> > with the need to modularise, i think that there's now more convergence
> > towards this
> >
> > given a little initial restructuring (moving code around), it should
> > be possible to gradually move code out from the pheonix deployment
> > module into separate modules.
> >
> > phase 1: make space for modules within james server trunk
> > * server/trunk -> server/trunk/pheonix
> >
> > phase 2: top level build
> > * create build.xml which delegates to pheonix/build.xml
> >
> > phase 3: upgrade build:
> > * upgrade to ant 1.7 (the new features are *really* good)
> > * create stage subdirectory which is local only
> > * create buildtasks module to host build macros and ant tasks for
> > module builds
> >
> > phase 3: create empty base module top to contain API interfaces
> > * create macros and tasks to support modular build
> > * create build-modules.xml to support common structure
> > * base builds copies artifacts into stage subdirectory
> > * pheonix build copies artifacts locally from stage
> > * create macros to allow easy generation of new modules
> >
> > once this has been done, we can gradually pull code out of pheonix
> > into modules. we can also add new code in as modules. branches can
> > just branch the modules they need and keep the others on trunk.
> >
> > if there's consensus about this approach, i'm willing to make time to
> > execute (unless someone beats me to it ;-)
> >
> > opinions?
>
> I prefer maven2 for modular builds. Imho make things more clear.
>
> On the other side I think that who *does* stuff have a special choice on
> how to do this, so I'm +1 *if* you'll take care of this.
a reorganisation along these lines would be build system agnostic: the
standard modules would be laid out using the standard jakarta
conventions upon which maven was based, the deployment module(s) would
use the current trunk layout.
> (I'm not +1, but -0, on a general choice for ant based multi-module
> build system: I still prefer maven2, expecially for a multi-module build)
IMO it's best to separate choice of build system from modularization.
ant 1.7 is good at multi module builds and so is maven 2 (early
versions of both systems had their flaws). the module code should not
need major reorganisation to switch from ant to maven but ant would
still be the primary build system for james.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> Ehi Danny, I replied +1, didn't you see? ;-)
I saw, thats fine, I'm not criticising you, just making the point that
we could probably all do without re-running the Maven vs Ant debate,
and particularly not with adding it to this discussion.
> And note that our website is build using maven2, so if we change the
> whole structure and we want to keep creating the website that way we'll
> have to update the maven2 stuff (pom.xml) anyway
Yeah, fine I get this, and Maven is proving itself for the web site.
> or create the necessary
> ant code to create the current site from the xdocs and the maven2 skin.
Not difficult to do if thats what we want.
And Maven *might* be useful if we're thinking of distributing James in
a variety of ways, the dependance management could be extremely
convenient. But it might be too confusing to try to refactor at the
same time as we change the whole build process. I'm more in favour of
trying to do one thing at a time.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> On 2/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>> I prefer maven2 for modular builds. Imho make things more clear.
>
> Please, not this again, lets just stick with Ant.
>
> d.
Ehi Danny, I replied +1, didn't you see? ;-)
But I think it is better to explain when a +1 is for an action being
taken or a +1 is an indication for a general architectural choice.
And note that our website is build using maven2, so if we change the
whole structure and we want to keep creating the website that way we'll
have to update the maven2 stuff (pom.xml) anyway or create the necessary
ant code to create the current site from the xdocs and the maven2 skin.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/3/07, Stefano Bagnara <ap...@bago.org> wrote:
> I prefer maven2 for modular builds. Imho make things more clear.
Please, not this again, lets just stick with Ant.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
robert burrell donkin wrote:
> with the need to modularise, i think that there's now more convergence
> towards this
>
> given a little initial restructuring (moving code around), it should
> be possible to gradually move code out from the pheonix deployment
> module into separate modules.
>
> phase 1: make space for modules within james server trunk
> * server/trunk -> server/trunk/pheonix
>
> phase 2: top level build
> * create build.xml which delegates to pheonix/build.xml
>
> phase 3: upgrade build:
> * upgrade to ant 1.7 (the new features are *really* good)
> * create stage subdirectory which is local only
> * create buildtasks module to host build macros and ant tasks for
> module builds
>
> phase 3: create empty base module top to contain API interfaces
> * create macros and tasks to support modular build
> * create build-modules.xml to support common structure
> * base builds copies artifacts into stage subdirectory
> * pheonix build copies artifacts locally from stage
> * create macros to allow easy generation of new modules
>
> once this has been done, we can gradually pull code out of pheonix
> into modules. we can also add new code in as modules. branches can
> just branch the modules they need and keep the others on trunk.
>
> if there's consensus about this approach, i'm willing to make time to
> execute (unless someone beats me to it ;-)
>
> opinions?
I prefer maven2 for modular builds. Imho make things more clear.
On the other side I think that who *does* stuff have a special choice on
how to do this, so I'm +1 *if* you'll take care of this.
(I'm not +1, but -0, on a general choice for ant based multi-module
build system: I still prefer maven2, expecially for a multi-module build)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/3/07, robert burrell donkin <ro...@gmail.com> wrote:
> opinions?
I like it.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/2/07, Danny Angus <da...@apache.org> wrote:
<snip>
> I posted this to the PMC list in q4 2004, when we were discussing what
> to do about the closure of Avalon. Time has moved on since then but I
> think it is still relevant:
>
> ... we slowly remove all trace of Avalon and Phoenix from James,
> refactoring it into a "james-phoenix" deployment project and leaving "our"
> code as POJO's
>
> Then we market James as container agnostic, supporting massive
> extensibility/configurability, and invite container projects to create
> other deployment packagers for James, MX or EJB/JCA or Geronimo or Pico or
> son-of-avalon, whatever. Let them compete to be the *best* container for
> James, not the *only* container for James because James will be the only
> sensible solution for proving a future proof mail framework.
>
> Thats the crux of it really, make James not standalone but embedable by
> design, any standalone distributions would be two things James+deployment
> code.
>
> Encourage people to come in and contribute their "non-core" stuff, and
> focus our limited bandwidth on creating deployment options for James, make
> james the ultimate chameleon, capable of being easily wrapped to embed in
> any Java container you want.
>
> James should be easily extended anywhere, be that by adding protocols, fast
> fail storage, mailets, seive whatever.
> Lets try to make James the R&D environment of choice for people who are
> experimenting with changing the nature of mail, and the discerning admins
> choice for flexibility.
> I think we've suffered a little from our lack of willingness to deviate
> from design decisions in the face of requests from the real world, lets
> open up the whole of James so that anyone can implement anything, even if
> it defies convention and breaks the rules.
with the need to modularise, i think that there's now more convergence
towards this
given a little initial restructuring (moving code around), it should
be possible to gradually move code out from the pheonix deployment
module into separate modules.
phase 1: make space for modules within james server trunk
* server/trunk -> server/trunk/pheonix
phase 2: top level build
* create build.xml which delegates to pheonix/build.xml
phase 3: upgrade build:
* upgrade to ant 1.7 (the new features are *really* good)
* create stage subdirectory which is local only
* create buildtasks module to host build macros and ant tasks for
module builds
phase 3: create empty base module top to contain API interfaces
* create macros and tasks to support modular build
* create build-modules.xml to support common structure
* base builds copies artifacts into stage subdirectory
* pheonix build copies artifacts locally from stage
* create macros to allow easy generation of new modules
once this has been done, we can gradually pull code out of pheonix
into modules. we can also add new code in as modules. branches can
just branch the modules they need and keep the others on trunk.
if there's consensus about this approach, i'm willing to make time to
execute (unless someone beats me to it ;-)
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Stefano Bagnara <ap...@bago.org>.
Danny Angus wrote:
> On 2/3/07, David Woldrich <da...@woldrich.com> wrote:
>> I think your "James is a POJO chameleon" idea makes a lot of sense. If
>> we make it easy for 3rd parties to wrap James up, they'd do the heavy
>> lifting of packaging the code up for you and making it deployable to
>> their systems. Is there anything screwy about picking the Spring
>> framework as the official container into which James is poured?
>> Couldn't that just be how James is shipped from the core team?
>
> IMO Yes... but ... we first need to be sure that we haven't missed any
> subtle but fatal gotcha's
I really suggest reading this old threads:
SpringJames vs. JamesNG
http://www.mail-archive.com/server-dev@james.apache.org/msg03576.html
Maven 2 and XBean
http://www.mail-archive.com/server-dev@james.apache.org/msg06246.html
Central class for service injection
http://www.mail-archive.com/server-dev@james.apache.org/msg08541.html
And expecially this one:
Re: [jira] Commented: (JAMES-495) Decide how to replace Avalon
Configuration (28/05/2006 16.09)
http://www.mail-archive.com/server-dev@james.apache.org/msg07490.html
I think that finding an answer to the last question will make anyone
more aware of what it means pojoification for James.
IMHO the key is make every component a container managed component, so
embracing avalon much more by creating avalon managed factories wheneven
you need to create components that need lifecycle. Once every component
will be top level (declare in the assembly) and
generated/fine-grained-componetns will be created by top-level factories
then a move to another container and a removal of avalon specific stuff
will be possible.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/3/07, David Woldrich <da...@woldrich.com> wrote:
> I think your "James is a POJO chameleon" idea makes a lot of sense. If
> we make it easy for 3rd parties to wrap James up, they'd do the heavy
> lifting of packaging the code up for you and making it deployable to
> their systems. Is there anything screwy about picking the Spring
> framework as the official container into which James is poured?
> Couldn't that just be how James is shipped from the core team?
IMO Yes... but ... we first need to be sure that we haven't missed any
subtle but fatal gotcha's
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Bernd Fondermann <be...@googlemail.com>.
On 2/4/07, robert burrell donkin <ro...@gmail.com> wrote:
> On 2/3/07, David Woldrich <da...@woldrich.com> wrote:
> > So, Spring would be the officially supported platform -
> > the only one that the core James team needs to be savvy with, but by no
> > means would Spring be the only container that could host James. Sounds
> > like what's going to be hot next year will just be all hot air, so
> > picking Spring is probably an ok decision.
>
> pheonix is an advanced and mature IoC container of the second
> generation. it runs the standalone application very well but requires
> custom adapters for other environments.
>
> spring is a third generation container and had the benefit of learning
> from drawbacks of the first and second generation containers but it's
> not as mature. switching from a mature container that's know to work
> well with james to spring would be risky and IMO it would be a poor
> trade.
No need to switch. We could provide an initial spring-based
distribution side-by-side the current phoenix-based ones quite easily,
based on the work in the spring-integration branch. Some developers
even use this code to run James out of Eclipse, AFAIK.
<off-topic>
Robert, where did you get that notion of first, second, third
generation containers from?
I am very interested in the specific definitions for some researches I
am doing ATM.
</off-topic>
> IMHO the biggest structural issue that james development has at the
> moment is not choice of container but a lack of modularization.
+1
> it is too much work to move all the current code base to POJOs. we
> need to be able to port code gradually.
For what it's worth, this was my initial motivation to start writing
unit tests: To be able to make refactorings on the "component
architecture" and being able to take that all apart and reassemble.
At the time we have enough of these, those refactoring will be totally
painless ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/3/07, David Woldrich <da...@woldrich.com> wrote:
> Robert,
> > <snip>
> >>
> >> their systems. Is there anything screwy about picking the Spring
> >> framework as the official container into which James is poured?
> >> Couldn't that just be how James is shipped from the core team?
> >
> > experienced has proved that it's better to be container agnostic
> >
> > pheonix was hot five years ago. last year, spring was hot. who knows
> > what'll be hot next year?
> >
> > yes, ship with bindings but free the core from container dependencies
> >
> All I was failing to communicate was, since James has to run standalone
> somehow, Spring could be the choice this year for what container to drop
> the POJO's in.
nothing wrong with your communication
> So, Spring would be the officially supported platform -
> the only one that the core James team needs to be savvy with, but by no
> means would Spring be the only container that could host James. Sounds
> like what's going to be hot next year will just be all hot air, so
> picking Spring is probably an ok decision.
pheonix is an advanced and mature IoC container of the second
generation. it runs the standalone application very well but requires
custom adapters for other environments.
spring is a third generation container and had the benefit of learning
from drawbacks of the first and second generation containers but it's
not as mature. switching from a mature container that's know to work
well with james to spring would be risky and IMO it would be a poor
trade.
> I'm just thinking from an executive decision-making standpoint, if the
> team were to make a major call like that and not have Spring be just
> some prototypical thingy, it might help focus refactoring efforts. And
> for me personally, I would have something I could latch onto. (I "get"
> POJO architectures. :)) Reading over the links Stefano provided, I see
> the POJO subject has come up over and over again, even with some
> specifics about what could and should be done there next.
IMHO the biggest structural issue that james development has at the
moment is not choice of container but a lack of modularization. there
is too much code on branches which should be in experimental modules.
it is too much work to move all the current code base to POJOs. we
need to be able to port code gradually.
there seems tentative consensus on my reorganisation idea so i'll push
it forward to the next stage.
> Stefano, I also am liking what I see with Maven 2. Switching to that
> for the build system would bring James more into accord with other
> Apache projects that are multiproject as well.
the choice of build system is a religious subject
from a technological perspective, both maven 2 and ant 1.7 work well
with multi-project builds (though earlier versions of each library has
drawbacks when used with multiple modules).
from a pragmatic perspective, switching the creation of the standalone
deployment to maven would require someone to invest several weeks in
creating numerous custom plugins. (switching the proposed module
builds to maven would be less effort.) not sure that anyone cares
enough about the build system to win the religious war and then create
the required plugins.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Robert,
> <snip>
>>
>> their systems. Is there anything screwy about picking the Spring
>> framework as the official container into which James is poured?
>> Couldn't that just be how James is shipped from the core team?
>
> experienced has proved that it's better to be container agnostic
>
> pheonix was hot five years ago. last year, spring was hot. who knows
> what'll be hot next year?
>
> yes, ship with bindings but free the core from container dependencies
>
All I was failing to communicate was, since James has to run standalone
somehow, Spring could be the choice this year for what container to drop
the POJO's in. So, Spring would be the officially supported platform -
the only one that the core James team needs to be savvy with, but by no
means would Spring be the only container that could host James. Sounds
like what's going to be hot next year will just be all hot air, so
picking Spring is probably an ok decision.
I'm just thinking from an executive decision-making standpoint, if the
team were to make a major call like that and not have Spring be just
some prototypical thingy, it might help focus refactoring efforts. And
for me personally, I would have something I could latch onto. (I "get"
POJO architectures. :)) Reading over the links Stefano provided, I see
the POJO subject has come up over and over again, even with some
specifics about what could and should be done there next.
Stefano, I also am liking what I see with Maven 2. Switching to that
for the build system would bring James more into accord with other
Apache projects that are multiproject as well.
Cheers,
Dave Woldrich
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by robert burrell donkin <ro...@gmail.com>.
On 2/3/07, David Woldrich <da...@woldrich.com> wrote:
> Danny,
>
> <snip>
> > I posted this to the PMC list in q4 2004, when we were discussing what
> > to do about the closure of Avalon. Time has moved on since then but I
> > think it is still relevant:
> >
> > ... we slowly remove all trace of Avalon and Phoenix from James,
> > refactoring it into a "james-phoenix" deployment project and
> > leaving "our"
> > code as POJO's
> >
> I think your "James is a POJO chameleon" idea makes a lot of sense. If
> we make it easy for 3rd parties to wrap James up, they'd do the heavy
> lifting of packaging the code up for you and making it deployable to
> their systems. Is there anything screwy about picking the Spring
> framework as the official container into which James is poured?
> Couldn't that just be how James is shipped from the core team?
experienced has proved that it's better to be container agnostic
pheonix was hot five years ago. last year, spring was hot. who knows
what'll be hot next year?
yes, ship with bindings but free the core from container dependencies
> <snip>
> >> If there was ever an
> >> official James bug day, I would love to get involved, make some new
> >> friends, and (especially) do some work towards the James-As-Plugin
> >> end...
> >
> > Thats a nice idea, but we're a pretty global bunch and tend not to
> > work regular hours.
> > OTOH we've got a whole bunch of stuff in JIRA which you're welcome to
> > pick from.
> > In return we need to sort out our lifecycle so that you get the warm
> > glow from seing your fixes released, rather than languish in svn for
> > months on end.
> >
> Yeah, it was just a thought because I figure I'm going to need some
> pretty serious handholding at first if I'm going to help out.
not a problem. you'll find people here are friendly enough :-)
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by David Woldrich <da...@woldrich.com>.
Danny,
<snip>
> I posted this to the PMC list in q4 2004, when we were discussing what
> to do about the closure of Avalon. Time has moved on since then but I
> think it is still relevant:
>
> ... we slowly remove all trace of Avalon and Phoenix from James,
> refactoring it into a "james-phoenix" deployment project and
> leaving "our"
> code as POJO's
>
I think your "James is a POJO chameleon" idea makes a lot of sense. If
we make it easy for 3rd parties to wrap James up, they'd do the heavy
lifting of packaging the code up for you and making it deployable to
their systems. Is there anything screwy about picking the Spring
framework as the official container into which James is poured?
Couldn't that just be how James is shipped from the core team?
<snip>
>> If there was ever an
>> official James bug day, I would love to get involved, make some new
>> friends, and (especially) do some work towards the James-As-Plugin
>> end...
>
> Thats a nice idea, but we're a pretty global bunch and tend not to
> work regular hours.
> OTOH we've got a whole bunch of stuff in JIRA which you're welcome to
> pick from.
> In return we need to sort out our lifecycle so that you get the warm
> glow from seing your fixes released, rather than languish in svn for
> months on end.
>
Yeah, it was just a thought because I figure I'm going to need some
pretty serious handholding at first if I'm going to help out.
Cheers,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: James deployed as plugin on Geronimo!
Posted by Danny Angus <da...@apache.org>.
On 2/1/07, David Woldrich <da...@woldrich.com> wrote:
> Do I have your attention yet? :)
Yes :-)
> I understand there are architectural thingies in James to consider and
> phoenix and whatnot. I understand that there's a lot of time and
> investment in the existing architecture. And I'm not suggesting that
> James should not be able to run standalone, but I would like to be able
> to optionally deploy James to Geronimo as a plugin. Has someone in the
> know put any thoughts together on what it would take for this type of
> deployment of James?
Yes, I have. Well not exactly, but it got your attention right? ;-)
We have an architecture which should lend itself well to james core
services being re-packaged for a whole range of deployment options. We
already have a sandbox fork which is deplyed in Springframework.
I posted this to the PMC list in q4 2004, when we were discussing what
to do about the closure of Avalon. Time has moved on since then but I
think it is still relevant:
... we slowly remove all trace of Avalon and Phoenix from James,
refactoring it into a "james-phoenix" deployment project and
leaving "our"
code as POJO's
Then we market James as container agnostic, supporting massive
extensibility/configurability, and invite container projects to create
other deployment packagers for James, MX or EJB/JCA or
Geronimo or Pico or
son-of-avalon, whatever. Let them compete to be the *best* container for
James, not the *only* container for James because James will be the only
sensible solution for proving a future proof mail framework.
Thats the crux of it really, make James not standalone but embedable by
design, any standalone distributions would be two things
James+deployment
code.
Encourage people to come in and contribute their "non-core" stuff, and
focus our limited bandwidth on creating deployment options for
James, make
james the ultimate chameleon, capable of being easily wrapped
to embed in
any Java container you want.
James should be easily extended anywhere, be that by adding
protocols, fast
fail storage, mailets, seive whatever.
Lets try to make James the R&D environment of choice for people who are
experimenting with changing the nature of mail, and the
discerning admins
choice for flexibility.
I think we've suffered a little from our lack of willingness to deviate
from design decisions in the face of requests from the real world, lets
open up the whole of James so that anyone can implement
anything, even if
it defies convention and breaks the rules.
Discussions with Dan Debrunner about a year later talked about
embedding James in Derby, as well as Derby in James, to produce a
mail-enabled database.
http://mail-archives.apache.org/mod_mbox/james-server-dev/200511.mbox/%3c437CB43F.50306@debrunners.com%3e
What showstoppers are there?
Lack of available effort, and a clear set of refactoring goals is what
has foundered the effort so far.
We'd probably have to re-structure the project to have james core and
a number of deployment options, and we'd need to create the deployment
options. Nothing fatal that I can see.
> If there was ever an
> official James bug day, I would love to get involved, make some new
> friends, and (especially) do some work towards the James-As-Plugin end...
Thats a nice idea, but we're a pretty global bunch and tend not to
work regular hours.
OTOH we've got a whole bunch of stuff in JIRA which you're welcome to
pick from.
In return we need to sort out our lifecycle so that you get the warm
glow from seing your fixes released, rather than languish in svn for
months on end.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org