Re: Hessian mailet

2006-04-22 Thread Serge Knystautas
On 4/20/06, Steve Brewin <[EMAIL PROTECTED]> wrote: > Serge Knystautas wrote: > > > > Guys, > > > > I was going to commit this, but wanted to run it by you just since it > > introduces another dependency. > > Ugh! Surely this is an optional feature. If people want to use it only then > should they

Re: Hessian mailet

2006-04-22 Thread Serge Knystautas
On 4/21/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote: > Stefano Bagnara wrote: > > Why don't we simply put the mailet in the Jar and import the package in > > config.xml ? > > > > A mailet already is a class that handle a mail and could be able to send > > the message to remote service. > > one h

RE: Hessian mailet

2006-04-22 Thread Steve Brewin
Serge Knystautas wrote: > > > On 4/20/06, Steve Brewin <[EMAIL PROTECTED]> wrote: > > Serge Knystautas wrote: > > > > > > Guys, > > > > > > I was going to commit this, but wanted to run it by you > just since it > > > introduces another dependency. > > > > Ugh! Surely this is an optional feature

Re: Hessian mailet

2006-04-22 Thread Stefano Bagnara
Serge Knystautas wrote: On 4/20/06, Steve Brewin <[EMAIL PROTECTED]> wrote: Serge Knystautas wrote: Guys, I was going to commit this, but wanted to run it by you just since it introduces another dependency. Ugh! Surely this is an optional feature. If people want to use it only then should the

Re: Fast-fail / Handlerchain change proposal

2006-04-22 Thread Stefano Bagnara
Venkataraman, Narendra wrote: I agree with you on the implicit dependencies on state hash map. While you work on A, I propose to implement some useful message and command handlers that we can ship with JAMES. The experience in developing these handlers can provide inputs to long term B approach.

Re: Hessian mailet

2006-04-22 Thread Bernd Fondermann
Serge Knystautas wrote: On 4/21/06, Bernd Fondermann <[EMAIL PROTECTED]> wrote: Stefano Bagnara wrote: Why don't we simply put the mailet in the Jar and import the package in config.xml ? A mailet already is a class that handle a mail and could be able to send the message to remote service.

Re: Maven 2 and XBean

2006-04-22 Thread Alan D. Cabrera
Stefano Bagnara wrote: Alan D. Cabrera wrote: Bernd Fondermann wrote: wouldn't it be best to POJO-fy _first_ without a specific container in mind (a larger task on its own) and then afterwards look at all the mature containers to integrate with? My thoughts exactly. IMHO, if the container m

Re: Maven 2 and XBean

2006-04-22 Thread Alan D. Cabrera
Stefano Bagnara wrote: Alan D. Cabrera wrote: Can XBean split the configuration in 2 multiple files? We currently have assembly.xml to declare how the component dependencies/wiring and config.xml to fill in configurations for that components. I don't think so. I've had some experience w/ ha

Re: Maven 2 and XBean

2006-04-22 Thread Alan D. Cabrera
Stefano Bagnara wrote: Alan D. Cabrera wrote: Bernd Fondermann wrote: Stefano Bagnara wrote: I currently don't have an opinion on what it is better for us between j2ee, OSGi, XBean, Phoenix, , but I think that we should choose one. This is way I'm really interested in pro/cons of XBean.

Re: Maven 2 and XBean

2006-04-22 Thread Alan D. Cabrera
Steve Brewin wrote: Stefano Bagnara wrote: It seems that if there is one thing that stirs us up it is container issues. At their most basic, containers provides the glue to wire application specific objects together and provide them with the service they require. Application objects are simple P

Re: Maven 2 and XBean

2006-04-22 Thread Alan D. Cabrera
Stefano Bagnara wrote: Steve Brewin wrote: [...] What is a service? In James and many other early container oriented applications it is something provided from outside of the application. Application objects are assumed to be present and referenced directly from within the code. They are treate

Maven 2

2006-04-22 Thread Alan D. Cabrera
Noel J. Bergman wrote: Alan Cabrera wrote: I'm going to investigate what it takes to convert James to maven 2 and XBean. I realize that others may not like that idea. My thinking is to convert a small piece and solicit comments. Let's separate the two issues, shall we? Personally,

Re: Maven 2 and XBean

2006-04-22 Thread Stefano Bagnara
Alan D. Cabrera wrote: We don't depend on the container itself. We don't have dependencies on phoenix in our code. We depend on the avalon-framework: think at it as a set of mostly interfaces and basic classes that helps starting up a new project (a common way to define things). It's the last b

Re: XBean

2006-04-22 Thread Alan D. Cabrera
Noel J. Bergman wrote: Alan Cabrera wrote: I'm going to investigate what it takes to convert James to maven 2 and XBean. I realize that others may not like that idea. My thinking is to convert a small piece and solicit comments. As for XBean, I favor OSGi interfaces, particularly as OSG

RE: Hessian mailet

2006-04-22 Thread Steve Brewin
Stefano Bagnara wrote: > > Serge Knystautas wrote: > > On 4/20/06, Steve Brewin <[EMAIL PROTECTED]> wrote: > >> Serge Knystautas wrote: > >>> Guys, > >>> > >>> I was going to commit this, but wanted to run it by you > just since it > >>> introduces another dependency. > >> Ugh! Surely this is an op

RE: Maven 2 and XBean

2006-04-22 Thread Steve Brewin
Alan D. Cabrera wrote: > > Steve Brewin wrote: > > Stefano Bagnara wrote: > > It seems that if there is one thing that stirs us up it is > container issues. > > > > At their most basic, containers provides the glue to wire > application > > specific objects together and provide them with the ser

Re: Hessian mailet

2006-04-22 Thread Serge Knystautas
On 4/22/06, Steve Brewin <[EMAIL PROTECTED]> wrote: > My concern wasn't really related to size. It was with creating a dependency > on a new and cool but not yet widely used API. In the same way as others > have expressed concern that we should not jump 'out of the fire in to the > frying pan' [old