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 dev
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> 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 dep
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
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 G
Hi Robert,
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 POJ
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 probabl
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Hi Robert,
>
>>
>> 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
robert burrell donkin wrote:
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 implementat
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 connect
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> 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
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> 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 sugges
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 processi
Danny,
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" d
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> 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
On 2/2/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Danny,
> 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 Phoe
On 2/2/07, Danny Angus <[EMAIL PROTECTED]> wrote:
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,
robert burrell donkin wrote:
On 2/2/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 th
Danny Angus wrote:
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> 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
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 sp
Robert,
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 year
On 2/3/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
opinions?
I like it.
d.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For addit
Danny Angus wrote:
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 a
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> 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.
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 phe
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Robert,
>
>>
>> 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 t
robert burrell donkin wrote:
On 2/3/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 reorganisatio
[EMAIL PROTECTED] wrote:
>
>
> On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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
> a
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 2/3/07, David Woldrich <[EMAIL PROTECTED]> 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 cou
Steve,
On 2/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
With these two issues resolved a simple script could be used to bring up the
new server with a new and already tested configuration, switch the IP
redirection to point to this server, then "drain and close" the old server.
If you could
On 2/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
>
>
> On 2/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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 sav
On 2/4/07, Danny Angus <[EMAIL PROTECTED]> wrote:
It might also make sense to divide up the config of James into
distinct component configurations.
+1
the monolithic configuration is one of my main PITAs ATM so this is
something i've been thinking about today :-)
but it might be solved by
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
in this case, it seems unreasonable to stop
serving corporate emails just so because some enterprise application
needs to reconfigure their mailets.
This is kind-of my point, you can re-deploy or reconfigure the
server's behaviour wit
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
but it might be solved by moving into the world of mail applications...
Yeah, but at some point there will have to be a "vendor specific"
container config, even if the bulk of the behaviour is in the std. app
config. For a long while n
Danny Angus schrieb:
> On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
>> but it might be solved by moving into the world of mail applications...
>
> Yeah, but at some point there will have to be a "vendor specific"
> container config, even if the bulk of the behaviour is in the std. ap
[EMAIL PROTECTED] wrote:
> Steve,
>
> On 2/4/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
>
> > With these two issues resolved a simple script could be
> used to bring up the
> > new server with a new and already tested configuration,
> switch the IP
> > redirection to point to this server, then "dr
On 2/4/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 2/4/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
> in this case, it seems unreasonable to stop
> serving corporate emails just so because some enterprise application
> needs to reconfigure their mailets.
This is kind-of my point, you
On 2/1/07, David Woldrich <[EMAIL PROTECTED]> wrote:
Hi Robert,
>
>>
>> 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
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 do
On 2/14/07, David Woldrich <[EMAIL PROTECTED]> 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 questio
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
a
On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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 thi
On 2/15/07, Danny Angus <[EMAIL PROTECTED]> wrote:
On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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
On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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 shutdo
On 2/15/07, robert burrell donkin <[EMAIL PROTECTED]> wrote:
On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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 (mea
robert burrell donkin wrote:
>
>
> On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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.ex
On 2/16/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>
>
> On 2/15/07, David Woldrich <[EMAIL PROTECTED]> 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
robert burrell donkin wrote:
>
>
> On 2/16/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
> > robert burrell donkin wrote:
> > >
> > >
> > > On 2/15/07, David Woldrich <[EMAIL PROTECTED]> wrote:
> > > > Robert,
> > > >
> > > > Ok, fair enough. Well, honestly for starters, I would love
> > > to deploy
On 2/18/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
robert burrell donkin wrote:
>
> On 2/16/07, Steve Brewin <[EMAIL PROTECTED]> wrote:
> > robert burrell donkin wrote:
> > >
> > > On 2/15/07, David Woldrich <[EMAIL PROTECTED]> wrote:
> > > > Robert,
> > > >
> > > > Ok, fair enough. Well, hones
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 benefit
robert burrell donkin wrote:
> serving SMTP, news, IMAP and so on requires sockets serving, thread
> pools and access to the file system. i'm not sure whether this breaks
> the JCA contract
That's not where JCA belongs in the JAMES architecture. I've already been
through this in some detail.
On 3/10/07, Noel J. Bergman <[EMAIL PROTECTED]> 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,
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 d
On 3/10/07, Noel J. Bergman <[EMAIL PROTECTED]> 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 ca
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, t
[EMAIL PROTECTED] wrote:
> 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
57 matches
Mail list logo
