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 Andrei Ivanov <my...@surfeu.fi> on 2002/08/14 00:29:04 UTC
Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
WOW!
And next things I would like to do
1. securing the SMTP remote delivery. Now I have answers to Serges's
questions he asked me long ago. After this we will be able really to secure
everything in James and make it even more attractive for business!
2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
rules!!!)
Andrei
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Wednesday, August 14, 2002 1:09 AM
Subject: RE: Contribution: Re: Handlers' streams RE: [Bug 11235]
>
> All,
>
> I'm going to be taking these files, making some alterations to bring
> them into line with James code standards, and basically getting them in
> the standard form for submission. In addition to these modifications, I
> will be unifying all of the server/handlers under this connection
> paradigm. At that point I'll discuss with Andrei, and resubmit the
> modified code to the list for discussion. Hopefully we'll get that
> taken care of in a week or so, as I'd really like to see this code
> incorporated into the code base.
>
> --Peter
>
> > -----Original Message-----
> > From: Andrei Ivanov [mailto:myfam@surfeu.fi]
> > Sent: Tuesday, August 13, 2002 3:09 PM
> > To: James Developers List
> > Subject: Contribution: Re: Handlers' streams RE: [Bug 11235]
> >
> > Hi,
> > finally it's done (see attachment)
> >
> > Comments:
> >
> > Attached are only modified and new files for current James.
> > If you check out new james and copy src directory from zip over
> existing
> > src
> > dir and build james distribution it will run right away.
> > When you'll look at sources you'll see what I've done. It is not well
> > commented in the code though...
> >
> > There are two things you have to pay attention first of all
> >
> > 1. "connection" package structure doesn't correspond james structure
> where
> > interfaces defined in "services" and implementation is spread over
> other
> > packages (I've been always wandering why James originators hadn't
> adapted
> > cornerstone package structure from very beginning). So you may want to
> > modify connection package structure (move interfaces and
> implementations)
> >
> > 2. About SMTPHandler. I adapted only doAUTH(..) method from the latest
> > James
> > (you will see it because it is shifted right). I think that most of
> the
> > recent changes were done to this method so I copied it from current
> James
> > and modified it according to my changes. If other methods have changed
> > recently you'll have to add those modifications to new SMTPHandler
> (use
> > doAUTH(..) as an example).
> >
> >
> > Andrei
> >
> > ----- Original Message -----
> > From: "Andrei Ivanov" <my...@surfeu.fi>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Monday, July 29, 2002 12:14 AM
> > Subject: Handlers' streams RE: [Bug 11235]
> >
> >
> > > Ok, then there will be
> > >
> > > 1. new AbstractServer
> > > 2. modified SMTPServer
> > > 3. modified SMTPHandler
> > > 4. modified MimeMessageInputStreamSource
> > > 5. modified SmsImpl (only one new constructor)
> > >
> > > There will be no changes in configs so that no compatibility
> hazards.
> > Hope
> > > it will not be so little slow to apply these changes.
> > >
> > > How does this sound now?
> > >
> > > Heh, I would like to add to this logging levels for mailets, but
> this is
> > > totally another story ;-). I am just recalling broken lances over
> > mailet
> > > logging :-( ...to no avail.
> > >
> > > Andrei
> > >
> > > ----- Original Message -----
> > > From: "Danny Angus" <da...@apache.org>
> > > To: "James Developers List" <ja...@jakarta.apache.org>
> > > Sent: Sunday, July 28, 2002 11:51 PM
> > > Subject: RE: [Bug 11235] Extensive use of string concatenation
> > throughout
> > > code base
> > >
> > >
> > > >
> > > >
> > > > > I can
> > > > > provide fixed SMTPHandler (since I ve been working a lot with
> this
> > part
> > > of
> > > > > James for my project) so that other handlers can be fixed as
> well
> > > similar
> > > > > way. How does this sound?
> > > >
> > > > Andrei,
> > > > We're *always* happy to accept contributions.
> > > > If a little slow, at times, to apply them.
> > > >
> > > > d.
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>What are the relationships between Merlin, Fortress and Phoenix?
>
In the beginning there was ECM (Excalibur Component Manager) and
Phoenix. ECM was basically a component manager implementation running
on steroids. It came about as a result of the needs of the Cocoon
community for dynamic service activation. Phoenix went in a different
direction, focussing much more of well structured service management
(dependency control, etc). About twleve months ago Fortress emerged -
the next generation of the Cocoon style dynamic service management but
formally structured as a container. About the same time, Merlin 1.0
arrived on the scene - basically a compoent runner along the lines of
Phoneix (xinfo based management and so on - but with auto assembly
abilities). Three months ago some work was initiated on a common
meta-model for all of these containers in a package called Containerkit.
That got forked as part of the work relating to Merlin 2.0 - a next
generation service management platform. Merlin 2.0 is progressivly
incorporating Fortress features concerning lifecycle and lifestlke
management and Fortress is adopting the Merlin 2.0 meta-model.
>Are they all containers for Avalon Frameworks components?
>
Yes - but with variations.
* Fortress supports different component lifestyles (threadsafe,
per-thread, pooled, etc.) but weak in respect to dependency
management and formal meta-model.
* Phoenix provides a reasonably complete app-server framework
for a linear service management model.
* Merlin provides a container hierachy, automated assembly,
dynamic component installation, automated context management,
package deployment profiles, and more.
>Cornerstone and Excalibre classes work with any of them?
>
Merlin will provide support for Phoenix blocks reasonably soon. The DTD
for Merlin xinfo files is very similar to a block info (but more stuff
concerning lifecycle extensions, and extension depedencies). In the
near future Merlin will automatically build a meta-model from a Phoenix
block defintion. Things like BlockListeners may be provided as
lifecycle extensions. As Fortress moves forward with implemetation
above the Merlin meta-model it will aquire the ability to run blocks as
well.
Merlin 2.0 lives in the following CVS:
akarta-avalon-excalibur/assembly
>Feel free to post a link to an FAQ.
>
Merlin Home Page
----------------
http://home.osm.net/doc/merlin
Merlin FAQ
----------
http://home.osm.net/doc/merlin/faq.html
Cheers, Steve.
>
>
> --- Noel
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Tuesday, August 13, 2002 23:24
>To: James Developers List
>Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
>RE: [Bug 11235]
>
>Andrei Ivanov wrote:
>
>
>>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>>rules!!!)
>>
>>
>
>You may want to hold off on this for a little while. Currently over in
>Avalon land there is work going on concerning a standard "meta model"
>that will be described using an xinfo resource that has the potential to
>enable component deployment across a number of different containers.
> Currently James uses Phoenix as its container and describes component
>meta-info in a blockinfo descriptor. It is expected that Phoenix will
>be enhanced to support a more standard meta info DTD in the near future.
> In the meantime there is work on-going with two other containers -
>Fortress and Merlin. The authors of these containers are working
>together to ensure the establishment of a meta-model that completely
>addresses not only the defintions of component services and depenedecies
>along the lines of the blockinfo model, but addition contextn such as
>lifecycle extensions, lifestyle management, and so on. When this all
>settles down I expect we will see support in Phoenix for the
>Fortress/Merlin meta-model and support for blockinfo declarations inside
>Merlin.
>
>Cheers, Steve.
>
>--
>
>Stephen J. McConnell
>
>OSM SARL
>digital products for a global economy
>mailto:mcconnell@osm.net
>http://www.osm.net
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
What are the relationships between Merlin, Fortress and Phoenix? Are they
all containers for Avalon Frameworks components? Cornerstone and Excalibre
classes work with any of them?
Feel free to post a link to an FAQ.
--- Noel
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@apache.org]
Sent: Tuesday, August 13, 2002 23:24
To: James Developers List
Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
RE: [Bug 11235]
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Paul Hammant <Pa...@yahoo.com>.
Andrei,
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
>
It does but it bloats the download by 700K and adds multiple seconds to
the build times. I personally prefer hand crafted xinfo files, but
understand that many do not.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>