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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
