Re: [Fwd: Re: Dynamic Reconfiguration]

[Stephen McConnell]

Steve Brewin wrote:

Steve,

 

While the subject of this message is about re-configuration, I think
that there is an argument for looking at the requirements in-terms of
re-deployment.
|-- deployment ->|
||
|  |<- suspension ---|
|  | |
|<-- decommissioning --|
|  | resumption >|
||
||
|<-decommissioning --|
In the above diagram, "deployment" covers the instantiation and
lifecycle processing of a component by a container.  The act of
"suspension" is to place the component in a volatile state
during which the state provided to it by the container during 
the prior deployment cycle is subject to change.  An act of 
"resumption" is the process of taking a component from a 
volatile state to a stable deployed state, and finally, the act 
of "decommissioning" covers the shutdown stages leading
to component disposal.
   

As Avalon already defines these phases -
http://avalon.apache.org/framework/reference-the-lifecycle.html - this seems
an entirely sensible approach.
Going from the specification we have:

 Recontextualize
 Recomposable/Reserviceable
 Reparameterizable
 Reconfigurable
These interface do two things:

 a) act as marker interfaces that signal to a container
that a component can handle lifecycle reprocessing
 b) provides the operation through which a component
receives artifacts from the container
Generally speaking, Avalon is trying to move away from marker interfaces 
as they tend to tie implementation semantics into the interface.  A 
better approach is to declare the mutable nature of an supplied artifact 
inside meta info (but this is more an A5 subject).

It is important that we have control over the order that components are
suspended and resumed. 

Umm, there is a very important question here - who is "we"?  A container 
is going "control" the sequencing of component suspension and 
resumption.  In the James case this is interesting because below the 
macro level Avalon components (handled by an Avalon container), you have 
multiple mailet instances.  The "James" component in this context is 
acting as a container of these instances, and as such, the James 
component has rather a lot of work to do during a suspension 
re-deployment cycle (equivalent to a classic Avalon container but 
focussed on the mailet implementation classes and instances).


For instance, we would want to stop injecting mail
into the mailet chain and have the mailet chain complete the processing of
currently injected mail prior to suspending. The reverse during resumption.
I don't see anything in Avalon that enables such dependencies to be defined,
but I'm no expert.
The Mailet API defines the services that a mailet instance provides.  
The James component is responsible for deployment and decommissioning of 
mailet implementation scenarios (mailet class + config + context, etc). 
If there is a formal component model for a mailet implementation, then 
James can do equivalent management of mailets using an embedded 
container.  Avalon project content in this area is emerging - in 
particular the area of composite containment is rather active.

What are the principals/ideas used inside James for things like mailet 
deployment?  Are mailets implementations potentially suspedable/resumable?


In this picture the open question is the semantic applicable during a
"resumption" phase.  It is reasonable to assume that context
entries are immutable?
   

Yes. For components that do not support the suspend/resume this would be the
default. For components that do support suspend/resume I think that this
should also be the default. Supporting suspend/resume is saying the
component can be suspended and resumed. Declaring context entries as mutable
is saying that the component supports changing them when in the suspended
state.
Is it a requirement that all components in the server must support
suspend/resume in order for the server instance to support it? If not, what
we could end up with non-suspended components trying to talk suspended ones.
Not good!
If component A is suspended, and component B is dependent on A but B is 
not suspendable, the container has to decommission B (i.e. take the 
component instance B out of existence - which includes decommissioning 
of all components are dependent on or part of B).  This is not totally 
hard-and-fast because different containers can use different tricks via 
proxies to fake a suspension.  I.e.  if B were allowed to continue and 
if it made an invocation against A, the invocation could be intercepted 
and stalled within a proxy pending the resumption of A.

Maybe we have to add a default implementation of suspend/resume for all
components, where suspend invokes destroy() and resume invokes init().
This shou

[Fwd: Re: Dynamic Reconfiguration]

[Stephen McConnell]

 Original Message 
Subject:Re: Dynamic Reconfiguration
Date:   Sun, 29 Jun 2003 16:35:15 +0200
From:   Stephen McConnell <[EMAIL PROTECTED]>
Reply-To:   Avalon Developers List <[EMAIL PROTECTED]>
To: Avalon Developers List <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>


Noel:

While the subject of this message is about re-configuration, I think 
that there is an argument for looking at the requirements in-terms of 
re-deployment.

|-- deployment ->|
||
|  |<- suspension ---|
|  | |
|<-- decommissioning --|
|  | resumption >|
||
||
|<-decommissioning --|
In the above diagram, "deployment" covers the instantiation and 
lifecycle processing of a component by a container.  The act of 
"suspension" is to place the component in a volatile state during which 
the state provided to it by the container during the prior deployment 
cycle is subject to change.  An act of "resumption" is the process of 
taking a component from a volatile state to a stable deployed state, and 
finally, the act of "decommissioning" covers the shutdown stages leading 
to component disposal.

In this picture the open question is the semantic applicable during a 
"resumption" phase.  It is reasonable to assume that context entries are 
immutable?  It is possible that we may want to change the temporary 
working directory used by the component?  Perhaps we want to apply a 
logging channel that has been reconfigured to use a different output 
target or priority?  Perhaps we want to swap the source provider 
component for a DNS service with another provider?  Maybe some 
parameters need to be propagated to the component, or potentially some 
configuration information needs to be reassessed.  All of these question 
concern state that is supplied by a container to a component - and all 
represent reasonable candidates for "re-assessment".

One of the things that can be done to make the above scenario more 
manageable is to mark state that is supplied to a component by a 
container as immutable.  For example, it is possible to imagine a 
component type declaring (as part of its meta-info) the immutable versus 
modifiable information.  This could be done at the level of individual 
context entries, individual parameter values, even nodes of a 
configuration hierarchy.  Based on this information, a container could 
assess the scope of re-deployment that a particular component 
implementation supports and handle the resumption cycle accordingly.

In practice, the process of resumption could be viewed as re-application 
of the lifecycle stages, qualified relative to the immutable state of 
the respective artifacts (e.g. if logging is declared as immutable by a 
component implementation, then it makes no sense for a container to 
allow or attempt to apply a change).   In fact, this constraint could be 
pushed back to the management access point such that the initiation of 
change potential within a client interface could be qualified by the 
component meta info.

My 0.02 euro on a Sunday afternoon.

Cheers, Steve.

Noel J. Bergman wrote:

Avalon frameworks manage the core tasks and should ideally manage the
reconfiguration of those tasks. Achieving this means that all Avalon
components benefit from these advances.
Ideally, yes.  This is something that we should bring up with Avalon, not
just here.  They should provide the core facilities, and we should know how
to use them.

The configuration file, config.xml, is essentially a persistent store for
the configuration parameters. As it is XML based we may as well go with
it.

We may well want to expose the parsed parameters as Java objects through
some kind of interface.
You mean, other than the existing ones?


Probably James would use the Java objects as its configuration source
and perist any changes to the Java objects by updating config.xml.
Avalon provides the configuration interfaces, and should be responsible for
the core support.  However, I would not want to see normal components able
to effect configuratin changes.  The JMX support should be able to do so.
Basically, I agree with your thoughts.  I am simply emphasizing that the
core integration of (re-)configuration and JMX should be part of Avalon.  If
we do it here, for example if that is something you want to undertake, it
really should be done by contributing to Avalon.
	--- Noel

cc: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--

Stephen J. McConnell
mai

Re: NOTICE: *IMPORTANT* CVS MODULES ARE MOVING

[Stephen McConnell]

Noel J. Bergman wrote:

Stephen,

We've been talking about it for quite some time.  This is just an opportune
point to do it.
 

Personally I would really love to see a breakout of the different
components in James as seperate subprojects (i.e. going beyond
james/mailet separation and into the seperation of the basic building
blocks - smtp, dns, remote, pop3, nntp, etc.
   

I don't believe that is going to happen.  We do not need a CVS module per
service, IMO.
Actually I wasn't thinking about seperate cvs repos - instead I was 
thinking more along the lines of seperating component builds as 
sub-projects within the james module.  I've been doing a lot of playing 
around with James in the past few days (linked to the cornerstone 
component builds) - and I've got to the point where the individaul 
components are just plugged together.  It would be really nice to be 
able to do the same thing with the assorted James components. 

In fact I'll probably be posting a detailed email on this sometime soon 
because I preparing a writup on James as a composite component example 
and there are a few questions I have concerning dynamic usage of the 
mailet services (but that's for later).

Is this a good time to be thinking about migration to Maven as well?
   

One step at a time, but yes.  Didn't you see my comment in [EMAIL PROTECTED] asking
if we could borrow Leo?  :-)  

Yep :-)

Also, Dion Gillard had done some work on it,
but he felt a bit stymied, IIRC, by the lack of a proper Avalon release.  As
you know, that's changing.
Sure is - excalibur releases are complete, the cornerstone candidates 
are in place, and its all been tested (James HEAD + cornerstone 
candidates + excalibur releases + framework 4.1.4 or 4.1.5-dev).  The 
cornerstone suite is ready to incorporate into a maven build and all of 
the required resources are available under the ibiblio server (with the 
exception of mail_1_3.jar and activation.jar).

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NOTICE: *IMPORTANT* CVS MODULES ARE MOVING

[Stephen McConnell]

Noel:

Suprise, surprise - I was thinking about the very same thing just 
yesterday.  Personally I would really love to see a breakout of the 
different components in James as seperate subprojects (i.e. going beyond 
james/mailet separation and into the seperation of the basic building 
blocks - smtp, dns, remote, pop3, nntp, etc.

Is this a good time to be thinking about migration to Maven as well?

Steve.

Noel J. Bergman wrote:

Folks,

This is a notice to let you know that the James CVS modules will be
changing.
The current jakarta-james module will become james-server.  Initially,
everything will be in there, but we're going to separate out the web-site
into a new module (probably james-site), and eventually other modules, e.g.,
james-mailet.
Once the change has been made, you can edit cvs/Repository, and change it to
read james-server instead of jakarta-james.
	--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

build.xml update

[Stephen McConnell]

Have just updated the James buildfile to include the generation of three 
distinct jar files prior to the creation of the Phoenix sar file.  These 
jar files include:

  1. james-${version}.jar
  2. mailet-api-${mailet-api-version}.jar
  3. mailet-${mailet-version}.jar
The build automatically includes the above into the Phoenix sar - so 
everything from the Phoenix point of view remains the same.  The 
benefits of the update are related to the use of the mailet services in 
other application environments where it is desirable to include mailet 
APIs in a shared classloader (as opposed to mailet and james 
implementation jar files in an implemention classloader).

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Fwd: cornerstone candidates]

[Stephen McConnell]

 Original Message 
Subject: 	cornerstone candidates
Date: 	Fri, 20 Jun 2003 00:57:30 +0200
From: 	Stephen McConnell <[EMAIL PROTECTED]>
Reply-To: 	Avalon Developers List <[EMAIL PROTECTED]>
To: 	Avalon Users <[EMAIL PROTECTED]>, Avalon Dev 
<[EMAIL PROTECTED]>



The core components from the cornerstone suite are now in place. I have 
tested and all of the components against the James implementation and 
everything appears to be working nicely (in fact this message is sent to 
you using a version of James that is running above the release candidates).

For the purpose of validation, I would appreciate it if a few people 
could do a build using Maven 9 just to validate things.

cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login  
cvs -z3 -d :pserver:[EMAIL PROTECTED]:/home/cvspublic co 
avalon-components

The following commands will build the suite of cornerstone components, 
install them in you local Maven repository, and generate the 
avalon-components site documetation under the directory 
avalon-components/site/target/docs.

$ cd avalon-components
$ maven
For addition information there is always the README.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Fwd: [ebxml-mktg] ebMail Source Code Donated to ebXML DevelopmentCommunity]

[Stephen McConnell]

 Original Message 
Subject:[ebxml-mktg] ebMail Source Code Donated to ebXML Development
Community
Date:   Fri, 13 Jun 2003 11:00:19 EDT
From:   [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


TO: ebXML Marketeers

News from our friends in Hong Kong (see below).  Best regards.

Alan Kotok
[EMAIL PROTECTED]
http://www.technewslit.com/
Editor, E-Business*Standards*Today, http://www.disa.org/dailywire/
Editor, ebXML Forum, http://www.ebxmlforum.org/
==

*ebMail Source Code Donated to ebXML Development Community
*
Hong Kong, Peoples Republic of China - June 12, 2003 - Center for
E-Commerce Infrastructure Development (CECID), Department of Computer
Science and Information Systems (CSIS), The University of Hong Kong
(HKU) is pleased to announce its code base donation of ebMail to the
ebXML development community. This open-source project is released under
the Academic Free License
(http://www.opensource.org/licenses/academic/hph) that permits royalty
free use of the source and binaries. Developers are encouraged to
download ebMail at http://www.freebxml.org 
and subscribe to the mailing lists set up at sourceforge
(http://sourceforge.net/projects/ebmail) for enquiries.
ebMail is a desktop e-mail client which helps organizations,
small-and-medium-sized enterprises (SME) in particular, to engage in B2B
e-commerce activities. This lightweight toolkit enables trading partners
to exchange business documents cost-effectively through email, or ebXML
Message Service (ebMS) over Simple Mail Transport Protocol (SMTP).
ebMail is a trimmed-down ebMS handler which does not require any
application server software and dedicated Internet connection to use
ebXML. It allows a user to compose electronic documents offline through
graphical user interface (GUI), and send and receive documents when the
user is connected to the Internet.
ebMail employs plug-in modules to provide different graphical user
interface (GUI) forms for capturing business data into different schemas
of XML documents (e.g. price quotation, purchase order, invoice, etc.)
and binary file attachments (e.g. PDF, graphics, etc.). These plug-ins
can load, save, and manipulate business data in the
local file system, as well as import documents from office applications
to the GUI for
efficient document handling. ebMail plug-ins can also handle simple
business processes that define choreographies of document exchanges.
A Java-based and platform-neutral application, ebMail provides a Java
API for third-party developers to create plug-ins. The plug-in API
allows developers to program GUI handlers, convert input data into XML
documents of a specific schema, and develop advanced features, such as
document management in the local file system.
XML documents composed by ebMail plug-ins are packaged into ebMS
messages and send and receive messages in ebMS/SMTP through central
mechanisms. Furthermore, ebMail can digitally sign and encrypt outgoing
documents, and decrypt and authenticate incoming documents using digital
certificates, and it makes use of ebMS code from another open-source
project, Hermes (http://www.freebxml.org ).
ebMail was developed by CECID under the auspices of Project Phoenix.
Project Phoenix is primarily sponsored by the Innovation and Technology
Commission of the Hong Kong Government. Two of the pilot project
partners using ebMail are Department of Health of the Hong Kong
Government and Hong Kong Observatory. CECID has developed a
prototype based on ebMail for the Department of Health to streamline its
pharmaceutical products import and export licensing application
procedure. The Center is starting the development of a new ebMail
plug-in for Hong Kong Observatory, which has been designated by the
United Nations' World Meteorological Organization (WMO) to collect world
weather information for the WMO's Website.
About CECID (http://www.cecid.hku.hk ):
Established in January 2002, the Center for E-Commerce Infrastructure
Development (CECID) at the University of Hong Kong conducts e-commerce
research and development with the vision of helping Hong Kong increase
its competitiveness in the international arena. CECID has the mission to
develop e-commerce enabling technologies, to join important
international e-commerce initiatives, to support e-commerce
standardization for Hong Kong and the Asia-Pacific Region, and to
transfer e-commerce technology and skills to the community. As an OASIS
member, CECID is participating in standardization projects, such as
ebXML and Universal Business Language (UBL). CECID also collaborates
with a number of lead technology users in the Asia-Pacific Region on the
application of advanced e-commerce
technologies.
About freebXML (http://www.freebxml.org ):
FreebXML is an initiative that aims to foster the development and
adoption of ebXML and related te

Re: Shutting down James

[Stephen McConnell]

Noel J. Bergman wrote:

Well, we need to shutdown the container/application.  What is the
recommended means?
 

 

Hopefully there is a means to do this from outside of James.
   

We provide a telnet admin interface.  You've never seen it?  Ideally we can
replace it with a JMX interface.
 

 - shutdown: take down the entire system
   

That's the topic at hand.

 

 - redeploy: decommission and recommission incorporating
  any changes to deployment information and/or resoruces
   

As far as I know, Phoenix doesn't support that idea, but we'd like to be
able to restart parts of James with a new configuration without having to
shut it down.  For example, if I've changed the mailet configuration, I'd
like to restart the spooler.  I should not have to shutdown the SMTP server,
since it should not be impacted.
Just for reference ...

I am working on JMX stuff right now.  My objective is to provide 
fine-grain redeployment of an appliance inside a container.  This means 
that all components would be redeployable (without changing existing 
component code).  Given a hierachy of managers this would enable 
selective subsystem redeployment.  But this will not bne available 
tommorow - things are currently focussing on sensible and intiative 
presentation of JMX information.

Cheers, Steve.

Phoenix has a JMX access point and I belive that MX4J supports SSL based
connections (going on memory here) - so in pricipal this should be
possible.
   

We disabled MX4J when we found out that it was permitted unsecured
administration.  I'd like to re-enable.  Hopefully Steve will help us get
that all square.
	--- Noel
 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shutting down James

[Stephen McConnell]

Noel J. Bergman wrote:

Is it safe to do this?
 

NO. IMHO this is evil.
   

OK  :-)

 

Calling System.exit(0) is not something a component should be doing.
   

Well, we need to shutdown the container/application.  What is the
recommended means?
 

Hopefully there is a means to do this from outside of James.


Can you give me a hint at the underlying rationale for this?
   

Shutdown down?  Restarting with new code or a new configuration?

There are two distrinty different things here:

 - shutdown: take down the entire system
 - redeploy: decommission and recommission incorporating
   any changes to deployment information and/or resoruces
The difference is scope.

Perhaps it is something more appropriately handled at the level of a JMX
management operation.
   

If we had JMX, and it was secure ... ;-)
 

Phoenix has a JMX access point and I belive that MX4J supports SSL based 
connections (going on memory here) - so in pricipal this should be 
possible.  MNaybe we should post the question on [EMAIL PROTECTED] ?

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Shutting down James

[Stephen McConnell]

Noel J. Bergman wrote:

Stephen,

Is it safe to do this?

 try {
   ((org.apache.james.James)
theConfigData.getMailServer()).getBlockContext().requestShutdown();
 }
 catch (Throwable t) {
   System.exit(0);
 }
NO.
IMHO this is evil.
Basically a component has no knowlege of the components that are using 
it - on the other hand a container can maintain a complete usage graph 
for a component and can make decisions about decommissioning of a 
component based on usage.

Phoenix still leaves some droppings if we call System.exit(0).  I figure
that in a non-Phoenix container, we'd just catch the exception and call
System.exit.
Thoughts/recommendations?

Calling System.exit(0) is not something a component should be doing.  In 
effect any implemetation code calling System.exit is basically acting as 
a top level component - i.e. an application.  In the Phoenix environment 
it is a somewhat simpler because James is packages as an application 
unit.  However in the Merlin environment James is packages as a 
composite component that can be used by other components. 

Can you give me a hint at the underlying rationale for this?
Perhaps it is something more appropriately handled at the level of a JMX 
management operation.

Cheers, Steve.

	--- Noel




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] check-targets.properties

[Stephen McConnell]

Jason Webb wrote:

Steve,

If the junit.jar is already in the project.class.path does this mean
that I don't need to do anything else?
   
 
 
   
 

That's it - nothing else to do.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] check-targets.properties

[Stephen McConnell]

Danny Angus wrote:

I'm finding it fairly easy to build the HEAD, but difficult to change any code without ending up with two _different_ sets of errors, one from ant javac, the other from my IDE's build.

Danny:

This does not make sense unless your IDE is using a different project 
classpath declaration.  Keep in mind that the build file 
project.class.path contains a very explicit per file inclusion of jars.  
If your IDL is including jar files based on directories then I could 
imagine some problems (and the potential need to review the current 
setup to make it possible for directory based includes to function 
properly).


Its fairly obvious, even to me, that the issue is a classpath one and also one that may not be imediatly obvious to Stephen.

It's a good assumption - I'm building, modifying and running HEAD 
without problem in Merlin and periodically testing under Phoenix.

Cheers, Steve.

d.

 

-Original Message-
From: Jason Webb [mailto:[EMAIL PROTECTED]
Sent: 24 February 2003 11:11
To: 'James Developers List'
Subject: RE: [PATCH] check-targets.properties
I'm confused about the auto-getting of junit
I also had to add the following line to build.xml

As well as add the following to include.properties
# - junit -
junit.jar=${lib.dir}/junit-3.7.jar
Is this correct, or am I barking up the wrong tree.
With those changes I can pull down junit 3.7 if I don't have it and if I
do then everything is OK
If this is correct I'll submit a patch for the other files

-- Jason

   

-Original Message-
From: Jason Webb [mailto:[EMAIL PROTECTED] 
Sent: 24 February 2003 09:49
To: James Developers List
Subject: [PATCH] check-targets.properties

The Maven style trick doesn't work as the Ant build adds the 
current version to the .id prop.

-- Jason

 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] check-targets.properties

[Stephen McConnell]

Jason:

I just checked my system here and I have JUnit in lib/ext so naturally I 
didn't see the problem you are experiencing.  Yes - junit needs to be 
included in the jar dowloading stuff.  In addition to the modification 
of the include.properties, you will need to inclde a reference to the 
junit jar file in the tools.class.path entry in the buildfile.

Cheers, Steve.

Jason Webb wrote:

I'm confused about the auto-getting of junit
I also had to add the following line to build.xml

As well as add the following to include.properties
# - junit -
junit.jar=${lib.dir}/junit-3.7.jar
Is this correct, or am I barking up the wrong tree.
With those changes I can pull down junit 3.7 if I don't have it and if I
do then everything is OK
If this is correct I'll submit a patch for the other files

-- Jason

 

-Original Message-
From: Jason Webb [mailto:[EMAIL PROTECTED] 
Sent: 24 February 2003 09:49
To: James Developers List
Subject: [PATCH] check-targets.properties

The Maven style trick doesn't work as the Ant build adds the 
current version to the .id prop.

-- Jason

   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon Jars

[Stephen McConnell]

Danny Angus wrote:

My 
only concern
is that there is an overlap between jars used as part of the Phoenix
distribution that are also used or implied by the James distribution.
   

This is also my biggest gripe. I don't really think conscience would allow me to sancion a release of James which was dependant on two different versions of the same Avalon sourced class. It seems like a receipe (is that how you spell that?) 

recipe

:-)

for disaster.

My understanding is that your releasing 2.1.2 from a specific CVS branch 
which has not been synchronized with the CM-SM migrated HEAD.  The 2.1.2 
branch presumably is using the Phoenix release and the old 
corenerstone.jar file.  Is that assumption correct?  I also share your 
concerns about releasing collocated jars of different versions (but my 
impression is that this is not being proposed for the James 2.1.2 release).

As far as the subject of dealing with multiple versions of particular 
Avalon release - this is something I've been paying rather a lot of 
attention to.  For example, under the Merlin container it is a 
requirement that you declare the dependencies that your have for your 
application - more specifically - you should not be linking your runtime 
James build to the particular version of a jar file that a container 
uses - and the container should not force you one way or another in this 
regard.  I'm not that familiar with the classloading arrangements in 
Phoenix but I do not that more effort will be going into this area in 
Merlin to ensure that there is a complete isolation between jar files 
used by Merlin and jar files used by clients.

It's a recipe for independence.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon Jars

[Stephen McConnell]

Noel J. Bergman wrote:

I've just completed test of the current Phoenix dist (in the James CVS)
against the James sar file and that passed OK (i.e. James in Phoneix as is
appears to be working fine).
   

That's good  :-)

 

The one file that can be safely removed is cornerstone.jar
(its not referenced by anything).  The rest are related to
the Phoenix implementation and I would really need to get
some advice on what can be replaced here.
   

I don't know, either.  It seems to me that as Avalon proposes an RC, we
should get that for testing.  If it passes your initial sanity check, it
should go into HEAD for community testing; if not, we need to report that to
Avalon ASAP.  When the RC becomes a Release, that goes into HEAD.  Does that
make sense?
Yep - that's consitent with the policy I've been applying.  My only concern
is that there is an overlap between jars used as part of the Phoenix
distribution that are also used or implied by the James distribution. It's
this area that I want to get some confirmation form Phoneix developers as
James HEAD requires later versions of jars than those available under
Phoenix.  The current build addresses this by included the dependent jars
into the James sar - and this seems to work without problem.
Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon Jars

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

If we can verify that the new jars (with Phoenix, not just Merlin) are
working as well as the old (unknown vintage) ones, is there any reason not
to do a cvs remove of the unused jars?  AFAIK, we are committed to moving
forward in HEAD.  I put the released logkit v1.2 jar into phoenix-bin/lib
when the vote came through, so that's updated, and I believe that it just
makes sense to clean up the files in HEAD.
 


I've just completed test of the current Phoenix dist (in the James CVS)
against the James sar file and that passed OK (i.e. James in Phoneix as is
appears to be working fine). The one file that can be safely removed is
cornerstone.jar (its not referenced by anything).  The rest are related to
the Phoenix implementation and I would really need to get some advice on
what can be replaced here.

Cheers, Steve.


	--- Noel

-Original Message-----
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 21, 2003 12:36
To: James Developers List
Subject: Re: Avalon Jars




Danny Angus wrote:

 

Guys,

I just did a clean checkout of the HEAD and dicover that theres a big load
   

of avalon jars in three seperate places,
 

/lib
/lib/candidates
/phoenix-bin/lib

Now HEAD builds and runs, but its impossible to develop because there are
   

conflicting classes in these avalon jars, and no clear indication of which
should be on the classpath and which are redundant.
 

Stephen, if you read this could you help please...

   


Sure - I'm going to update the project.class.path to use the explicit
declarations from the default.properties file.  This will ensure that
there is one and only one reference point for the identification of the
jars in use.

Cheers, Steve.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon Jars

[Stephen McConnell]

Stephen McConnell wrote:




Danny Angus wrote:


Guys,

I just did a clean checkout of the HEAD and dicover that theres a big 
load of avalon jars in three seperate places,

/lib
/lib/candidates
/phoenix-bin/lib

Now HEAD builds and runs, but its impossible to develop because there 
are conflicting classes in these avalon jars, and no clear indication 
of which should be on the classpath and which are redundant.

Stephen, if you read this could you help please...


Sure - I'm going to update the project.class.path to use the explicit 
declarations from the default.properties file.  This will ensure that 
there is one and only one reference point for the identification of 
the jars in use.


Ok - that's done - next step is to synchronize the phoenix-bin directory.  
That's going to take a little more time - I'll try to take care of that 
tommorow.

Steve.



Cheers, Steve.




d.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon Jars

[Stephen McConnell]

Danny Angus wrote:


Guys,

I just did a clean checkout of the HEAD and dicover that theres a big load of avalon jars in three seperate places,

/lib
/lib/candidates
/phoenix-bin/lib

Now HEAD builds and runs, but its impossible to develop because there are conflicting classes in these avalon jars, and no clear indication of which should be on the classpath and which are redundant.

Stephen, if you read this could you help please...



Sure - I'm going to update the project.class.path to use the explicit 
declarations from the default.properties file.  This will ensure that 
there is one and only one reference point for the identification of the 
jars in use.

Cheers, Steve.



d.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] Avalon Framework Release Candidate 4

[Stephen McConnell]

Noel:

Already confirmed - I've been running James with framework 4.1.4
without problem (including clean build of James against the 4.1.4
version).
Cheers, Steve.

Noel J. Bergman wrote:

Stephen,

Can you verify if this version is working well with James HEAD?

	--- Noel

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-james/src/java/org/apache/james James.java

[Stephen McConnell]

Darrell DeBoer wrote:


On Mon, 17 Feb 2003 23:18, [EMAIL PROTECTED] wrote:
 

  /**
 - * @see
org.apache.avalon.framework.service.ServiceableServicable#service(ServiceMa
nager) + * @see
org.apache.avalon.framework.service.Serviceable#service(ServiceManager) */
   


Whoops. Fixed a javadoc tag, and made it even worse. 


I figured it was a reference to a *highly*-serviceable component!

:-)



Thanks for picking that 
up.

 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

/proposal - what's the status

[Stephen McConnell]

Hi everyone:

Just did a search through the jakarta-james/proposal/** directories for 
the extent of files that need to be taken care of in terms of CM-->SM 
transition. Initial inspection shows 18 files. However - before doing 
anything - there are some questions:

 1. is code in the proposals/ packages "alive-and-well"
 2. do proposal sub-packages (imap, rmiremote, etc.) correspond to
anyone in particular (I'm thinking about liaison before fixing)
 3. do we care about migration of this content

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: imap2 - DataSourceSelector not found

[Stephen McConnell]

Kenny:

I have not made any changes to the proosal directory - in fact I have 
not even looked in there so it is reasonable to assume that the changes 
to head and build could have broken something.In the case referenced 
below the ...datasources.DataSourceSelector is in one of the jar file in 
lib/candidates so probably all that is needed is to update whatever buid 
your using.  Sorry I'm can't be more helpful but I'm deep in a bunch of 
Merlin changes for the moment - but should be more attentive later in 
the week!

Cheers, Steve.


Kenny Smith wrote:

Hi all,

I sat down to start work on imap2 again this morning, but the proposal
cannot find
org.apache.avalon.cornerstone.services.datasources.DataSourceSelector. That
seems to be the right class name according to the viewcvs on apache, does
the new james include libs that the imap2 propsoal doesn't have? It may just
be too early in the morning, but I'm having trouble finding them, so I
figured I'd ask and cut to the chase.

Kenny Smith


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Phoenix updates complete

[Stephen McConnell]

Noel J. Bergman wrote:


Would you please recheck?  I cannot do a build of HEAD.
 

My mistake - fixed - two files added to lib/candidates.
   


OK, I can build HEAD again.  Can't say if it runs (am running tests on
v2.1.1a7), but it builds again.  :-)



Remomber -to use test.xml for running the test (I havn't finished the 
updating of the build file in the test directory yet).

$ cd tests
$ ant -buildfile test.xml

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Phoenix updates complete

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

Would you please recheck?  I cannot do a build of HEAD.  I have done both a
cvs update -Pd, and finally deleted both lib/ and phoenix-bin/ just to be
sure.  For one thing, I don't see some of the updated excalibur jars, and I
do see old ones.
 


My mistake - fixed - two files added to lib/candidates.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-james build.xml

[Stephen McConnell]

Noel J. Bergman wrote:


There are libraries that we are likely to need to remove from the CVS,
specifically, mail_1_3.jar and activation.jar.  We are allowed to put them
in the builds, but not in the CVS, apparently.  What I have in mind is
modifying .cvsignore and the Ant scripts so that if they are not present,
the Ant script tells the user that they need to be downloaded, and from
where.  The .cvsignore will keep cvs from trying to put them back in the
module.
 


Noel:

I've put in place Leo's script that puts up details of where to download 
javamail and activation.  If you want to see it in action - just rename 
either of these resources in james/lib you will get the details of where 
to download and the license location.  I havn't done the stuff related 
to .cvsignore - maybe we can get to that later (I think it's a good idea).

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-james build.xml

[Stephen McConnell]

Thanks Leo!

Leo Simons wrote:


get

http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent
http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.properties

put them in james cvs, modifying them to include additional 
information about the jars james needs (mostly very simple 
cut-n-paste). Then update the james build.xml to kinda macro-include 
check-targets.ent. Some info on that in check-targets.ent itself. Also 
see

http://cvs.apache.org/viewcvs.cgi/avalon/build.xml.diff?r1=1.159&r2=1.160&diff_format=h 


where I implemented this for avalon.

Notes:
- it is cleaner and neater to move to maven :D
- licenses currently fetched from the OSI site, the maven
  repo will get updated to have the licenses there, and
  the script should be too

cheers,

- Leo

Pseudo-build-file to give more ideas:


  

  ]>















&check-targets;























destdir="${target.classes}"
debug="${debug}"
optimize="${optimize}"
deprecation="${deprecation}"
target="1.2">



unless="logkit.present"/>

unless="logkit.present"/>

unless="log4j.present"/>

unless="logkit.present"/>

unless="logkit.present"/>

unless="jdk14.present"/>

unless="commons-logging.present"/>









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-james build.xml

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

Would you please do us a favor while you are re-organizing the Ant scripts?

There are libraries that we are likely to need to remove from the CVS,
specifically, mail_1_3.jar and activation.jar.  We are allowed to put them
in the builds, but not in the CVS, apparently.  What I have in mind is
modifying .cvsignore and the Ant scripts so that if they are not present,
the Ant script tells the user that they need to be downloaded, and from
where.  The .cvsignore will keep cvs from trying to put them back in the
module.

I'm not an Ant maven (pun somewhat intended), and you seem to know what
you're doing with it.



ROTFL ... !!!

I'll check with Leo Simons - he's someone who really knows what he's 
doing :-)

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Phoenix updates complete

[Stephen McConnell]

Hi everyone:

Have just updated the buildfile with some changes to the prepare-phoenix 
task.  These changes include the following:

 1. ensures that excalibur-thread-1.1 is placed in the phoenix/lib
directory instead of the 1.0 version
 2. ensures that ecalibur-pool-1.2 is placed in the phoenix/lib
directory (required by thread 1.1) instead of 1.0
 3. adds the commons-collections-2.1 jar to phoenix/lib (required
by pool 2.1)

The changes to thread 1.0 -> 1.1 include the bug fix concernign the max 
pool parameter.  The 1.1 version introduces the dependency on pool 1.2 
which in turn has been recently updated with the replacement of the 
depricated excalibur-collections with commons-collections library.  All 
of the above are on the Avalon Considated Release schedule so we should 
be able to lock onto released content reasonably soon.

I've tested all of the above and everything is working fine.

I also updated the formatting in the buildfile to make it easier to read 
and shifted property declarations into default.properties (hope that's 
ok).  Based on these changes - the build file I was using is now 
redundant (james.xml and james.properties), however, I suggest we leave 
it there until I've cleaned up the test build file.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EXCALIBUR] threads - ConcurrentModificationException

[Stephen McConnell]

Stephen McConnell wrote:




Harmeet Bedi wrote:


- Original Message -
From: "Stephen McConnell" <[EMAIL PROTECTED]>
 

Have just confirmed this with a test run under Merlin - not problems.
Everything running perfectly!
  



Stephen,
Do you have an ETA on when tests would work with Phoenix ? From your cvs
comments it looks like Phoenix is broken.



Its's fixed - Paul posted an email earlier to the dev list noting that 
the release branch is updated to include excalibur-thread-1.1 and that 
he's tested this against the cornerstone component and everything 
appears to be working properly. I need to check a couple of things 
with Paul first - but if I understand things correctly the current 
version Phoenix in James just need the excalibur-thread-1.1 package 
update - but like I said - I want to check with Paul first. 


Quick update:

I'm currently sorting though things in the James/Phoenix scenario and I 
have a running solution which passes the test case.  The changes 
required to the Phoenix distribution (lib directory) include:

 1. replacement of excalibur-thread-1.0 with 1.1
 2. replacement of excalibur-pool-1.0 with 1.2
 3. addition of commons-collections-2.1.

I'm about make these changes to HEAD and in the meantime I'll liase with 
Paul to make sure that this is synchronized with the next release of 
Phoenix.  This gets us into a working and deployable system with a 
specific change-list.


Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [EXCALIBUR] threads - ConcurrentModificationException

[Stephen McConnell]

Harmeet Bedi wrote:


- Original Message -
From: "Stephen McConnell" <[EMAIL PROTECTED]>
 

Have just confirmed this with a test run under Merlin - not problems.
Everything running perfectly!
   



Stephen,
Do you have an ETA on when tests would work with Phoenix ? From your cvs
comments it looks like Phoenix is broken.



Its's fixed - Paul posted an email earlier to the dev list noting that 
the release branch is updated to include excalibur-thread-1.1 and that 
he's tested this against the cornerstone component and everything 
appears to be working properly. I need to check a couple of things with 
Paul first - but if I understand things correctly the current version 
Phoenix in James just need the excalibur-thread-1.1 package update - but 
like I said - I want to check with Paul first.

I am not sure what Merlin Install means. Is it build and add jar files from
an Avalon source tag ?



A Merlin install means following the directions in the THE_RED_PILL.TXT

http://cvs.apache.org/viewcvs/avalon-sandbox/merlin/THE-RED-PILL.TXT
I.e. for the moment - you need to build a bunch of things from CVS. 
There is not binary download. A maven based build in in progress which 
will simplfy things a lot (but its not there yet). And as the document 
states - if you try Merlin - you probably like living on the edge ;-)

Phoenix has been James' container, and would like to avoid different
containers unless of course the Avalon folks recommend that James should use
one container over other.
Avalon seems to have 4 containers - Phoenix, Merlin, Fortress, Tweety(toy,
not functional). Earlier there was only one - Phoenix. I feel, James should
stick with one container.



Of the container you have listed - only two are capable of dealing with 
the James component model. These include Phoenix (released) and Merlin 
(pre-release and under active development). There is a roadmap within 
Avalon that basically lays out the convergence of Merlin, Phoenix and 
Fortress, leading to a single container solution.

With respect to James - I'm not making any suggestions about what James 
should or should not do concerning containers - with the single 
exception that I have and will probably continue to encourage a 
container neutral approach in the code. Keep in mind that there are two 
parts to James - one is James as a component - the other is James as a 
deployed package (James component + Phoenix + James/Phoenix deployment 
directives). I'm interested in James as the component because I want to 
be able to use the James component as the enterprise messaging solution 
with other components I'm working on. These components require a 
containment environment that lets me package and expose James services 
to other components (e.g. web-servers, PKI systems, business objects, 
community and collaboration frameworks, etc.). EMail management is an 
important part of that equation and the basis for my interest in James 
and its development.

A second aspect concerns Merlin development itself. Merlin basically 
provides support for a composite component management where a system 
like James can be packaged as a regular component. This means that I can 
take the entire James platform and transport it into a component 
exposing a specific set of services. Merlin does this by separating the 
implementation (a component/container hierarchy) from the services 
published by the component. The "implementation" separation is complete 
and operational, however, work is ongoing concerning the encapsulation 
side. Having the potential to test and validate Merlin against the James 
component is a major plus for Merlin development - it's already resulted 
in the identification and resolution of a number of issues and some 
important improvements to the code base.

In relation to James direction and policy ... my interest should 
absolutely not conflict with the James project usage of Phoenix or the 
overall James containerment strategy. In fact, if you asked me to select 
a container for James - I would recommend Phoenix relative to the 
objective of delivering a deployable electronic messaging platform. 
However - if you need to be able to embed James into another 
environment, or create a component that has a dependency on James - then 
the containment subject takes on a new perspective.

Personally I think it is absolutely *brilliant* that James (the 
component) can be deployed in more than one container. It demonstrates 
that the James component design is successful and that forward looking 
evolution is likely to be achieved with even greater confidence.

Hope that clarifies my point of view.

Cheers, Steve.


Harmeet

- Original Message -
From: <[EMAIL PROTECTED]>
Subject: cvs commit: jakarta-james james.xml james.properties
 

.
 +Running the generated sar file inside the releaed Phoneix will result
   

in an error relating to the thread package.  Changes to

Re: [EXCALIBUR] threads - ConcurrentModificationException

[Stephen McConnell]

Super!

Have just confirmed this with a test run under Merlin - not problems.
Everything running perfectly!

Cheers, Steve.



Noel J. Bergman wrote:


Found it.  Fixed it.  I had actually looked right at it recently, and not
seen it.

Here is the code:

   public Iterator list() {
   // Fix ConcurrentModificationException by cloning
   // the keyset before getting an iterator
   final HashSet clone = new HashSet();
   clone.addAll( keys );
   return clone.iterator();
   }

Well, then you look at the definition of keys:

   keys = Collections.synchronizedSet(new HashSet());

No problem.  Everything is synchronized.

WRONG!  The addAll operation isn't synchronized against the collection
passed as a parameter!  Each atomic operation on it was synchronized, but
not the clone!

	--- Noel

-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 08, 2003 2:41
To: James-Dev Mailing List
Cc: Avalon Developers List
Subject: RE: [EXCALIBUR] threads - ConcurrentModificationException


Stephen,

LOL!  Thank you, thank you!

I have been looking for that exception.  It had been previously marked as
"impossible", and the exception was discarded.  I fixed that just the other
day.  Now I can try to find and fix the bugger.

	--- Noel

-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 08, 2003 2:05
To: Avalon Dev
Subject: [EXCALIBUR] threads - ConcurrentModificationException



A java.util.ConcurrentModificationException is occured while
running James with the excalibur-thread-1.1.jar.
I'm guessing this is a result of recent changes. Any ideas?

Cheers, Steve.


[INFO   ] (container.smtp): Connection from localhost (127.0.0.1)
[ERROR  ] (container.mailstore): CME in spooler - please report to
http://james.apache.org
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:762)
at java.util.HashMap$KeyIterator.next(HashMap.java:798)
at java.util.AbstractCollection.addAll(AbstractCollection.java:315)
at
org.apache.james.mailrepository.AvalonMailRepository.list(AvalonMailReposito
ry.java:389)
at
org.apache.james.mailrepository.AvalonSpoolRepository.accept(AvalonSpoolRepo
sitory.java:47)
at
org.apache.james.transport.JamesSpoolManager.run(JamesSpoolManager.java:268)
at
org.apache.excalibur.thread.impl.ExecutableRunnable.execute(ExecutableRunnab
le.java:90)
[INFO   ] (container.smtp): Successfully spooled mail from
postmaster@localhost for [test@localhost]
[INFO   ] (container.smtp): Successfully spooled mail from
postmaster@localhost for [test@localhost]


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CM/SM/Cornerstone migration

[Stephen McConnell]

Hi everyone:

The James HEAD is now updated to include the following changes:

  1. transition from ComponentManager to ServiceManager
  2. update to use the CR cornerstone packages (see lib/candidates)

I started off with a seperate buildfile (james.xml and related 
properties file james.properties) and its working fine. I've also 
updated the standard buildfile so that it includes the cornerstone 
candidate jars.

Here is a summary of results under the Merlin and Phoenix containers:

 MERLIN: test completes sucessfully - however I'm seeing a
 ConcurrentModificationException caused by the excalibur-thread-1.1
 package (have already posted info on this to Avalon Dev). Aside
 from that - everyting is working properly.  If you want to do the
 same thing - please read the README.txt in the /tests directory.

 PHOENIX: out of the box deployment isn't possible due to a conflict
 related to excalibur-1.0 versus 1.1. The solution is to upgrade
 Phoneix to 1.1 (both in terms of building and libraries).  Presumably
 this will occur once we have excalibur-thread-1.1 released, however,
 there appears to be another problem in that even though I've included
 1.1 in the James lib (sar file), the Phoenix version is being used.
 I've posted a note on this to Avalon Dev as well.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

HEAD build failure

[Stephen McConnell]

In the process of synchronizing my local sources with the latest Jaes 
HEAD, I cam across the following problem:

The initialize method in the org.apache.james.fetchmail.FetchScheduler 
contains a reference to the state member "fp" which is underclared.  I'm 
not sure what is intended here - could someone take care of this or 
suggst the update needed.

Cheers, Steve.


   /**
* @see org.apache.avalon.framework.activity.Initializable#initialize()
*/
   public void initialize() throws Exception {
   enabled = conf.getAttributeAsBoolean("enabled", false);
   if (enabled) {
   scheduler = (TimeScheduler) 
m_manager.lookup(TimeScheduler.ROLE);
   Configuration[] fetchConfs = conf.getChildren("fetch");
   for (int i = 0; i < fetchConfs.length; i++) {
   FetchMail fetcher = new FetchMail();
   Configuration fetchConf = fetchConfs[i];
   String fetchTaskName = fetchConf.getAttribute("name");
   
fetcher.enableLogging(getLogger().getChildLogger(fetchTaskName));
   fetcher.service( m_manager );
   fetcher.configure(fetchConf);
   Integer interval = new 
Integer(fetchConf.getChild("interval").getValue());
   PeriodicTimeTrigger fetchTrigger = new 
PeriodicTimeTrigger(0, interval.intValue());
   scheduler.addTrigger(fetchTaskName, fetchTrigger, fp); 
// < FP UNDEFINED
   theFetchTaskNames.add(fetchTaskName);
   }
   getLogger().info("FetchMail Started");
   } else {
   getLogger().info("FetchMail Disabled");
   }
   }


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon and James (was JNDI for James)

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

Do you want to reapply to CVS HEAD?  Also, see if the changes I made today
fix your looping problems.



I'll commit and let kou know the result status.



A request for your commit karma was sent off earlier today.  I just did a
grep of avail; you aren't in there just yet.  If you reapply the patches
against HEAD, and still don't have karma when you're ready, send me the cvs
diff -u, and I'll apply from my side.
 


Looks like everything is in place.


Do we also need to pull in any of the release candidates?  What is ready for
release testing?



The build includes the updated cornerstone coponents which include the 
bug fix on the pool max size.  This means that we need to build against 
some of the Excalibur candidate releases.  To make this process 
manageble I put in place a alternative build file that uses jar 
pathnames established in a properties file - which makes life a lot 
easier to swich the source of jar files your testing against.

Here is the list of candidates I'm building against:

  

  


  
  
  
  
  
  


  
  
  
  


  
  

  

There are also implicit jars that are made available by the container 
(such as excalibur-threds, excalibur-pool, etc.).  I'll pull a list of 
these together for both Phoenix and Merlibn scenarios.

Cheers, Steve.


	--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Welcome New Committer, Stephen McConnell

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

Yes, this is your notice (if you haven't already heard from root), that you
now have karma to the jakarta-james CVS module.

We are looking forward to working with you.  :-)



Thanks!

I'll be getting started on the updates (CM->SM) later this evening.

Cheers, Steve.



	--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Avalon and James (was JNDI for James)

[Stephen McConnell]

Diff from a snapshtop that's probably a couple of weeks old against the 
current CVS HEAD.  That will give you an idea of the changes - nothing 
interlectual - just replacements of CM with SM, CE with SE, etc.  Pete 
basically did the same thing but against 1.2 so its doubtful that 
anything in the diff will help - but here it is anyway.

Cheers, Steve.

p.s. The modification to the testcase (the very last entry) is a hack to 
eliminate the problem of the testcase killing the test user while the 
spool is busy writing messages to that user.

[EMAIL PROTECTED] wrote:


Can you send the patch of your changes to list. It seems to be that the best course is commit to head, have a regression or two for some time, let everybody test and fix it. Infinite loop problem should be easy to track down.



Index: src/Manifest.mf
===
RCS file: /home/cvspublic/jakarta-james/src/Manifest.mf,v
retrieving revision 1.6
diff -r1.6 Manifest.mf
4,35d3
< Name: org/apache/james/James.class
< Avalon-Block: true
<
< Name: org/apache/james/core/AvalonMailStore.class
< Avalon-Block: true
<
< Name: org/apache/james/core/AvalonUsersStore.class
< Avalon-Block: true
<
< Name: org/apache/james/nntpserver/NNTPServer.class
< Avalon-Block: true
<
< Name: org/apache/james/nntpserver/repository/NNTPRepositoryImpl.class
< Avalon-Block: true
<
< Name: org/apache/james/smtpserver/SMTPServer.class
< Avalon-Block: true
<
< Name: org/apache/james/pop3server/POP3Server.class
< Avalon-Block: true
<
< Name: org/apache/james/remotemanager/RemoteManager.class
< Avalon-Block: true
<
< Name: org/apache/james/dnsserver/DNSServer.class
< Avalon-Block: true
<
< Name: org/apache/james/transport/JamesSpoolManager.class
< Avalon-Block: true
<
< Name: org/apache/james/nntpserver/AuthServiceImpl.class
< Avalon-Block: true
cvs server: Diffing src/conf
Index: src/conf/james-assembly.xml
===
RCS file: /home/cvspublic/jakarta-james/src/conf/james-assembly.xml,v
retrieving revision 1.13
diff -r1.13 james-assembly.xml
37c37
<  
role="org.apache.avalon.cornerstone.services.datasource.DataSourceSelector" 
/>
---
>  
role="org.apache.avalon.cornerstone.services.datasources.DataSourceSelector" 
/>
117c117
<  
role="org.apache.avalon.cornerstone.services.datasource.DataSourceSelector" 
/>
---
>  
role="org.apache.avalon.cornerstone.services.datasources.DataSourceSelector" 
/>
126c126
<  
role="org.apache.avalon.cornerstone.services.datasource.DataSourceSelector" 
/>
---
>  
role="org.apache.avalon.cornerstone.services.datasources.DataSourceSelector" 
/>
158c158
<  
class="org.apache.avalon.cornerstone.blocks.datasource.DefaultDataSourceSelector" 
/>
---
>  
class="org.apache.avalon.cornerstone.blocks.datasources.DefaultDataSourceSelector" 
/>
cvs server: Diffing src/java
cvs server: Diffing src/java/org
cvs server: Diffing src/java/org/apache
cvs server: Diffing src/java/org/apache/james
Index: src/java/org/apache/james/James.java
===
RCS file: 
/home/cvspublic/jakarta-james/src/java/org/apache/james/James.java,v
retrieving revision 1.43
diff -r1.43 James.java
35,39c35,38
< import org.apache.avalon.framework.component.Component;
< import org.apache.avalon.framework.component.ComponentException;
< import org.apache.avalon.framework.component.ComponentManager;
< import org.apache.avalon.framework.component.Composable;
< import org.apache.avalon.framework.component.DefaultComponentManager;
---
> import org.apache.avalon.framework.service.Serviceable;
> import org.apache.avalon.framework.service.ServiceManager;
> import org.apache.avalon.framework.service.DefaultServiceManager;
> import org.apache.avalon.framework.service.ServiceException;
79,80c78,79
< implements Contextualizable, Composable, Configurable, JamesMBean,
 implements Contextualizable, Serviceable, Configurable, JamesMBean,
>Initializable, MailServer, MailetContext {
90c89
< private DefaultComponentManager compMgr; //Components shared
---
> private DefaultServiceManager compMgr; //Components shared
201c200
<  * @see 
org.apache.avalon.framework.component.Composable#compose(ComponentManager)
---
>  * @see 
org.apache.avalon.framework.service.Servicable#service(ServiceManager)
203,204c202,203
< public void compose(ComponentManager comp) {
< compMgr = new DefaultComponentManager(comp);
---
> public void service( ServiceManager comp) {
> compMgr = new DefaultServiceManager(comp);
344c343
< compMgr.put( "org.apache.mailet.UsersRepository", 
(Component)localusers);
---
> compMgr.put( "org.apache.mailet.UsersRepository", localusers);
369c368
< // For AVALON aware mailets and matchers, we

Re: Avalon and James (was JNDI for James)

[Stephen McConnell]

Hi Noel:

Noel J. Bergman wrote:


At the same time it would be a lot more helpful to the process
in James were in sync.  While I understand that this is not on
the James short list of priorities



Excuse me?  Where did that come from?  

 
Read the thread ... :-)


I thought that we were cooperating with you.



There are a bunch of things going on - Avalon is starting is rollout of 
release, within a few weeks we will be hitting the Cornerstone content 
relase process which concerns James more than any other project.  That 
realese process is (from my point of view) is very much about supporting 
the excalation of James. However, this, again "from my point of view" 
needs an active process so we can get James in shape before release 
condidates start comming out of Avalon.  This has nothing to do with 
what version James locks into - it about enabling a mechanisms whereby I 
can validate the candidates I'll signing off on.  To do that we need up 
rollup James from CM-to-SM, sort out an identified loop, and arrive at a 
platform against which we can do some real evaluation.

My understanding, Stephen, was that you were working on the changes, and I
have been watching the various parts of Avalon go into a release cycle.  My
impression was that we had agreed to pickup those parts as they became
release eligible (and, as you know, there is a fix in logkit 1.2
specifically because of James), and that you were in the process of making
the necessary code changes (e.g., CM -> SM).



First cut on the CM-SM transition was coplete one month ago (today). 
That process raised issues that after a couple of weeks were resolved 
down to being a combnination of somethig strage in James CVS head (the 
looping problems), combnined with some bugs inthe James test code, + 
probably issue relative the current Excalibur candidate releases on the 
thread and pooling areas.  A second cut at the transition was applied 
against Pete' James variant which proved to be totally succesfull - in 
fact it was this process that identifies that there is a definitate 
problem in James CVS head (which I presume still exist) and the the 
issues are indepent of the CM-SM migration. To be frank, I was hoping we 
would have cleared these things before the release process started over 
on Avalon.



Do you have the code changes ready?



They have been ready for at least four weeks.  But to be honest - it't 
only in the last two weeks that I've know that it isn't the code change 
that is problamatic - it's the transition/target combination that is the 
area of interest/concern - and that's the thing I've been asking for 
support on - i.e. there is something problamatic in the James CVS head 
releative to the current builds.  Resolving/identifying this IHVHO is a 
prerequisite to Avalon Excalibur and Corenerstone realese candidate 
evalutation.  I suspect there are problems low down but I've aleady been 
through the process of validating tbis on at least four seperate 
occasions.  If I run either Phoneix or Merlin using the release 
candidate (and related candidates, etc.) I end up in an infite loop 
inside James.  This is somethig wrong and it needs to be fixed before 
the Avalon RC process for Exclibur and Cornerstone can really rolls into 
place.


Oh, that reminds me ... Serge, didn't we pass a vote to give Stephen commit
rights?  Do you need to verify the vote count, and submit a request to
infrastructure or root?



Nothing as yet.

Commit privs or a target to send a zip/diff to - whatever - I don't mind.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JNDI for James

[Stephen McConnell]

Harmeet Bedi wrote:


- Original Message -
From: "Aaron Knauf" <[EMAIL PROTECTED]>


... we will need to agree on the correct way
to establish this dependency.

Two things seem obvious to me here:

  1. We don't want to depend on the whole tomcat project just to get
 the Naming stuff.



It may be a good idea to get on naming/tomcat mailing list push them to do
stable releases. If they realize other projects depends on it, they should
be happy do a snapshot build for the naming libraries. Working against CVS
seems like a moving target.



  2. We don't want to get stuck in an obsolescent rut, as we are with
 our stone age Avalon release.




Avalon release have been mostly driven by Avalon developers and James folks
have just gone along. I really don't think there has been a strong need to
upgrade. If there pain there(although to me it seems moderate to low) maybe
James should just be more James oriented on when and how we upgrade naming
libraries.



Harmeet:

I think the question of "James synchronization" is bigger than the point 
concerning naming.  If Aaron puts time and effort into a new service - 
he has to take into consideration the constrains implied by the James 
"obsolescent rut".  If you developing new components to work with James 
this can be a real issue (read "obstacle to James adoption"). Over in 
Avalon there is process to bring out releases of everything that James 
is theoretically dependent on.  At the same time it would be a lot more 
helpful to the process in James were in sync.  While I understand that 
this is not on the James short list of priorities - the lack of 
synchronization has a real detrimental impact.  As long as James remains 
out of sync., James remains out-of-scope for many potential users.

There are two ways to bring James in sync.

 (a) via collaboration - i.e. updated James CVS HEAD and validate current
 candidates - so you know what's happening, and the Avalon guys will
 knows what's happening

 (b) wait for formal releases then you guys do the work of bringing
 yourself up-to-date - and if there is a problem with any of the
 release content, then - yes - Avalon will sort the issue

One of these approaches is about "partnership" and one is about being a 
"user".  Personally I prefer the the "partnership" approach. I think 
it's more constructive, healthier and at the end of the day - more fun! 

Cheers, Steve.



Harmeet




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JNDI Mailet Configuration

[Stephen McConnell]

Noel J. Bergman wrote:


You have lost me - can you expand on something for me?
  Context myContext = new InitialContext();
How does a container control what is in the instance myContext?



The container can establish both the implementation and population of the
initial context.  To do this per component is a bit more of an issue.



Its the per component subject I'm thinking about.



One solution involves playing with
NamingManager.setInitialContextFactoryBuilder().  You can also play around
with classloaders.  If this were really of interest, we can snarf code from
Tomcat, which supports per-webapp contexts, as I understand it.



This seems terribly complicated as compared to the approach of a 
component declaring what it needs, and the container supplying this via 
some method.

However, my proposal wasn't an attempt to implement IoC.  Servlets don't see
separate contexts, and that is the model closest to the Mailet API.



I though we were discussing the mailet API - I'm kind of not sure if I'm 
talking about things that have been set in concrete or not - 
clarification on this would be helpful.  I'm personally not convinced 
that strait out following of the servlet API is the best thing - in fact 
I think we can do better than that.  What I am very interested in is the 
contract between a mailet and its container (which is more than the 
Mailet API itself).  My impression is that part of the puzzle is largely 
missing.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JNDI Mailet Configuration

[Stephen McConnell]

Aaron:

You have lost me - can you expand on something for me?

  Context myContext = new InitialContext();

How does a container control what is in the instance myContext?

Cheers, Steve.


Aaron Knauf wrote:




Nicola Ken Barozzi wrote:



This is not true IOC. The Mailet asks for something, it is not given it.
IOC in practice means that the container calls a method on the child. 
This is not the case here... 


:-)

From my previous post - "My current thinking is closer to IOC than to 
pull, but not entirely the same."   ...   "IOC is there in spirit".

The calling of a particular method on the child is an implementation 
detail.  The salient point in my proposal is that the container is 
still in control of what resources the Mailet has access to, because 
it has to put them in the mailet's context.

I agree that this is not true IOC, as defined by the Avalon designers, 
however the major benefit (having the container maintain control of 
resources used by the component) is still there - I just have a 
different way of achieving it.

One thing I like about this is the huge scope that container 
implementers have for providing access to value-add features.  The 
ability to pull an actual DataSource out of the context, rather than 
just a JDBC url is a good example.  On the surface, this may seem 
like an invitation to sabotage mailet portability.  I think that 
quite the opposite is true. 



Then this is not a configuration, but a ComponentManager. Avalon has 
separated the concepts, here they are intermixed.

There is a place when this still happens which is the Context, but 
it's also the most controversial part of the Framework and the most 
unportable one. This is basically a Context as I see it.

Yes, this is basically a context.  I do not believe that this is a bad 
thing.  We are specifying a contract between the Mailet and its 
Container that says that the mailet container must place everything 
that the mailet desires into the mailet's context.  (Kinda like your 
own personal djinni!)  Essentially, the Context becomes a facade into 
whatever mechanisms the underlying appserver wishes to use to provide 
these resources.

As mentioned in my previous post, I believe that this enhances 
portability.  It does this in the following manner:
1)It uses a standard API (JNDI) for access to resources.  It is 
more reasonable to expect that an alternative mailet container will 
provide JNDI, than it is to expect that the Avalon ComponentManager 
interface will be provided.
2)It provides a layer of indirection between the way that the 
Mailet refers to a resource and the way that an appserver provides 
it.  The container serves as the translator here.

Here is an example of how the ToRepository mailet might differ if 
written with this system

---  Current ToRepository mailet --
public void init() {
   repositoryPath = getInitParameter("repositoryPath");
   try {
   passThrough = new 
Boolean(getInitParameter("passThrough")).booleanValue();
   } catch (Exception e) {
   // Ignore exception, default to false
   }


   try {
   repository = 
getMailetContext().getMailRepository(repositoryPath);
   } catch (MessagingException e) {
   log("Initialisation failed can't get repository 
"+repositoryPath);
   }


   }
-- 



- New ToRepository mailet -
public void init() {
   try {
   Context myContext = new InitialContext();
   passThrough = 
((Boolean)myContext.lookup("passThrough")).booleanValue();
   repository = myContext.lookup("repository");
   } catch (NamingException ne) {
   log("Initialisation failed");
   }
   }
--- 



As you can see, there is now no need to supply the repository name as 
an init param.  The mailet always refers to the repository by the same 
name.  The name will always be unique because each instance of a 
mailet has its own Context and therefore its own namespace.  If you 
have multiple instances of the same mailet, the context for each 
instance is configured separately.  The fully qualified name of the 
context is, of course, different for each instance.

In what way does this reduce portability?  This is certainly more 
portable than using Avalon API's.  It is also completely 
implementation agnostic.  The actual contents of the context may come 
from an XML file, a database, or may be generated on the fly by the 
container, or a combination of all of the above.

Another advantage is that it is easier for new Mailet authors to 
learn, because developers will often already be familiar with JNDI.

I agree that this is a very different approach to that currently used 
by Avalon.  Reproducing Avalon was not (and is not) th

Re: James v3 Requirements and Planning

[Stephen McConnell]

Nicola Ken Barozzi wrote:



Noel J. Bergman wrote:
...


I don't care which container we're operating in.  And people seem fairly
firm regarding a Mailet API that works well within an Avalon 
container, but
is not tied to requiring one.


Stephen , all, we have already discussed this at lengths, and the 
conclusion has been that Mailet API has to be indipendent of Avalon.
This is their community decision, which I totally respect, and that 
has evident good points too.

One thing that has polluted in the past this decision, IMHO, is that 
Avalon can easily be regarded as a whole, and Paul has gone to extents 
to explain this in (painful? ;-P ) detail.

Mixing my views and the results of the James discussion, I have come 
to the personal conclusion that it would be cool to have:

 - mailet API indipendent on Avalon
* very lightweight, no concerns about config, logging, etc
* it makes possibly unportable mailets


I disagree.  I think the approach on the Mailet spec provides the 
highest portability.


 - mailet Avalon profile
* mailets that are also Avalon components, thus gaining
  Avalon features
* mailets can be more portable and feature rich



Provides less portability (because it requires an Avalon aware 
container), but is much more useful (because it leverages a formal 
component model).  

The point not addressed in the Mailet discussion to date is the 
framework for mailet assumptions about the mailet container (Avalon syle 
or any other style).  In particular, the container needs to be able to 
look at a mailet and ask itself - can I run this mailet and provide 
everything it is expecting - OR - a mailet container interface is 
defined across which I can provide an established mailet instance (i.e. 
bypassing an internal James mailet deployment phase).

Cheers, Steve.


1 cent's worth...



--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: James v3 Requirements and Planning

[Stephen McConnell]

Noel J. Bergman wrote:


I'm just not sure what, if anything, to take away from your
comments regarding what we need to do in terms of James
v3 design and implementation.




1. stop being paranoid about dependencies
2. think about users and what they want
3. containers are about delivering value to users
4. there is a lot of scope that we can deal with
5. most of that scope is a container concern
6. if the spec if good then containment solution will be transparent
7. transparence isn't so easy
8. I'm willing and able to contribute to the work
9. just wanted to have more than eight points



I'm not sure what point(s) you're making, in the context of James.  This
isn't a discussion about an Avalon container.  


I'm not talking about Avalon containers.  I'm talking about the Mailet API.


We have domain specific needs
regarding a user data model and message storage model.  Those are key
services provided to the protocol handlers, matchers and mailets.  And
those, in turn, implement the messaging server.

I don't care which container we're operating in.  And people seem fairly
firm regarding a Mailet API that works well within an Avalon container, but
is not tied to requiring one.



The current Mailet API provides a non-dependent interface. That's fine 
but when we consider logging, configuration, dependency management, etc. 
you are talking about mailet architecture - stuff that may not be 
expressed in the Mailet interface but would be expressed in a Mailet 
Architecture Specification. The Specification would/should/could include 
the specification of the container side of the contract - i.e. what 
assumptions can a Mailet author make and what obligations is a Mailet 
container author required to handle.

The reason why I'm thinking about these issues is that I have some 
application scenarios that deal with close integration of business logic 
into a messaging environment.  I'm looking at the James system as a 
platform into which I would be able to dynamically add and remove 
mailets based on higher level components that are managing the James 
system.  At the other end of the spectrum I know I'll have to deal with 
mailets that have complex dependencies which means either plugging in 
mailet load management into James, or, building the mailet and supplying 
the mailet instance to James.

I don't have a good idea of what assumptions are being made on the V3 
definition - but as I mentioned above - I do think we need mechanisms 
that will allow the introduction of rich-Mailet.  This means addressing 
things like I've described above.

I guess this is drawing the distinction between:

  * the Mailet service interface (the minimal non-dependent Mailet API)

  * the Mailet construction model (the aspects dealing with mailet
logging, configuration, composition, etc.)

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: James v3 Requirements and Planning

[Stephen McConnell]

Noel J. Bergman wrote:


It maybe of interest to people here that I am I working on  a container
and part of the requirements I aim to fulfill it to provide a complete
solution to the Mailet container scenario.
   


Well, of course we're interested.  I'm just not sure what, if anything, to
take away from your comments regarding what we need to do in terms of James
v3 design and implementation.



1. stop being paranoid about dependencies
2. think about users and what they want
3. containers are about delivering value to users
4. there is a lot of scope that we can deal with
5. most of that scope is a container concern
6. if the spec if good then containment solution will be transparent
7. transparence isn't so easy
8. I'm willing and able to contribute to the work
9. just wanted to have more than eight points

;-)

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: James v3 Requirements and Planning

[Stephen McConnell]

Noel J. Bergman wrote:


it may be difficult to judge the impact that other aspects of
development have on the Mailet API until those topics are
addressed.
   


Oh, of course.  :-)  We anticipate as best we can when we discuss, but the
best that we can do is identify the directions that we'd like to try.
 


It maybe of interest to people here that I am I working on  a container 
and part of the requirements I aim to fulfill it to provide a complete 
solution to the Mailet container scenario.  In fact - I will be 
promoting the ability to declaring (via a James configuration argument ) 
the container implementation to be used for mailet management.  In case 
your wondering which container I'm talking about - then get yourself 
ready for some blatant advertising - its Merlin!

Lookout world - magic is in the air.

Cheers, Steve.

	--- Noel


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Configuration Subsystem (was Mailet Configuration)

[Stephen McConnell]

Aaron Knauf wrote:




Stephen McConnell wrote:




Aaron Knauf wrote:


I have an idea for addressing this that needs some work, but 
basically it goes like this:
Implement the configuration as an Avalon block.  (I think this is 
the right term, but I am not too familiar with Avalon, so bear with 
me.) This block would basically manage the loading and parsing of 
configurations from any datasource that you want to write a plugin 
for. Components will obtain their configuration from this block. 



Hi Aaron:

I read you email with interest.  Concerning the above paragraph - I 
think it would be preferable for the James system to be acting a 
mailet container and following IOC principals.  This means that the 
container figures out what the mailet needs, pulls it together, and 
supplies it to the mailet.  I.e. the mailet does not need to be 
concerned with "obtaining" the things it needs - instead - it gets 
supplied everything it needs. 



Oh, I agree completely.  I guess I wasn't clear on this point.  I 
expect that the MailetLoader would be the thing parsing the config the 
Mailet configs and handing them to the mailets.  Also, the plugin 
parsers would be called by the configuration manager and handed just 
the part of the config that they are responsible for.

As a matter of fact, I had to learn the hard way the benefits of IOC 
while implementing the config subsystem for my recent project.  I was 
unable to use IOC because I was stuck with an existing server 
implementation that had static getConfig().getThis() and 
getConfig().getThat() calls all over the place.  Making the thing 
re-initialise certain components when the config changed was a nightmare.







A question: should we hook heavily in to Avalon with this thing, or 
should we make it something more portable, that can be used outside 
of Avalon? 




I think there are separate concerns relating to the Mailet API versus 
the container implementation approach.  From everything I've seen 
here the principal is to keep the mailet API as free of dependencies 
as possible. 


This question was never intended to suggest that Avalon APIs might 
make an appearance in the Mailet API.  There needs to be a clear 
delineation between the portable container API and the non-portable 
container implementation.

What I really meant was do we make this whole configuration manager 
thing another james component, so that the James container 
implementation could hook into it without going through Avalon, or do 
we hook in to all of the Avalon APIs that I am sure I will find 
enticing along the way?  This is all behind that Mailet abstraction 
layer.

The other side of that coin is that you end up falling back to the 
lowest common denominator.  The approach I'm working on is to enable 
components (e.g. mailets) to declare a strategy to the container 
(e.g. James) ... i.e. the mailet declares that it is using interface 
X for configuration and the container simply takes care of this 
by selecting and applying an appropriate handler.  This means I can 
write a mailet that uses a Servelt configuration model, or the Avalon 
Configurable interface, or a Mailet special, or whatever.  The mailet 
API remains independent - but I (as a mailet author) can leverage the 
technologies I want. 


H.  I am not sure that I fully follow what you are saying here, 
but I believe I have the gist of it.  When I initially looked into the 
Avalon configuration subsystem, I was disappointed to find that we are 
forced into a quite sizeable Configuration interface for configurating 
our Configurables.  Further, this interface exposed XML-specific 
namespace stuff to the Configurable, when (IMHO) that ought to be an 
implementation detail used by the parser when reading the config.xml 
and creating the Configuration impl. 


I'm not familiar with the XML-specific namespace stuff - but I do know 
the there is broad support for the Configuration interface.  It is 
simply really really nice to work with.  If the Mailet API comes up with 
something new - I really hope it looks and smells like the Avalon 
Configuration interface.

If you are suggesting that Configurables might be able to get fed an 
arbitrary configuration object in future, (possibly implementing a 
smaller interface to allow the framework to handle it,) then that is 
great news.  

I'm suggesting that a component (using information declared in meta 
data) declares what its configuration contract is.  The container simply 
resolves that depedency. Keep in mind that this direction is much more a 
Merlin specific thing - but on the other hand the Avalon peeps are 
actively discussing such radical stuff over on avalon-dev.

Perhaps you might consider my proposed configuration manager as an 
implementation for driving this? 


Consider it as considered.  If you make this a component (Phoenix Block) 
it will automatically work in Merlin.

If so, I would suggest that -
a)The

Re: Configuration Subsystem (was Mailet Configuration)

[Stephen McConnell]

Aaron Knauf wrote:


I have an idea for addressing this that needs some work, but basically 
it goes like this:
Implement the configuration as an Avalon block.  (I think this is the 
right term, but I am not too familiar with Avalon, so bear with me.) 
This block would basically manage the loading and parsing of 
configurations from any datasource that you want to write a plugin 
for. Components will obtain their configuration from this block. 

Hi Aaron:

I read you email with interest.  Concerning the above paragraph - I 
think it would be preferable for the James system to be acting a mailet 
container and following IOC principals.  This means that the container 
figures out what the mailet needs, pulls it together, and supplies it to 
the mailet.  I.e. the mailet does not need to be concerned with 
"obtaining" the things it needs - instead - it gets supplied everything 
it needs.



A question: should we hook heavily in to Avalon with this thing, or 
should we make it something more portable, that can be used outside of 
Avalon? 


I think there are separate concerns relating to the Mailet API versus 
the container implementation approach.  From everything I've seen here 
the principal is to keep the mailet API as free of dependencies as 
possible. The other side of that coin is that you end up falling back to 
the lowest common denominator.  The approach I'm working on is to enable 
components (e.g. mailets) to declare a strategy to the container (e.g. 
James) ... i.e. the mailet declares that it is using interface X for 
configuration and the container simply takes care of this by selecting 
and applying an appropriate handler.  This means I can write a mailet 
that uses a Servelt configuration model, or the Avalon Configurable 
interface, or a Mailet special, or whatever.  The mailet API remains 
independent - but I (as a mailet author) can leverage the technologies I 
want.


Either way, I would like to use the lastest version of Avalon, to 
avoid being obsolete before I start.


Let me know if you need a hand navigating through all of the Avalon 
stuff.  You may be interested in checking out the Merlin demos - it has 
examples of (a) custom lifecycle strategies, and (b) configuration 
separation - i.e. configuration fragments containing sensitive data are 
separate from the main configuration.  Merlin handles the merging of 
these configurations during deployment.  The main benefits are two fold: 
firstly it enables a very significant simplification of the 
configuration overhead for the user, and secondly, allows separation of 
sensitive information.


Having just successfully implemented a configuration subsystem (with 
pluggable config sources and dynamic reconfiguration) for our SMS 
server at work, I know that this will not be a trivial undertaking.  I 
also have a ton of ideas for how to improve over the last attempt.  
While I am willing to write the code, I do need some indication that I 
am headed in the right direction.  Some helpful advice would also be 
handy (as would any other contributions). 
The code would be written for my own interest, but I would like to 
have the satisfaction of seeing it as part of James when it is done.  
This means getting some buyin from the James community along the way, 
so let me know what you think.


Aside from the IOC issue - a pluggable configuration provider is 
definitely something I would be interested in seeing and using.

Cheers, Steve.


Cheers

ADK



Danny Angus wrote:


Aaron,

You wrote:

 

This subject has come up a few times.  I suggested an approach to 
handling mailet and matcher config better, as did a few others.  I 
even offered to write it.  However, due to the distinct lack of 
enthusiasm for my (or any other) solution, I lost interest.  I could 
be convinced to revisit this if some of the committers indicated 
that they were interested.
  


Without checking I think that the perceived lack of interest was due 
to a deferal of these issues to v3.
Now that v3 is proceding go ahead with it, I'm indicating that I'm 
interested and will support your contribution.
Check the wiki for others' opinions on this (and other) v3 topics, 
and post your ideas, or code, here for discussion & inclusion.

AFAICR we reached some concensus on the following style.. which would 
allow us to produce a processor DTD (example attached) and 
standardise every mailet config.
I can't remember what other suggestions/arguments were raised, but 
you could check the mail archive.



...
   





...











d.
 





 class CDATA #REQUIRED
 name CDATA #REQUIRED
 



 class CDATA #REQUIRED
 



 class CDATA #REQUIRED
 





 name CDATA #REQUIRED
 

 


--

Re: BlockContext introduces Phoenix dependency

[Stephen McConnell]

Exactly!

:-)


Noel J. Bergman wrote:


In which case we need to find another way to get the
path to apps/james, its going to be essential if we're
going to manage to have packaged mailet apps.
   


You mean like o.a.j.context.AvalonContextUtilities? :-)

See:
http://james.apache.org/javadocs/org/apache/james/context/AvalonContextUtili
ties.html

	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: BlockContext introduces Phoenix dependency

[Stephen McConnell]

Noel J. Bergman wrote:


Danny,

 +//Temporary get out to allow complex mailet config files to stop
blocking sergei sozonoff's work on bouce processing
 +attributes.put("confDir",
((BlockContext)myContext).getBaseDirectory().getCanonicalPath()+"/conf/");

This introduces a problem.  BlockContext is Phoenix dependent.  We should
find out from Stephen if there is a portable way to accomplish the same
goal.  I believe that I have code from Peter that removes BlockContext for
the mailet class loader code.  I'll look and see.  I should have time to
start looking at his contributions (tons of new features and enhancements),
and James v3.



It would probably be a best to do the following:

 1. Create: james/util/AvalonConstants.java

  public static final String URN_HOME_DIR = "app.home";

 2. Then update the source

  String path =
((File)context.get(  URN_HOME_DIR  ) ).getCanonicalPath() 
+"/conf/";

Once a standard URN is defined under the framework (or container work) 
we will be able to synchronize containers.  The "app.home" key works in 
both Merlin and Phoenix.  Merlin also supports "urn:avalon:home" - but 
its not Avalon official.

Cheers, Steve.


	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Noel J. Bergman wrote:


[talking as an engineer] The best solution is to make a branch, and give
temporary karma to Stephen to be able to work on that branch.
   


+1

Since we are working on James v3, and not impacting the stable v2 branch,
I'm fine with it.  Plus, this is part of what is being done to produce the
Avalon Coordinated Release build.



I now have two james builds locally on my machine:

 1.  James based on Peter's derivative of 2.1, CM/SM
 migration and Cornerstone candidates in place.
 This is working fine.  Some problems were occuring
 in the test case but we finally narrowed this down
 to a bug in the test case (the test delete's the user
 before the spool completes its work, resulting in
 email in the spool that contain invalid reciipient
 addresses).

 2.  James based on HEAD + CM/SM migration + updates for
 Cornerstone candidates.  This version is doing the
 500 error on "" commands and getting itself into a
 loop.  However, it's fully synced with the HEAD and
 can be committed.

I suggest we go ahead and ties build (2) into head and sort of the 
loop/500 problem from there.


Any idea how far off the ACR is at this point?  


Avalon peeps have been busy getting a lot of little things up-to-date on 
the Excalibur side - thing like version information, manifest and so on. 
Also Gump status across the Excalibur suite is looking much better.  The 
cornerstone candidates need to be updated to create dist targets with 
their doc etc. and respective gump entries.  That will help get James 
Gump running.  The same story applied to Cocoon which is dependent on 
some of the same Cornerstone component as James (but currently tied to 
the entire Cornerstone project).  There have been a couple of updates to 
Excalibur that need to propergeted to applications like Phoenix and 
Cocoon - in particular excalibur-thread-1.1, excalibur-pool-1.2, and 
maybe a excalibur i18n-1.1.  There are some recent framework related 
wrapper classes that have been introduced but can/could/should be moved 
out (more Avalon dev discussion needed).  Aside from that - there is 
formal release process required for excalibur-configuration, 
excalibur-sourceresolver, and possible excalibur-xmlutil.

There is also the question of migration of excalibur-xxx packages to 
commons-.  This has been taken care of for the pool package 
(commons-collection).  There may be a coupe of other packages that 
require transition.  Also, excalibur-cli (used in Phoenix and a couple 
of Excalibur projects) can/should/could be replaced by commons-cli.

i.e. Things are already looking comfortable - and within a few weeks we 
should be able to freeze the release targets and validate things across 
containers, applications and external projects followed by formal 
vote/release/publication.

I'm sure that you'll need to check with Cocoon, Jesktop, and 
other clients, as well as James.
 


Yep - its in progress. Some of the updated in Excalibur are used 
extensively in Cocoon and some of guys on working on the Avalon/Cocoon 
front in much the same we as I'm trying to get James/Avalon in sync.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Noel J. Bergman wrote:


My concern is that we end up relying on this compilation check *at the
expense of other support*.
   


Serge, this ties in with something I've been wondering about, which would be
whether Sam could add JUnit type testing to GUMP.



This can be achieved by declaring the ant target in the gump project 
that includes a JUnit test. I.e. it's an quation of availablity of 
Junity tests withi individual projects.  This does assume that test 
targets are depedent on the general build target.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Stephen McConnell wrote:




Nicola Ken Barozzi wrote:



Thanks for the very detailed and insightful summary.
I understand your views and agree. Just one comment.

Aaron Knauf wrote:


In fact, I believe that we should be very reluctant to change james 
to accomodate changes in avalon cvs unless it is clear that a stable 
avalon release containing those changes will be available before the 
next james release.  As others have mentioned, be don't what to 
block james releases.



Yes, I'm aware of this and it's fundamental. As you can see, Stephen 
is working very hard to make it done sooner than later.

I'd say that intent is quite clear on both sides. Let's resolve 
things one by one as they come. I personally don't think that we 
should copy James stuff in avalon-sandbox, and I'm sure that Stephen 
could be given time-limited karma for changes he has to make.

Stephen has modified code that can be patched on James. It seems he 
really needs a hand in resolving problems, and want you all to try 
the changes and see if you can help.

This can be reasonably done by tagging current James and patching 
HEAD, or making a branch and tagging that.

[talking as an engineer] The best solution is to make a branch, and 
give temporary karma to Stephen to be able to work on that branch. He 
is free to change things, James committers can check changes, and 
current James HEAD is not affected.

Stephen, James guys, what do you think?


Works for me. 
In the meantime Pete Goldstein has been helping out with supplying a 
version of James he has transitioned from CM to SM and that's resolved 
the invinite loop problem (the principal difference here is that 
Pete's version is based on HEAD).  

Woops - correction!
My version was based on HEAD
Peter version is NOT based on HEAD.
Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Nicola Ken Barozzi wrote:



Thanks for the very detailed and insightful summary.
I understand your views and agree. Just one comment.

Aaron Knauf wrote:


In fact, I believe that we should be very reluctant to change james 
to accomodate changes in avalon cvs unless it is clear that a stable 
avalon release containing those changes will be available before the 
next james release.  As others have mentioned, be don't what to block 
james releases.


Yes, I'm aware of this and it's fundamental. As you can see, Stephen 
is working very hard to make it done sooner than later.

I'd say that intent is quite clear on both sides. Let's resolve things 
one by one as they come. I personally don't think that we should copy 
James stuff in avalon-sandbox, and I'm sure that Stephen could be 
given time-limited karma for changes he has to make.

Stephen has modified code that can be patched on James. It seems he 
really needs a hand in resolving problems, and want you all to try the 
changes and see if you can help.

This can be reasonably done by tagging current James and patching 
HEAD, or making a branch and tagging that.

[talking as an engineer] The best solution is to make a branch, and 
give temporary karma to Stephen to be able to work on that branch. He 
is free to change things, James committers can check changes, and 
current James HEAD is not affected.

Stephen, James guys, what do you think?


Works for me.  

In the meantime Pete Goldstein has been helping out with supplying a 
version of James he has transitioned from CM to SM and that's resolved 
the invinite loop problem (the principal difference here is that Pete's 
version is based on HEAD).  So I have something up and running that 
against the Cornerstone release candidate jars.  

I don't have the test case working successfully yet - but I'm a lot 
further ahead than I was a couple of hours ago.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

#2

[Stephen McConnell]

I think some explaining is needed, possibly because I've badly phrased 
the #2 options in prior emails.  The purpose of this email is to 
describe what I think needs to be done at the James level to get James 
properly integrated into Gump so that it provides a good feedback loop.

Now keep in mind that I'm not gump expert - but I'm learning.

Gump lets you invoke an ant project (e.g. the build.xml in James) and in 
doing so, you can direct gump to declare some properties in advance.  If 
the James buildfile were to define the jars it was using as properties, 
then gump can override the James build with jar files generated from 
other projects like DNS, commons, avalon, etc.  Getting the most out of 
gump would require some small updates to the James build procedure:

 1. define a properties file that declares the path to
the released jar files that you use day-to-day (e.g.
stuff in /lib, etc.

 2. update the James build.xml to read in these properties
and use these properties when defining things like the
project.class.path.

E.g.



  

  

  
  









...
  

  ...



 3. In the Gump descriptor for James, the definition of the
jar file corresponding to the property value can be declare
to be the result of a gump build (e.g. the current DNS, ORO,
Commons xxx, Excalibur xxx, Cornerstone xxx, etc.). We can
choose to link to either our local library of jars or to
the gump generated library.  Linking to the gump version
is what provides the feedback loop - someone (like me) does
something to excalibur-pool which inadvertently breaks something
else - I look at gump and find I have broken a dozen excalibur
builds, James, Cornerstone, Cocoon, etc.  Based on this info
I fix whatever it is I have done.

 4. The current James build includes dependencies to Phoenix, when
in fact this can be separated out to a following stage.  Stage
one should be building James.  Stage two should be building
the deployment solution (and Phoenix is the released solution).
I.e. at the gump level we should defining a gump target that
builds James core.  A second gump target should be defined
that builds the james-phoenix deployment solution - which
would naturally be dependent on james core and phoneix.

 5. James users (like me) can then declare dependencies on James
core (because I don't have a dependency on Phoenix).  When
someone in James does something to James that breaks something
that I'm working on - the feedback cycle to me is around 12 hours.
I.e. everyone is provided with a soft notification solution.

Hope that clarifies what I'm talking about with respect to #2.

Cheers, Steve.

p.s. and yes, I'm happy to put time into getting that in place.

SJM

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Serge Knystautas wrote:


Stephen McConnell wrote:


Danny Angus wrote:


 1. a James releasse scenario - this is where you referencing 

relased jars


 2. a James build that is based on the current CVS of Avalon 

based on Gump

I agree with 1, but not with 2.

I don't think it does James any good to treat the Avalon jar 
dependencies any different than we would other libraries.  I also 
don't think it does Avalon any good in the long term.


I agree with Serge, despite our close relationship with avalon I 
think we *must* work with released software only,


But your not - your build against and distributing against an 
unrelease cornerstone package.


Well yes, and I think this is again why we don't want (and would like 
to no longer be) doing #2, i.e., building against what's in CVS... 
because we end up using unreleased code and are otherwise not supported. 


No. I'm not suggesting *using* unrelease code.
#2 is getting the Gump descriptor for James sorted - that does not 
effect you day to day work.


So now it's a question of getting Avalon to make a published release, 
and then get a proposal from someone to do the upgrade... and as you 
imply, since we're not building against a release, I don't think you'd 
get much disagreement (and I hope we've been supportive of your 
preparatory work to have that happen). 


I would really like to sucessfully validate the candidates against James 
before proposing releases.



If there is cornerstone code we need that isn't getting released, we 
can absorb that code into the James package so that we can determine 
it releasable, and then if Avalon does release it, we can review 
handing over responsibility for that functionality back to them.


I've updated corenerstone so that each component that James is depedent 
on has its own build procedure and release version.  This means that (a) 
your not carrying around code for components you are not using, (b) your 
migrating to something that is supported, and (c) furture evolution of 
components can be managed properly.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: Excalibur/Cornerstone/James clarification

[Stephen McConnell]

Serge Knystautas wrote:


Stephen McConnell wrote:


There are two scenarios I think you should be considering:

  1. a James releasse scenario - this is where you referencing 
relased jars
  2. a James build that is based on the current CVS of Avalon based 
on Gump


I agree with 1, but not with 2.

I don't think it does James any good to treat the Avalon jar 
dependencies any different than we would other libraries.  I also 
don't think it does Avalon any good in the long term. 


Some clarification:

 Scenario (1) is getting James into shape so that it is
 built and distributed based on released jar files from
 wherever.  This is not the case today.  James is currently
 using an unsupported build of cornerstone.  James will
 also needs to upgrade at some point to the new thread jar
 from excalibur (that includes the fixes concerning pool
 sizes).  This upgrade impacts Phoenix as well because
 James is currently bound to Phoneix at the level of the
 code.  All of the above is managable stuff that is reflected
 in the James repository via addition of released jars in
 lib directories, etc.  Key actions that both James and
 Avalon people need to be concerned about is:

   * migration to a release for the cornerstone 1.0 components
   * migration to the updated thread 1.1
   * migration to a Phoenix release backed with thrread 1.1

 Scenario (2) is about collaborating sufficiently so that
 release candidates (like the current cornerstone-xxx-1.0 jars
 and the excalibur-thread-1.1 jar) can be validated.  The best
 approach to this is to establish a Gump based build procedure
 that is a seperate process that builds James against all of
 the current Apache repositories.  This has been in place for
 ages and has been failing for ages.  Things I'm doing are in
 part address this disconnect.

Some misconceptions:

 Nobody is suggesting that James move from well defined releases
 to HEAD depedencies.  Gump is an early warning system that will
 help to keep the James community aware of changes that may
 impact them across the entire Apache community.  I am suggesting
 that James/Cornerstone dependency get sorted - because the setup
 in James today with respect to cornerstone is far from
 satisfactory.

Hope that clarifies things.

Something else to keep in mind is that I'm moving close to a point
where I will be introducing James depedencies into code I'm working
on.  Having James in Gump (working) provides me with a lot more
assurance about things - if something fails - then I've got info
about the source (where the source could be James or could be a
dependency that James has on some other Apache project).



I know it's not ideal, but for me the big API change that happened in 
the Avalon project (Component -> Service I think it was) is not that 
big of a deal.  What made it a big deal is that there was not much of 
a clear release beforehand, I don't think any release (yet) after the 
fact, and I haven't heard of a changelog or HOWTO to help users make 
this change.

Codebases change all the time, and I have to believe the Avalon 
committers did what they felt was a right by moving to a different 
naming/design pattern.  But with software engineering, you need 
software development practices to support it.

As an example with another open source project, we use Netsaint for 
monitoring.  This was basically disolved, and the authors went and 
refactored the codebase into Nagios.  I don't mind that Netsaint isn't 
supported or that my large conf file needs to be completely 
rewritten... because there is explanation of what happened, clear 
releases so I can stay with Netsaint until we have the time to 
migrate, and I've heard rumor there is a conversion tool out there to 
help you migrate your conf file.  These practices allow me to handle 
the change, and this is better than having Nagios people who are very 
willing to help because in the end, I know my code/system best and 
need to understand how to apply it.

These software development practices allow the software engineering to 
happen with less restrictions.  For the Avalon community, having James 
build against Avalon and have Avalon committers help James with that 
is a misdirection of resources (IMHO).  You will get James working on 
it, but at the expense of other activities that can slow adoption of 
the codebase (which ultimately James needs to see happen as well). 


I disagree with the "slowing adoption" argument.  Getting James in sync 
with avalon releases will accellerate adoption.



So, I think Avalon should be treated just like other dependencies... 
people can propose updates, the community reviews it, and then if 
approved, the update happens.


Sounds good and I agree in principal.

BUT.

1. James needs to dump cornerstone.jar
2. A set of candidate releases of corerstone components have been
   prepared that incorporate bug fixes raised here.
3. To move from a unr

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Danny Angus wrote:


 

 1. a James releasse scenario - this is where you referencing 
 

relased jars
   

 2. a James build that is based on the current CVS of Avalon 
 

based on Gump

I agree with 1, but not with 2.

I don't think it does James any good to treat the Avalon jar 
dependencies any different than we would other libraries.  I also don't 
think it does Avalon any good in the long term.
   


I agree with Serge, despite our close relationship with avalon I think we *must* work with released software only, 


But your not - your build against and distributing against an unrelease 
cornerstone package.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Harmeet Bedi wrote:


Stephen is proposing a CVS repository of James and Avalon in Avalon Sandbox.
This would be based on current CVS code and would be temporary.

- If it is based on current CVS, shouldn't it be ongoing rather than
temporary ? I would expect a temporary integration codebase for well defined
releases not current CVS.
 


There are two scenarios I think you should be considering:

  1. a James releasse scenario - this is where you referencing relased jars
  2. a James build that is based on the current CVS of Avalon based on Gump

Why - because it means that (a) we have to get in sync. and (b) its an 
mutual early warning system, and (c) it enables James community to 
properly manage migration to released packages in Avalon.

- It would be better to to only sync up on well defined releases rather than
current CVS. Stephen do you have a release candidate of
Excalibur/Cornerstone that you want to synch up with James. 


Yes.

The cornerstone CVS has been updated to include a cornerstone.xml build 
file.  This gnerates a set of single component jars which can be manged 
under independent release cycles.

Or is the desire
to be always in Synch within development trees. 


Yes - as well - but via Gump.


James is a user of Phonix
and as long as there is a stable version of Phoenix for James all is good.
Not sure why James needs to tie in into current CVS of
Excalibur/Cornerstone.



1. Because your using a cornerstone jar file that I can't replicate.
2. Because there is no feeback loop from James to Avalon - and that's bad.
3. Because there is no feeback loop from Avalon to James - and that's bad.
4. Because I'm integrating James into my patform and I want to see some
  real synchronization :-)



It seems heavy to sync up on development trees via a temporary CVS
repository but if Stephen wants to do it, no harm there.
 


I would like to avoid it if I can - its just that I'm kind at a brick 
wall and I need help - and that possibly/probably/maybe means getting 
what I have here available to you and other James and Avalon people.

Cheers, Steve.

Harmeet

- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
To: "Avalon Developers List" <[EMAIL PROTECTED]>; "James
Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, January 22, 2003 10:32 PM
Subject: RE: Excalibur/Cornerstone/James woes


 

Stephen, are you planning to sync with a release version of
Excalibur/Cornerstone or with a development snapshot ?
 

Harmeet, are you having trouble keeping up with james-dev?  Stephen,
   

Serge,
 

Nico, and I have discussed this issue in depth and in multiple message
threads.

Stephen is one of the Avalon developers and PMC members.  He is working to
prepare a formal set of Avalon Release builds.

--- Noel


--
To unsubscribe, e-mail:
   


 

For additional commands, e-mail:
   




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Noel J. Bergman wrote:


We haven't reverted the HEAD, yet, just the v2.1 branch.  My plan was to
submit Peter's revised handler to replace the HEAD.  Stephen should pull
smtphandler.java from branch_2_1_fcs.



Tried that and started to get myself into trouble.  Seems that the 
branch_2_1_fcs version of SMTPHandler is referencing classes that don't 
exist in HEAD.  Maybe it would be easier if you reverted the HEAD?.

In order to resolve this problem I would like to import the modified
James sources into avalon-sandbox to enable James and Avalon people
to dig into this.
   


Actually, I'm not sure that I see the point, so please clarify.
 


Because I don't want to bring in something that isn't working.


from your e-mail it sounds like it makes more sense to me to
add a branch to james cvs.
   


If there is something in James that needs to change that might make sense,
and we can arrange for commit rights, as was done previously for PeterD and
PaulH.



While working though the code I've been doing little tings like putting 
in leg priority test occasional javadoc and stuff like that - comit 
privs would help with that - but more useful is the fact that I would be 
able to commit and take care of the build and property files I'm using 
(no conflict with existing setup - just a couple of build file that tie 
into the avalon jars.

 

I'm confident this is a Cornerstone/Exalibur change issue
and we will need assistance from James people
   


If it isn't in James code, then why do we need a separate copy of the James
source in the CVS?  And if it is, then I think it should be done in our
module.



I'm happy to go with whatever you think is best. Given that this was all 
working at one point (post SM rollever), I'm now suspecting that the 
problem may be in the James HEAD - but I havn't updated for a few days - 
and I'll do that later this evening and see where that leads me.

Cheers, Steve.

p.s. more feedback comming in replay to Pete's email in a moment.



	--- Noel

-Original Message-
From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 13:39
To: 'Avalon Developers List'
Subject: RE: Excalibur/Cornerstone/James woes

Stephen,

Are you sure this isn't a config problem?  Ignoring the empty command for
the moment, it looks like your mail to "test@localhost" is being routed to
RemoteDelivery for processing.  Maybe because it's in the spammer blacklist?
A posted configuration file might help immensely.  Also, it would probably
be desirable to flip on debug for all the individual mailets if you haven't
done so already.

I've got a (somewhat modified) version of James that uses the current
Cornerstone classes (haven't upgraded all of the Excalibur ones), has
undergone the Composable->Serviceable change, and runs inside Phoenix.
Seems to work ok.  I'd be happy to share source code with you if you so
desire.

Also, does your source have the post-2.1 patch that altered the SMTP handler
data buffering?  As that patch was in error, and has since been reverted, it
may be causing some of your empty command woes.  The empty command you are
observing is symptomatic of a bug introduced with that patch.  Please see
james-dev for a discussion.

--Peter

 

-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 3:17 AM
To: Avalon Developers List; James Developers List
Subject: Excalibur/Cornerstone/James woes


Guys:

It looks like my earlier note concerning success with James was
premature.  I'm back experiencing an loop inside James mail processing
and have not been able to isolate the problem.

Relevant points:

  1. build of James, Cornerstone and Excalibur related resources
 are all from current CVS
  2. James sources have been updated locally to support the service
 package (to sync with Cornerstone changes)

Some important notes:

  1. james extends several Cornerstone classes based on Cornerstone
 implementations from back in June and I suspect that there may
 be a runtime disconnect here somewhere
  2. problem occurs when running under Phoenix or Merlin so I think
 we can rule out containers as the issue

I've put up a log with full debug level on at the following URL:

  http://www.osm.net/technical/james/james-log.txt

Comments added to the log file are prefixed by ##.

In order to resolve this problem I would like to import the modified
James sources into avalon-sandbox to enable James and Avalon people to
dig into this.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net
   



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: http://james.apache.org

[Stephen McConnell]

[EMAIL PROTECTED] wrote:


Christ Danny - that was one hell of a burst of enthusiasm!  I see that
you've even removed all the Jakarta James references! Great job!

It has taken Avalon over a month (and still counting) and they haven't even
got a redirect up!  Their top level site still shows an empty dir listing.
Ha ha!

:-)



:-)

!#@&%$**


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Excalibur/Cornerstone/James woes

[Stephen McConnell]

Leo Simons wrote:


Stephen McConnell wrote:


It looks like my earlier note concerning success with James was 
premature.  I'm back experiencing an loop inside James mail 
processing and have not been able to isolate the problem.





In order to resolve this problem I would like to import the modified 
James sources into avalon-sandbox to enable James and Avalon people 
to dig into this.


If it is temporary only and the james team agrees (I think they are 
indeed interested in seeing this code soon, right?) it's fine by me, 
even if from your e-mail it sounds like it makes more sense to me to 
add a branch to james cvs.


Temporary - Yes.

Is an immediate concern - for me yes, for the James commitee - it as 
thorn in the side.

The reason for propsing avalon-sandbox is that (a) I consider this to be 
our problem - not a James problem - i.e I'm confident this is a 
Cornerstone/Exalibur change issue and we will need assistance from James 
people to sort ot out, and (b) its more convinient because I'm not a 
comitter over on James so sticking it into sandbox is easier for me.

Cheers, Steve.



cheers,

- Leo



--
To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 
<mailto:[EMAIL PROTECTED]>




--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

[PROPOSAL] avalon housekeeping

[Stephen McConnell]

I would like to propose that we put some priorities in place.

 On our release agenda is Avalon framework 4.1.4, logkit 1.2,
 excalibur packages: thread 1.1; sourceresolve 1.0;
 configuration 1.0; xmlutil 1.0; store 1.0, cornerstone
 packages: threads 1.0; connection 1.0; datasources 1.0;
 masterstore 1.0; scheduler 1.0; sockets 1.0 threads 1.0.
 If we throw into the equation the potential release of
 Fortress we also need to address release of the avalon-sandbox
 lifecycle package and the instrument package.  Phoenix release
 is already out but used non-released code - excalibur
 configuration, loader and extension.

Throw into this equation the fact that our current Cornerstone
repository (used by James and Cocoon) has changed at interface and
implementation levels and that every indication from Gump tells us
we have a broken product. Also keep in mind that Cocoon is using the
source, component, xml, store, datasource, pool, testcase, util,
instrument, collections (and possibly other packages) some of which
we have never release.

My proposal is this:

No new release proposals until the current Avalon in-use
excalibur and cornerstone products are finalized,
validated, properly released, and synchronized with
Cocoon and James.

A.K.A - Lets put our priority towards getting Avalon in shape for
our users based on what they are doing today.  From that platform
we can move ahead.

Cheers, Steve.


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Excalibur/Cornerstone/James woes

[Stephen McConnell]

Guys:

It looks like my earlier note concerning success with James was 
premature.  I'm back experiencing an loop inside James mail processing 
and have not been able to isolate the problem.

Relevant points:

  1. build of James, Cornerstone and Excalibur related resources
 are all from current CVS
  2. James sources have been updated locally to support the service
 package (to sync with Cornerstone changes)

Some important notes:

  1. james extends several Cornerstone classes based on Cornerstone
 implementations from back in June and I suspect that there may
 be a runtime disconnect here somewhere
  2. problem occurs when running under Phoenix or Merlin so I think
 we can rule out containers as the issue

I've put up a log with full debug level on at the following URL:

  http://www.osm.net/technical/james/james-log.txt

Comments added to the log file are prefixed by ##.

In order to resolve this problem I would like to import the modified 
James sources into avalon-sandbox to enable James and Avalon people to 
dig into this.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-james/proposals/TLP proposal-letter.txt

[Stephen McConnell]

From them revised text:

 We don't expect that james.apache.org will bring many
  direct benefits, but we do think that normalising our relationship
  with Jakarta by becoming a sibling rather than a child, and taking
  official control of all the issues we currently inherit and
  "interpret" from Jakarta would benefit James.

I would suggest substituting the word "peer" for "sibling" in the above. From the point of view of the Board you would be taking on management responsibilities equivialent to Jakarta concerning the autiting of the James project - as such you are a peer.

Cheers, Steve.


[EMAIL PROTECTED] wrote:


serge   2003/01/17 18:33:41

 Modified:proposals/TLP proposal-letter.txt
 Log:
 Made small edits and wrote the history section.
 
 Revision  ChangesPath
 1.3   +34 -14jakarta-james/proposals/TLP/proposal-letter.txt
 
 Index: proposal-letter.txt
 ===
 RCS file: /home/cvs/jakarta-james/proposals/TLP/proposal-letter.txt,v
 retrieving revision 1.2
 retrieving revision 1.3
 diff -u -r1.2 -r1.3
 --- proposal-letter.txt	21 Nov 2002 11:26:21 -	1.2
 +++ proposal-letter.txt	18 Jan 2003 02:33:41 -	1.3
 @@ -17,7 +17,7 @@
  Introduction to James:
  --
  
 -James is a 100% java Mail and news server.
 +James is a 100% Java mail and news server.
  
  James provides highly configurable SMTP mail transport and local
  delivery into POP3 or IMAP accounts, utilising file system or database
 @@ -28,7 +28,7 @@
  processing of mail and news messages.
  
  James implements the Mailet API, and as such is itself a platform for
 -Mailet applications. Applications providing bespoke/custom mail
 +Mailet applications. Applications providing custom mail
  processing, such as listservers, or providing gateways into other
  systems, messaging systems such as NNTP, SMS or proprietery messaging,
  or insertion into non-standard storage media.
 @@ -53,39 +53,57 @@
  The proposals being discussed on reorg & community include the notion
  of federated projects. We would like to think that we wouldn't be
  leaving Jakarta, just growing up.
 +
  We also know that James would continue to rely on Jakarta for code,
  insight and knowekdge, but we don't need to be a Jakarta sub-project
  to benefit from that.
 +
  --
  Project Management:
  --
  This proposal is more about management than web-site and mail
 -addresses, we don't believe that james.apache.org will bring many
 +addresses.  We don't expect that james.apache.org will bring many
  direct benefits, but we do think that normalising our relationship
  with Jakarta by becoming a sibling rather than a child, and taking
  official control of all the issues we currently inherit and
  "interpret" from Jakarta would benefit James.
  
  James has a small yet mature self-sustaining community, we seldom seek 
 -recourse to the jakarta PMC, and equally seldom are we scrutinised by 
 +recourse to the Jakarta PMC, and equally seldom are we scrutinised by 
  them. We are perhaps not the most active project, and some of us may 
  feel that this sometimes causes James to be disregarded. Likewise, 
 -apart from Avalon, we have few direct ties with other jakarta projects.
 +apart from Avalon, we have few direct ties with other Jakarta projects.
  
  --
  Profile:
  --
 -As outline above James is composed of three main
 +As outline above James is composed of three main areas.
  
 +JAMES server
  Sub-Projects:
 -Mailet API:
 -Mailet Applications:
 +Mailet API
 +Mailet Applications
  
  
  --
  History:
  --
 -### TODO: SERGE you must know most of the history..? ###
 +JAMES was originally envisioned and placed as a holding page on
 +java.apache.org, before Jakarta was organized.  Individuals
 +(unfortunately names forgotten at this point) had submitted a proposal
 +to the (HTTP) servlets group at Sun to provide mail handling.  They
 +rejected the proposal due to technical reasons.
 +
 +Serge Knystautas later donated a Java SMTP server implementation that
 +became the original codebase for JAMES.  The mailet API was heavily
 +discussed and finalized, the original code was massively refactored
 +and improved, and a POP3 implementation was added.
 +
 +JAMES was later refactored to use the new Avalon codebase.  JAMES also
 +received a donation of an NNTP implementation.  JAMES has slowly added
 +new mailets, improved reliabilit

Re: Updating James vis-a-vis Avalon

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

 

Who is wondering what he should do with the James tranformation of
CM to SM that he has on his machine?
   


We'd love to have it, Stephen.  The only issue appears to be whether or not
we want it before Avalon is ready to do a Release.  Related to this, Dion
Gillard is working on the Maven setup for James.  He also needs us to have a
clean set of Avalon JAR files.  Right now he's having trouble because of
James / Avalon compatibility issues.
 


Yep - I noticed that (basically the same issues I've been dealing with 
this last week and the reson why I've been working up the product table 
this week):

  http://www.osm.net/technical/avalon/docs/avalon.html


Serge's view, and I think there is justification, is that we want a Release,
not another CVS dump.  I do see that Avalon (in the person of you, for the
most part) is starting to do the preliminary work necessary.  Personally,
since James v3 is in early development, I don't know that I would mind
starting with a tagged CVS release that was considered by the Avalon PMC to
be a Milestone build, but mine is just one vote.



The are a coule of steps:

  (a) getting out a release candidate (milestone build) of Cornerstone 
- this need Avalon an OK

  (b) getting a release together - this needs PMC which needs process 
which needs time

I want to get the changes off my machine and into James and from there 
start validation of operation within Phonix.  If there is a problem with 
Phoenix execution based on the Cornerstone CVS release - we jump in and 
fix Phoenix.  Once everything is working nicely - we move forward with a 
release.  But release has prerequisites - and there is as little 
housekeeping that needs to be done over on avalon first.  I would like 
to can to the point of validating a candate before we get into the 
release process - and that means getting this stuff into James HEAD.


My suggestion is that you propose to us that you submit your patches
concurrent with such a Milestone from Avalon, and let us vote on it.  This
is important for Maven, too, since they would put your version labeled jars
into their central repository.



Sounds reasonable - I will make a proposal on Avalon for RELEASE 
CANDIDATE (milestonte) status of the Cornerstone jars. If that flows 
through - I'll make a proposal to James to ramp up to the RC jars. 
Assuming that that flows though - we put in place validate of deployment 
of James on Merlin and Phoenix - we solve any problems that arrise. 
After that - you guys give the green light for a release to Avalon - 
following which I'll persue a process of release (taking into account 
all of the the dependency considerations).


On a related topic, I've no problem with Avalon keeping store.  I was just
pointing out that Peter Donald has commented that he thought it ought to be
moved to James.  Right now we do have our own (fixed) copy of the file store
implementation, since it was broken, and we were told to fix it in copies of
our own so that it could be removed from Avalon.



I'm feeling a little uncomfortable about all of this - I don't have a 
good idea about what is wrong - I don't know if James is the only user 
of this or not - and I don't like the fact that I don't know where we are!!!

But I do want to resolve this.

In the meantime:

  Step 1: Avalon OK on a RC status on the Cornerstone build.

  Step 2: James OK on migration to RC and CM --> SM migratiton.

I'll get started on step (1).

Cheers, Steve.


	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

James and Merlin looking good

[Stephen McConnell]

Have resolved the issue I was having in Merlin 2.1 with James - turns 
out I copied and pasted a configuration from the current defintions to 
the wrong component!  That's all fixed and I've done a bunch of tests, 
optimized a few things in Merlin and now everything is runing peachy.  

Tests pass without error and client interaction is working fine.

Just for reference, the block defintion for the James system in Merlin 
has been added to the CVS - you can't use it yet because the James 
ComponentManager -> ServiceManager changes I've made are local on my 
machine and I havn't committed the Cornerstone stuff yet.  

Anyway, the reference may be of interests:

  The top-level blocks.xml file which tells Merlin which
  blocks to load - the James block includes a confuration
  fragment that suppliments a packaged confiuration so you
  can site specific informaiton.

  http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/merlin/blocks.xml

  The actual James block definition just contains the
  description of the components to be deployed within
  the container managed by the James block.  This is
  reasonably similar to the current information exect that
  you don't need any assembly information (Merlin will figure
  that out for you).

 
http://cvs.apache.org/viewcvs.cgi/avalon-sandbox/merlin/src/test/config/james.xml

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James HEAD, CM-->SM, Cornerstone OK

[Stephen McConnell]

Noel J. Bergman wrote:


After executing the test the SMTP thread is still busily running
consuming as much CPU as it can get.
   


The following fragment of the SMTP log is typical:

[DEBUG  ] (james.smtp): Command received:

This is bad already.  Where is the command?  We just changed the read code,
but the original code was "return inReader.readLine().trim();" and I don't
think the replacement is broken.



I just did a little debugging - the command is a zero length string.

So I added a little something to the SMTPHandler.pasrseCommand() to 
check if the command length is 0 and if so, to return false.  That has a 
rather significant impact in that everything appears to be working properly.

   if( (rawCommand == null) || ( rawCommand.length() == 0 ) ){
   return false;
   }



 

[DEBUG  ] (james.smtp): Calling reset() default Worker #1017
[DEBUG  ] (james.smtp): Calling reset() default Worker #1423
[DEBUG  ] (james.smtp): Calling reset() default Worker #1652
[DEBUG  ] (james.smtp): Calling reset() default Worker #214
   


This is also not good.  Those numbers are related to threading.  Something
feels truely fouled.
 


And this has dissapeared.

Cheers, Steve.

p.s. Test execution for 1000 messages took 86 seconds (file storage, 350 
MHtz Intel).

	--- Noel


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James HEAD, CM-->SM, Cornerstone OK

[Stephen McConnell]

Serge Knystautas wrote:


We have a fledging group of tests for both performance and 
functionality testing... if you can try to run those against your 
mod'd version as well, that'd be great. 


Serge:

I had to update the DeliveryTest.java source (replacement of all assert( 
boolean ) statements with assertTrue( boolean ) due to conflict with JDK 
1.4 assert statement - aside from that the test ran without problem. 
I'm running under the default out-of-the-box configuration (file system 
based storage).  However, I know I'm not quite out of the woods just 
jet.  After executing the test the SMTP thread is still busily running 
consuming as much CPU as it can get.

The following fragment of the SMTP log is typical:

[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Command received:

With occasional bursts of:

[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Calling reset() default Worker #1017
[DEBUG  ] (james.smtp): Calling reset() default Worker #1423
[DEBUG  ] (james.smtp): Calling reset() default Worker #1652
[DEBUG  ] (james.smtp): Calling reset() default Worker #214
[DEBUG  ] (james.smtp): Calling reset() default Worker #1309
[DEBUG  ] (james.smtp): Calling reset() default Worker #261

I'm presuming that this is not normal behaviour.

Any suggestions?

Cheers, Steve.






--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: James HEAD, CM-->SM, Cornerstone OK

[Stephen McConnell]

Serge Knystautas wrote:


Steve,

Sounds great!  We have a fledging group of tests for both performance 
and functionality testing... if you can try to run those against your 
mod'd version as well, that'd be great.  I don't think they're 
organized, but hopefully there's enough there to make sense of it.

Sounds like a good idea - but first of all I'm playing with getting 
things running poroperly.  Incomming mail isn't a problem and I've just 
received my first messages in Netscape from my new James account setup 
using the remote admin (this is fun). However I figure I may have 
something wrong in the configuration because when I send an email from 
the client, James SMTP its dropping into an infinate loop (100% CPU 
consuption).

[DEBUG  ] (james.smtp): Command received:
[DEBUG  ] (james.smtp): Sent: 500 home Syntax error, command unrecognized:
[DEBUG  ] (james.smtp): Calling reset() default Worker #13

The message actually does get sent.
Does this ring any bells?

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

James HEAD, CM-->SM, Cornerstone OK

[Stephen McConnell]

Some good news.

I have a special version of James that appears to be functioning 
correctly (at least its receiving and processing mail). Here is a quick 
summary of the environment:

  1.  Local update of James sources based on CVS HEAD to
  incorporate complete transition to ServiceManager
  and retraction of the deprecated
  org.apache.avalon.component.* references.

  2.  Build and deployed against a set of seperated
  Cornerstone jars (based on Cornerstone HEAD):

cornerstone-connection-1.0.jar
cornerstone-datasource-1.0.jar
cornerstone-store-1.0.jar
cornerstone-scheduler-1.0.jar
cornerstone-sockets-1.0.jar
cornerstone-threads-1.0.jar

   3. Updated James sources to use common collections
  in preference to Excalibur Collections.

   4. Built and running against updated versions of
  Excalibur jars (threads, pool, datasource) that
  are based on commons collections instead of
  Excalibur Collections.  All other Excalibur resources
  are based on Excalibur HEAD.

   5. Running under a Merlin 2.1 as a single composite Block
  defintion.

   6. No container jars exposed.

   7. No Phonenix jars required.

I need to put some details together about the changes I've made in
the Excalibur and Conerstone projects (probably tommorow). That ties
in with the current Avalon on releasing and Avalon Components so I'm
planning on submitting a diff real soon - but the main things is that
its done, and its working.

For the moment I'm actually going to look at the documentation and
figure account how to setup an account for myself!  

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Synchronizing James and Cornerstone

[Stephen McConnell]

Noel J. Bergman wrote:


Steve,

 

Actually, Noel's last email raises a bigger question for me... 
what Avalon **release** are we proposing upgrading to?  I would 
be *much* more relunctant if the proposal is just to upgrade to 
Avalon's HEAD.  What we're running with now was HEAD at one 
point, and then things start changing and we're told we have an 
unsupported version.

If Avalon has a release we want to upgrade to, that sounds great.  
But just upgrading to their HEAD sounds like trouble in river 
city to me.
 

A combination of both.
 1. build against specific version of jars with crear version
dependencies and release status
 2. gump validation against the CVS HEAD
   



Serge's point is really valid though.  THIS time we have to get release
jars, with all of what that entails (including tagging the CVS).  As you've
noticed, you can't even backup to what we have without guessing about some
old beta version of cornerstone.

Yes, GUMP will build us against the Avalon CVS HEAD, but that's just an
Early Warning System to get us running over to avalon-dev@ to see WTF is
going on.

Is the Avalon PMC able to define a coordinated Release of all the A4 modules
such that we know that they all work together?
 


Well you have one PMC member who is very keen to see (a) a checklist 
fulfilment that precoditions any release, and (b) a product sheet 
detailing the products in Avalon and asociated status.  However - one 
isn't sufficient - lets raise this on the avalon list and see if we can 
get that checklist into place.  I've already started the process of 
digging into the thread, poll, threadcontext and conerstone thread 
packages which will al least facilitate a kick-off a product list.

I'm CC'ing to Avalon Dev and Avalon PMC so we can get more feedback on 
this suggestion.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Synchronizing James and Cornerstone

[Stephen McConnell]

Serge Knystautas wrote:


- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>


 

I don't know if Paul tagged the CVS when he took the code currently
   

embedded
 

in James from the Avalon CVS.  Yes, it is certainly an older version of
   

the
 

code prior to Avalon violating (er, unilaterally changing) interface
contracts.
   


Actually, Noel's last email raises a bigger question for me... what Avalon
**release** are we proposing upgrading to?  I would be *much* more
relunctant if the proposal is just to upgrade to Avalon's HEAD.  What we're
running with now was HEAD at one point, and then things start changing and
we're told we have an unsupported version.

If Avalon has a release we want to upgrade to, that sounds great.  But just
upgrading to their HEAD sounds like trouble in river city to me.



A combination of both.

  1. build against specific version of jars with crear version 
dependencies and release status
  2. gump validation against the CVS HEAD

Cheers, Steve.


Serge Knystautas
Loki Technologes
http://www.lokitech.com/



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Branching for Avalon Update

[Stephen McConnell]

Serge Knystautas wrote:


- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>


 

I don't know if we need a vote, but ...

Do we agree that it is a good idea to create a temporary branch for
   

purposes
 

of resolving our Avalon conflicts?  We can make the changes to HEAD
directly, but that would temporarily disable your ability to build
   

runnable
 

James (other than from branch_2_1_fcs) until we finished.
   


A couple of thoughts...
1. I'd like to hear more of the case for upgrading our Avalon components.
We have a working version, and I haven't seen a case made for what
features/fixes we're after that justifies the upgrade work, just that it
doesn't compile against what's in Avalon's CVS.  I wouldn't really
discourage anyone from doing the upgrade mind you, it's just that we've got
an underlying library that changes API and features, sometimes without
changing version numbers, so without listing the benefits, it's the kind of
upgrade I generally think a lot about before doing.  Even the rarely
released and stable package of JavaMail/JAF went through a qualification of
what bugs/improvements we wanted with the upgrade, as with DnsJava.



1. James integrity
  * building against a cornerstone base that is actually supported
  * reducing dependency of Avalon framework by getting rid of the
component interface dependecies (once you switch over to
ServiceManager you are not longer limited to Avalon Components)
2. James flexibility and independence
  * introduce a choice in the James deployment strategy
(including embedded James deployment scenarios)
  * elimination of container depedencies (instead of building against
Phoneix jars you would be building against relased jars from Avalon)
  * leverage opporuntities arrising from Avalon work on a common container
architecture
3. Help Avalon rationalize
  * James building against Cornerstone and Excalibur components directly
  * Immidiate automated feedback from James to Avalon when something
breaks (ourside, yourside, whatever)

Cheers, Steve.


2. I don't think whoever is making these changes should commit changes until
you have a runnable James (or at least in that person's knowledge... not
saying there won't be bugs, but you shouldn't commit incomplete changes).
3. I don't think we need to branch as these changes could be made directly
to HEAD.

Serge Knystautas
Loki Technologies
http://www.lokitech.com/


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Synchronizing James and Cornerstone

[Stephen McConnell]

Noel J. Bergman wrote:


Stephen,

[Responding to all of your various notes here]

I don't know if Paul tagged the CVS when he took the code currently embedded
in James from the Avalon CVS.  Yes, it is certainly an older version of the
code prior to Avalon violating (er, unilaterally changing) interface
contracts.



I just checked the CVS "with-Avalon-4_0b2" - if could be this (at least 
the code I'm looking at on the WebCVS is consitent with the error I was 
getting originally).

What I don't understand is how James could be running inside Phoneix
without problem unless nobody from James has executed a clean checkout of
Excalibur in the last 3 months.
   


Of course we haven't:

  http://cvs.apache.org/viewcvs.cgi/jakarta-james/phoenix-bin/lib/
  http://cvs.apache.org/viewcvs.cgi/jakarta-james/lib/

As should be well understood by now, James uses the older version because
the interfaces were changed, and broke our code.  At some point, we had to
focus on our own release, and not play three-card monty with Avalon's
interfaces.
 


Yep.


 

  James is runing againt excalibur-thread-1.0.jar (size 22k)
  Excalibur current build of excalibur-thread-1.0.jar (size 32k)
  appears to be incompatible
   


Gee, what a shock.  And with the same version label, no less.

If I sound a bit testy today, I'm sorry (and probably a bit testy, anyway
:-)).  Reading your messages has me thinking about how much work and testing
we may have to do to get James running with the current Avalon.  Plus the
fact that this is still open despite being reported multiple times, put in
bugzilla, *and* having had the fix posted with it:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15296.

FWIW, we did take the file repository classes from Avalon and moved them
into our codebase because we were told that the code was in Avalon only for
us, and would not ever be fixed.

 

Things would be *so* much easier if we got James and Cornerstone in sync.
   


Yes, getting back to the problem at hand ... how far have you gotten on all
of the problems you enumerated?



I have James running - but failing due to what I think is an 
incompatability in excalibur-thread-1.0.jar - which I think may be 
linked to the collections jar.  Aside from that - there were some issues 
I encountered on the container side relating to non-components being 
passed out of a component manager but that has been solved with a proxy. 
That, combined with a simulated Phoenix BlockContext seems to have 
resolved the build and deployment stages.


I'm willing to work with you on updating the HEAD to work with the curent
Avalon code.  I suspect that the best thing, so as not to foul up others
would be to create a short-lived branch of James, put the new Avalon jars in
that branch, and work on the James code until we can once again build and
run.  Then we can merge the Avalon jars and the changed code into HEAD.

And we can let GUMP warn us if someone changes interfaces again.

That the way you'd do it?
 


Sound good.


I don't see any value to changing the v2 branch to use the updated Avalon
interfaces.  Frankly, there is a trust factor, and I don't want to risk
breaking our stable branch.
 


I agree - there is some rebuilding to be done (I'm I not referring to code).


- Classes in James that extend Cornerstone and call super
 on ComponentManager (which is broken because the Cornerstone
 classes no longer implement ComponentManager.
   


 

- Numerouse casting errors related to James casting of objects
  to Component which do not exist in the current Cornerstone
  package.
   


 

- Some more tricky errors related to the passing of component
  managers and component across different instances which don't
  show up until runtime.
   


What about the other errors reported by GUMP, e.g.,

 org.apache.james.core.AvalonMailStore should be declared abstract;
 it does not define isSelectable(java.lang.Object)

 select(java.lang.Object) in org.apache.james.core.AvalonMailStore
 cannot implement select(java.lang.Object); attempting to use
 incompatible return type
found   : org.apache.avalon.framework.component.Component
required: java.lang.Object

Etc.  Are you including those errors, or have you fixed them already?
 


These errors are directly related to the ComponentManager/ServiceManager 
changes in Cornerstone.  Basically some of the classes in James  extend 
classes in Cornerstone and there are places where a James compoent is 
invoking super.compose( manager ) and the supertype does not implement 
the the compose operation.  Other errors are simply cast errors related 
to the Component interface.  There a few tricky ones where the compoennt 
manager is held as a state member and subsequently passed as an argument 
which is a little harder to track down given all of the inconsitencies. 
Bottom line - 95% of the issue will dissapear with the CM -> SM 
rollover in the James code.

In addition to synchronization I think there is some repackaging
required on th

Re: James / Excalibur ThreadPool conflict

[Stephen McConnell]

Stephen McConnell wrote:



Pete:

Have finally got to a point where I'm running James inside Merlin again.

But I'm gettig a rather odd exception.  The execution occurs after 
James is established and running (about 30 seconds after).  The 
exception (listed blow) is a NoSuchMethodError - raised when the 
JamesSpoolManager invokes excecute, passing itself as an argument. I 
looked into the sources and CVS history and discovered that 
org.apache.avalon.excalibur.thread.ThreadPool.execute() interface was 
changed by you about three months ago - retracting Runnable as a valid 
argument in favour of Executable.  It appears that this breaks James 
(based on the James HEAD and the current ThreadPool source.  What I 
don't understand is how James could be running inside Phoneix without 
problem unless nobody from James has executed a clean checkout of 
Excalibur in the last 3 months.


Some additional observations:

Phoneix is using an old version of the excalibur-thread-1.0.jar (July 2002)

  James is runing againt excalibur-thread-1.0.jar (size 22k) from the 
Phoenix distribution
  Excalibur current build of excalibur-thread-1.0.jar (size 32k) 
appears to be incompatible

Phoneix gump is based on the current excalibur-thread-1.0.jar (size 32k)

No concrete conclusions from these observations other than the following:

  (a) the current excalibur-thread-1.0.jar does not appear to be 
backward compatible
  with the 22k version
  (b) getting James in sync should be a number 1 Avalon priority in 
order to get
  concrete feedback on changes we are making (across Cornerstone, 
Excalibur
  and Phoenix)

Cheers, Steve.


Can you or anyone else (Avalon or James) shead any light on this?

Chee rs, Steve.

--- 

java.lang.NoSuchMethodError:
  org.apache.avalon.excalibur.thread.ThreadPool.execute(

Ljava/lang/Runnable;)Lorg/apache/avalon/excalibur/thread/ThreadControl;
 at org.apache.james.transport.JamesSpoolManager.initialize(
   JamesSpoolManager.java:246)
--- 



--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

James / Excalibur ThreadPool conflict

[Stephen McConnell]

Pete:

Have finally got to a point where I'm running James inside Merlin again.

But I'm gettig a rather odd exception.  The execution occurs after James 
is established and running (about 30 seconds after).  The exception 
(listed blow) is a NoSuchMethodError - raised when the JamesSpoolManager 
invokes excecute, passing itself as an argument. I looked into the 
sources and CVS history and discovered that 
org.apache.avalon.excalibur.thread.ThreadPool.execute() interface was 
changed by you about three months ago - retracting Runnable as a valid 
argument in favour of Executable.  It appears that this breaks James 
(based on the James HEAD and the current ThreadPool source.  What I 
don't understand is how James could be running inside Phoneix without 
problem unless nobody from James has executed a clean checkout of 
Excalibur in the last 3 months.

Can you or anyone else (Avalon or James) shead any light on this?

Cheers, Steve.

---
java.lang.NoSuchMethodError:
  org.apache.avalon.excalibur.thread.ThreadPool.execute(
Ljava/lang/Runnable;)Lorg/apache/avalon/excalibur/thread/ThreadControl;
 at org.apache.james.transport.JamesSpoolManager.initialize(
   JamesSpoolManager.java:246)
---

--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Synchronizing James and Cornerstone

[Stephen McConnell]

Noel J. Bergman wrote:


the transition from Composable to Serviceable is not too difficult
is just a matter of some specific replacements and a some
validatition - the more relavant question is when?
   


Well, that's why I asked.  What exactly do we need to do?  We may not do it
for James v2, but I'd like James v3 (HEAD) to be able to float against
Avalon.



On timming I would very much like to see synchronization as early as 
possible.  I'm currently running into lot of problems with James that 
are related to the Cornerstone version in james/lib.  The problem 
appears to be that the James version is still linked to BlockContext 
whereas the Avalon version is not (following recent Cornerstone changes).

Some of the problems I'm encountering when attempting to build James 
against Avalon Cornerstone include:

 - Classes in James that extend Cornerstone and call super
   on ComponentManager (which is broken because the Cornerstone
   classes no longer implement ComponentManager.

 - Numerouse casting errors related to James casting of objects
   to Component which do not exist in the current Cornerstone
   package.

 - Some more tricky errors related to the passing of component
   managers and component across different instances which don't
   show up until runtime.

Problems related to working with the current James version of 
Cornerstone include:

 - ClassCastExceptions when dealing with context (which is surely
   related to Pheonix BlockContext but I don't know where the code is
   backing the the James version of Cornerstone so I'm working in
   the dark.

Things would be *so* much easier if we got James and Cornerstone in sync.

In addition to synchronization I think there is some repackaging 
required on the Avalon side.  Currently the Cornerstone.jar contains a 
bunch of components that are not used by James (RMISubscriber, 
SocketStreamPublisher, RMIPublisher, DefaultAuthenticator, and Glue). 
It would make a lot more sense for individual components in Cornerstone 
to be packaged in individual jars and treated as specific products (with 
respective releases, status, versions, etc.).

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SMTPHandler

[Stephen McConnell]

Noel J. Bergman wrote:



Is anyone other than James complaining about the interface change(s)?


Not that I am aware of.

Just for reference do you know where the sources are for the version of 
cornerstone.jar in the james/lib distribution.  I can build James 
against that version which means that your version is different to the 
Avalon version.  It would be useful to know what the differences are.

the transition from Composable to Serviceable is not too difficult
is just a matter of some specific replacements and a some
validatition - the more relavant question is when?
   


Well, that's why I asked.  What exactly do we need to do?  We may not do it
for James v2, but I'd like James v3 (HEAD) to be able to float against
Avalon.


Here is the replacement list

1. replace org.apache.avalon.framework.component.ComponentException
  with org.apache.avalon.framework.service.ServiceException
2. replace org.apache.avalon.framework.component.Composable
  with org.apache.avalon.framework.service.Serviceable
2. replace org.apache.avalon.framework.component.ComponentManager
  with org.apache.avalon.framework.service.ServiceManager
4. replace org.apache.avalon.framework.component.DefaultComponentManager
  with org.apache.avalon.framework.service.DefaultServiceManager
5. replace org.apache.avalon.framework.component.ComponentSelector
  with org.apache.avalon.framework.service.ServiceSelector
6. replace org.apache.avalon.framework.component.DefaultComponentSelector
  with org.apache.avalon.framework.service.DefaultServiceSelector

That's about it - then your recompile and sort out any issues - which 
basically involve removing all casting and reference to Component 
(because ServiceManager.lookup() returns an Object), replacing and state 
members that reference Component with Object, and removing Component 
import statements.

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: SMTPHandler

[Stephen McConnell]

Noel J. Bergman wrote:


Steve,

Is that in the HEAD branch?  


Yep.


I have to update my copy of that.  Been patching up v2 stuff this week.

Speaking of patching ... are you familar with what I need to do to address
the Avalon changes so that GUMP can build us properly?



Umm ... familiar is not the word that I would use.  I'm was trying to 
build james against the cornerstone CVS but there are simply too many 
problems and I reverted to the "special" version in the james/lib 
directory.  The changes that were applied to Cornerstone several months 
ago (retraction of Component, and the replacement of Composable with 
Serviceable) simply create too many problems (and this is a build phase 
- nothing to do with which container you are using) to spend too much 
time on it.

Options are:

 a) we (Avalon) rollback Cornerstone to implement ComponentManager
+ addition of Component to the inhertance graph of
related components

or

 b) upgrading James to use ServiceManager

I would suggest proceeding with option (b) but to be honest - I have not 
been tracking all of the James messages - instead I've been watching the 
Mailet API discussions with an interest in ensuring that the concepts 
related to containment architectures can fully support the notions of a 
"virgin-component-model" - i.e. I'm noty completely up-to-date on the 
state of the 2.1 relase.  But anywhay the transition from Composable to 
Serviceable is not too difficult is just a matter of some specific 
replacements and a some validatition - the more relavant question is when?

Cheers, Steve.


	--- Noel

-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 10, 2003 16:14
To: James Developers List
Subject: SMTPHandler


While building James after a CVS update from a couple of minute ago:

   CLASS: org.apache.james.smtpserver.SMTPHandler

Is appears to be missing the following input statement:

   import java.io.ByteArrayOutputStream;

Cheers, Steve.


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



 


--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

SMTPHandler

[Stephen McConnell]

While building James after a CVS update from a couple of minute ago:

   CLASS: org.apache.james.smtpserver.SMTPHandler

Is appears to be missing the following input statement:

   import java.io.ByteArrayOutputStream;

Cheers, Steve.

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Database connections (was RE: Avalon dependance in mailets)

[Stephen McConnell]

Danny Angus wrote:


Or.. using IOC the container could supply a mailetDatasource on
initialisation which would have a single method.. getConnection().

The last would make it harder for a single mailet to access more than one
datasource, so I prefer the MailetContext().getConnection(datasourceName)
route.



The IOC approach using MailetContext().getConnection( key ) gets my vote
(where key is a key to one of possibly multiple datasource URLs declared by
a particular mailet type).

Cheers, Steve.

(who is watching the Mailet spec subject with interest as it is terribly
consistent with thoughts I have about containment/containers and the 
freedom
developers should have with respect to lifecycles, lifestyle, etc.).

:-)

--

Stephen J. McConnell
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: pop3-file bug

[Stephen McConnell]

Serge Knystautas wrote:


Stephen McConnell wrote:
>
>
> Applied.
>


Egads!!!  Please read the reply I just finished... I really don't 
think you wanted to do that...


I just read the reply!
I'll revert the change.
Steve.

--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Re: pop3-file bug

[Stephen McConnell]

[EMAIL PROTECTED] wrote:


- Original Message -
From: [EMAIL PROTECTED]
Sent: Dec 20, 9:00 PM

 

I agree it is trivial to fix. I think it is is even more trivial than what Iwasa is suggesting.

In Avalon this would be the fix.
RepositoryManager

public static final String getName()
{
-return REPOSITORY_NAME + id;
+return REPOSITORY_NAME + id++;
}

   


Sorry it is the other way Repository Manager diff should be
 public static final String getName()
 {
+return REPOSITORY_NAME + id;
-return REPOSITORY_NAME + id++;
 }
 


Applied.

--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: pop3-file bug

[Stephen McConnell]

[EMAIL PROTECTED] wrote:


- Original Message -
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
Sent: Dec 20, 11:12 PM

 

It's very easy to fix the numbering... but some work to offer backwards
compatibility.
 

The numbering fix looked trivial from Iwasa Kazmi's patch
(http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]
e.org&msgId=572609).
   



I agree it is trivial to fix. I think it is is even more trivial than what Iwasa is suggesting.

In Avalon this would be the fix.
RepositoryManager

public static final String getName()
{
-return REPOSITORY_NAME + id;
+return REPOSITORY_NAME + id++;
}
 


That's it?
Let's just fix it in Avalon.
Steve.


I am fairly certain this Avalon bug can be worked around inside James in a fairly contained manner.

If this is to be done in 2.1, and no one else has started doing work on this, I can put together a patch. 

The patch I was thinking of would be about ~10 lines of code change in James. Basically the problem is name of repository key depends on initialization order. This can be fixed in Avalon or reset in in AvalonMailRepository.

Harmeet
 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Release 2.1

[Stephen McConnell]

+1

Nicola Ken Barozzi wrote:



As a developer
---

Please, get this F***ing 2.1 release out of the door.
It works very well with a DB, just disable the filesystem repos and 
mark them as "unstable" or something. Then get a 2.1.1 release out 
right after.

Release early - release often.

And please, let's stop this thread. It's not constructive and has a 
stupid header that is simply wrong and unfair to you all.

Also, sorry if my mails on mirroring stirred up things, it was not my 
intention.


As a user
---

Please, get this F***ing 2.1 release out of the door.  ;-)

And get 2.1.1 our *right after*.


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

file based persitence

[Stephen McConnell]

From memory there is a virtual file system package in commons or 
somewhere like that - does anyone know any details ?

Cheers, Steve.


Danny Angus wrote:

James in in a code freeze pending release of version 2.1

I can't say when the release is likely to happen, but it is unlikely that
this issue is going to be addressed before then.

The reason for it not being fixed before now is because we inherit it from
Avalon.
We are intending to replace that with our own filesystem code in the next
cycle.

d.


 

-Original Message-
From: Dejan Nenov [mailto:[EMAIL PROTECTED]]
Sent: 19 December 2002 07:44
To: [EMAIL PROTECTED]
Subject: There is no active development on James


To any committers / active contributors to James development out there -
can you please review and verify bug 15460 - unless no one else can
reproduce the problem - it seems to be making James totally unusable!



Thank you,



Dejan


   



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [GUMP] Build Failure - jakarta-james

[Stephen McConnell]

/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/core/AvalonMailStore.java:205: select(java.lang.Object) in org.apache.james.core.AvalonMailStore cannot implement select(java.lang.Object) in org.apache.avalon.cornerstone.services.store.Store; attempting to use incompatible return type
   [javac] found   : org.apache.avalon.framework.component.Component
   [javac] required: java.lang.Object
   [javac] public synchronized Component select(Object hint) throws ComponentException {
   [javac]   ^

 


This appears to be a result of a change to corenerstone back on around 
the 24 September (refer revision 1.6 to 1.7) in which ComponentSelector 
was replaced by ServiceSelector without a component version increment. 
I'll CCing this to Avalon dev to see if the guys can take care of this.

http://cvs.apache.org/viewcvs/jakarta-avalon-cornerstone/src/java/org/apache/avalon/cornerstone/services/store/Store.java

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:   
For additional commands, e-mail: 

Re: Build From CVS has Warnings?

[Stephen McConnell]

Kenny Smith wrote:


Hey all,

Since I'm still new getting and building releases out of CVS I wanted to
check to see if it's ok that I got this and if you experienced it when you
built:

warning: ComponentException(java.lang.String,java.lang.Throwable) in
org.apache.avalon.framework.component.ComponentException has been deprecated
 throw new ComponentException( message, e );

I got it in 11 different places.



This is correct.

The Component interface has been deprecated as of version 4.1.2 of the 
Avalon framework.  The reason that this interface has been deprectated 
is that it forces developers of now component to implement the interface 
even though the interface declares no operations.  This can be a real 
PITA for anyone dealing with legacy or Avalon independent components. 
There is not replacement for component - instead the entire 
framework/component package is deprecated in favour of the 
framework/service package in which services and components are simply 
derived from java.lang.Object.

In terms of James there has been several message about this and the 
interest/need for James to migration from the component pacakge to the 
service package.  This seems to have been deferred for now as there are 
implications in the Mailet implemenation and (and potentially in the 
future the mailet interface).  In addition, there have been upgrades to 
the Avalon Cornerstone package to migrate towards the service package 
but this needs to synchronized with projects such as James.

I.e. the message are normal - and I think (as a non-committer) it is 
fair to say that resolution of this is on the James agenda.

Cheers, Steve.


Kenny Smith
JournalScape.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] James as an official Apache project

[Stephen McConnell]

Danny Angus wrote:


All,

Now that we've had a chance to digest whats meant by a top level project, I'll subject you to my opinion, which I've held back so far.

Basically I'm in favour of proposing james as an apache top level project (tlp), I'm prepared to take the lead on our proposal, and here's why:

James has a small yet mature community, we seldom seek recourse to the jakarta PMC, and equally seldom are we scrutinised by them. We are not the most active project, and I feel that this sometimes causes James to be disregarded. Likewise, apart from Avalon, we have few direct ties with other jakarta projects, and little in common apart from the language/platform and culture (but the culture is Apache)

The tlp issue is more about management than web-site and mail addresses, I don't believe that james.apache.org will bring many benefits, but I do think that normalising our managerial relationship with Jakarta by becoming a sibling rather than a child, and taking official control of all the issues we currently inherit and "interpret" from Jakarta would benefit James. The James PMC would be responsible to The Board.

I do believe that Jakarta is becoming too big to function as a single project, that community and culture become diluted as you descend the heirarchy and that one solution is for mature projects leave the nest. Of course other projects are free to make their own choices but as James consists primarily of the server which is an end-user product I feel that top level project status, emphasisng its purpose rather then its technology, would suit it well.

The proposals being discussed on reorg & community include the notion of federated projects, James, with the approval of the Jakarta PMC, could continue to be associated with Jakarta, I would like to think that we wouldn't be leaving Jakarta, just growing up. I also know that James would continue to rely on Jakarta for code, insight and cool thinking, but we don't need to be a Jakarta sub-project for that.

It would also give us the opportunity, as Serge mentioned, to better promote our sub-projects, theres Mailet, and mailets, and there are the beginings of full blown mailet applications.

So.. we've had time to examine the issues, lets vote.. 

Should we prepare a proposal for submission to the board, that James be elevated to a top level project?

  [ ] +1  I think it's a good idea 
  [ ] +0  I'll accept the majority decision, stop bothering me
  [ ] -0  I have reservations 
  [ ] -1, I don't think its a good idea
 


+1

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:   
For additional commands, e-mail: 

Re: performance figures w/ spool enabled

[Stephen McConnell]

I have to agree with Steve on this (i.e. a non-official +1).

I had problems during James depolyment a couple of months ago - part 
James, part Cornerstone, - basted on the current status I'm getting 
ready to lauch another assault on James deployment.  I know based on the 
emails that things are looking good and we are mocving into predicable 
behaviour + performace measurement.  This is such a big plus over and 
above 2-3 months ago.  I'm really looking forward to playing some more 
with the release - and the last thing I want is somethig odd that 
doesn;t tie into the results reported ovet the last weeks - not that I 
think that there will be anything different - but I will feel better if 
is deferred until post release.

Cheers, Steve.


Steve Short wrote:

Defer, defer, defer.  There have been a number of issues with file
repositories in the past 9 months or so, and without a decent set of
regression tests you risk re-introducing old problems such as the
ConcurrentModificationException or the 0 size file.  At the moment they
are stable and working reasonably well - don't touch them - please.

There is already a todo list item tabled for v3.0 to revisit the
repostories (mailbox versus spoool queue repositories) and this would be
a better place for this work.

Regards
Steve

 

-Original Message-
From: Noel J. Bergman [mailto:noel@;devtech.com] 
Sent: Monday, October 28, 2002 10:27 AM
To: James Developers List
Subject: RE: performance figures w/ spool enabled


I'll give it a shot.  Mind you, one difference is that the 
JDBC spool code is able to iterate through the first 1000 
entries of the database, whereas each call to 
loadPendingMessages() for the file system will have to clone 
the entire HashSet again.  But if we can keep that down to 
once or twice a minute instead of hundreds of times per 
minute, it ought to help.

I'm going to pull the pending messages code into a common 
class with an abstract load method.

	--- Noel

-Original Message-
From: Peter M. Goldstein [mailto:peter_m_goldstein@;yahoo.com]
Sent: Monday, October 28, 2002 12:23
To: 'James Developers List'
Subject: RE: performance figures w/ spool enabled

   

Noel J. Bergman wrote:
 

Serge wrote:
 (2) Use the same approach found in JCBCSpoolRepository,
 where we maintain a small cache of keys.  When the
 list is exhausted, it is reloaded.  I believe that I
 can pretty much clone the code from one to the other,
 with the obvious change in populating the list.

Are either of those approaches something that we want to undertake
   

for
   

v2.1?
 

Do you want to consider this a bug fix, or a performance 
   

enhancement
to
   

defer?  I don't have a problem implementing the change, 
   

but I don't
want
   

to
 

undertake it today if we don't want it until after the release.
   

If you can get the code from JDBCSpoolRepository and pretty quickly
 

get
   

this alternate approach running, then see how your 
 

performance tests 
   

do... if it's an improvement, I would go ahead and put it 
 

in.  In my 
   

mind it's known logic, so it's not that big of a deal.
 

I'm of the same mind as Serge on this one.  If the logic is 
already written and has been shown to work, I say put it in.

--Peter



--
To unsubscribe, e-mail:   
 [EMAIL PROTECTED]>
For 
additional commands, 
e-mail: 


--
To unsubscribe, e-mail:   
 [EMAIL PROTECTED]>
For 
additional commands, 
e-mail: 


   


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: *** PLEASE STOP ***

[Stephen McConnell]

Noel J. Bergman wrote:


Sorry about that. I was a bit ticked off and that may have showed.
I do intend to be positive, but it is hard sometimes not to push
back.
   


Well until everyone STOPS pushing back at each other, calms down, and
focuses on code, this is going to continue to spiral, until it breaks.  And
that is the last thing anyone wants.

 

Help is always appreciated, but at this point
you're driving Peter bonkers,
 


Both of those are are pretty fair assessments.  But everyone probably owes
everyone an apology for SOMETHING around here lately.  So I'll say it for
everyone, so that no one has to step up and admit that he or she might have
stepped over a line somewhere: I'M SORRY.  WE'RE ALL SORRY.

Now ... let's not have any more personal attacks.  No more calling someone
else a liar.  No more revisiting the past.  We've got code in the CVS now,
and we want to move forward FROM HERE.

Computers run code.  They don't care about egos, personality, or even
perceptions of intelligent life.  They just run the code.  It either works,
or it doesn't.

As I understand it, the rules are that if someone, anyone, delivers good
code then we are supposed to have a good reason for rejecting it.  On the
other hand, the rule is that if code is submitted by someone, anyone, that
we don't believe we can in good conscience support, then we are justified to
give our technical reaons and reject it.



+1

But I'm really really impressed with the James level progress over here.

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:   
For additional commands, e-mail: 

quote of the week

[Stephen McConnell]

Been distracted with the multitude of emails on the reog list and only 
just managed to get up to speed on James - in doing so I really liked 
the quote in Noel's email:

 Thomas Kuhn would likely argue, we often require failure before
 we are motivated to undertake structural change.

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:   
For additional commands, e-mail: 

Re: Where do we go from here.

[Stephen McConnell]

Harmeet Bedi wrote:


We should have a plan and release manager for the next major release.



+1



Here are some ideas.
- Have a single, standard repository API. Noel, others have mentioned JNDI.
- Move all protocols including NNTP to use that repository API.
- IMAP Server support.
- Test Bed to check RFC compliance, performance and stability.
- Experimental MS Exchange Protocol Support.
- Move away from Avalon/Phoenix. There has been some talk on this topic. We
could keep the framework part and not use Phoenix if this is a sensible
goal.



I would rehprase the last point - istead of moving away from Phoenix, 
think about it as seperating execution from deployment cocerns.  Phoneix 
is a cool application for handling complex component deployment.  The 
key feature of seperation  is being able to choose - and choice is liberty.

Cheers, Steve.



I think, we should first only collect all the possible things we could do
and then figure out what it takes to do it i.e. design changes etc.
It may also be a good idea to cap the expected time frame of next release. A
good time frame may be 6-9 months.

comments...
Harmeet


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code change the Apache way

[Stephen McConnell]

Danny Angus wrote:


p.s. I don't know anything about the context of this dicussion :-)

Cheers, Steve.
   


Well done then for hitting the nail on the head!

As far as I can ascertain the rules mean this; That although the policy is "comit then review", and review is subject to lazy concensus (ie  abstention is tacit aceptance) changes affecting architecure, existing functionality or design policy which are likely to provoke comment are best discussed beforehand and concensus reached, with or without a formal vote on the issue.

If the community is working well discussions will be taking place anyway.

This is one very good reason to keep technical discussions on the list, not behind the scenes, even where the perticipants feel that it would be of no value to have them in public, perhaps because they are esoteric, of marginal relevance to the overall picture, or just plain dull.

As far as a veto, I agree with Steves analysis that vetos have to be justified, and that the only way to remove a veto is by reaching concensus with the vetoer. In the case where concensus can't be reached, the PMC are there to help resolve issues, but I couldn't imagine resorting to this drastic step would do much more than harm the community, whatever the outcome.



Dany:

I hate to say this but I total  disagree concerning the PMC.  I really 
think that there is a *major* fobia concerning project to PMC 
interaction.  Projects like James and Avalon and I'm sure other should 
be making PMC members work their buts off for and on behalf of the 
projects they are representing.  IOf they don't have the bandwith then 
the need to expand capacity - look at Jakarta today - it does not have 
the bandwith to handle everything - which means that there is a 
potential that they are not representing you.  Due to that flack on the 
reorg list concerning licensing I'm currently working with the PMC to 
come up with a license solution with will take a lot of icky stuff out 
of the code that I have committed (icky from a legal point of view). 
The actions of the PMC have a potential to make the work I'm doing much 
easier - engage more comitters in content I'm directly involved within. 
I've been stuffing around with getting solutiuon "by myself" for 9 
months - then I went to thr PMC - winthin 48 hours we have a couple of 
people who have the necessary contacts to make things happen jumped up 
and voluteer to help.  The board jumped in with opinions wich provide me 
sufficient guidance so that I know what to do to conform with the 
"Apache Way".

Working with your PMC is a positive thing.
Making your PMC work for you is even better.

:-D

Cheers, Steve.


All of the above helps to reduce the possibility of code yo-yo-ing between two competing designs.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Code change the Apache way

[Stephen McConnell]

Noel J. Bergman wrote:


Serge,

Judging from "All other action items are considered to have lazy approval
until somebody votes -1, after which point they are decided by either
consensus or majority vote, depending on the type of action item" it seems
that lazy simply means that it is accepted until rejected.  On the one hand,
it means that a Committer on vacation can't be "surprised" when he or she
gets back.  On the other hand, I don't see what (on paper) prevents a
Committer from rejecting decisions made months or even years previously.

Practically, this surely can't happen (or at least often), or nothing would
get done.  I'd venture that the rules work best where everyone tacitly
agrees to seek the best solution for the project.  I don't see what
procedures are provided for resolving conflict, other than discussing it
until everyone agrees on something.  Other parts of the Jakarta site
emphasis the importance of community building, so apparently part of the
solution is getting along.

In any event, I'd be interested in hearing more from experienced Apache
members just informationally, but hopefully it won't be a practical issue
here.



I can give you my understanding (having gone though though this).  If a 
committer has contributed to a particular source file, that contributor 
can -1 the action.  Generally speaking the only course of action is for 
the community to lobby that committer to change his/her mind.  There is 
a qualification that a committer must provide justification, however 
that justification may be totally irrelevant or oven irrationale.  The 
committer right to veto holds.  The standard solution presumed under the 
Jakarta framework is that the option is always available for a fork to 
take place.  Within small scenarios this is workable - within larger 
scenanarios the single committer veto start to fall appart - because of 
the implications of forking of a large scale project.  There is an 
option to request mediation from the Jakarta PMC - just email 
[EMAIL PROTECTED] with a request for assistance.  I've been told 
not to do this in the past - but its clear from the reorg list that the 
PMC is there to work for you in thise sort of cases.  

p.s. I don't know anything about the context of this dicussion :-)

Cheers, Steve.



Thanks for the kudos.  And I agree with you regarding ASF.  I think that it
is definitely the right kind of organization, with the best attitude towards
licensing, allowing a synergistic mixture of open (Tomcat) and closed
(Websphere) participants contributing to a common code base.

	--- Noel

-Original Message-
From: Serge Knystautas [mailto:sergek@;lokitech.com]
Sent: Friday, October 25, 2002 0:13
To: James Developers List
Subject: Re: Code change the Apache way


Noel,

Technically, I think you're right.  I read this half a dozen times
before sending my previous email, and with another half a dozen reads,
I'm still confused but now leaning towards your interpretation.  I was
deriving significance from the term "lazy", although it's never defined
in the document.

As for a clarification, you'll have to request one from the Jakarta PMC.
 From my memory, I thought voting used to be typically majority-style.
 But from this doc, a release plan and a release testing are the only
actions that are to use this vote-style.  All others should ultimately
be consensus.  I have to think this is backwards... changing CVS
requires consensus but making a release doesn't?

Anyway, kudos on being a committer.  I firmly believe the ASF has
produced so much great stuff, and it's because it has the right style...
from licensing model to decision making approach to project proposal
credentials to culture.  I think the interpretations and the future
re-org are relatively minor and just clarifying what's largely already
in place. (saying the rules and regs aren't heavy and not a big part of
the culture, imho.)

--
Serge Knystautas
Loki Technologies
http://www.lokitech.com/

Noel J. Bergman wrote:
 

a code change [only needs] a majority vote (even a -1 isn't blocking).
 

Please explain this.  Because I really want to understand, and I had
understood it differently.  From
http://jakarta.apache.org/site/decisions.html:

"Changes to the products of the Project, including code and documentation,
will appear as action items in the status file. All product changes to the
currently active repository are subject to lazy consensus."

I'd interpreted this to say that CVS changes are subject to lazy
   

consensus.
 

And the document says that "[an] action requiring consensus approval must
receive at least 3 binding +1 votes and no binding vetos."

Please explain where I missed the point, and where I can find more
illuminating information.  I figure that between my being a new Committer,
the talk about a PMC, and having to stand in front of 600 people in 10
   

days
 

talking about all of the wonderful Java technologies from Apache, it is
probably a good idea to get mor

Re: Jakarta-james new commiter Noel J Bergman

[Stephen McConnell]

Good stuff!

Danny Angus wrote:


Dear all,

In accordance with The Apache Way as she is written Jakarta James commiters have elected Noel J Bergman as a new commiter with 5 +1's and no -1s (one -1 was changed to +1 after some debate) 

+1's

Danny Angus  "danny"
Peter M. Goldstein "pgoldstein"
Serge Knystautas "serge"
Charles Benett "charlesb"
Harmeet Bedi "hbedi"


Welcome Noel.

d.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: [VOTE] New Commiter Noel J Bergman

[Stephen McConnell]

Serge Sozonoff wrote:


All,

I know I can't vote, but.. +1

I don't understand how anyone can vote otherwise, all you have to do is read
the last several months of this list where From = Noel Bergman to realise
that Noel knows his stuff and is able to contribute to *any* portion of
JAMES including IMAP.



Serge you said it all - I can't vote either but here is my +1 for Noel.
Harmeet - *please* reconsider your position.
Cheers, Steve.




Serge

- Original Message -
From: "Danny Angus" <[EMAIL PROTECTED]>
To: "James Developers List" <[EMAIL PROTECTED]>
Sent: Saturday, October 19, 2002 11:46 PM
Subject: [VOTE] New Commiter Noel J Bergman


Guys,

I'd like to propose Noel as a commiter, If I have to detail his
accomplishments you've been too inactive.. Over the last months Noel has
contributed code and opinion, offered his help on the Users list and
mediated in Robust Discussions.

Failing to elect Noel would rob James of one of our most enthusiastic
participants.

d.

start the count with my +1


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 



 


--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Phoenix 4.0.1 preview release

[Stephen McConnell]

Harmeet Bedi wrote:

>There was some talk of having Avalon LogKit and Log4J both underneath the
>logger abstraction.
>
>Does anyone know if that was done ? Is there a way to use Log4J and separate
>the log configurations through log4j specific config file ? Not sure which
>logging toolkit is better but was wondering if this facility is existing
>now.
>

The Excalibur Logger package (excalibur/logger) includes multiple 
logging implementations - Log4J, LogKit, the JDK 1.4 Logger, etc.  For 
configuration details you should post a question on the phoninx list.

Cheers, Steve.

>
>Harmeet
>- Original Message -
>From: "Peter M. Goldstein" <[EMAIL PROTECTED]>
>To: "'James Developers List'" <[EMAIL PROTECTED]>
>Sent: Wednesday, October 16, 2002 11:10 AM
>Subject: FW: Phoenix 4.0.1 preview release
>
>
>  
>
>>Folks,
>>
>>Sorry to have been absent for the last 12 hours or so - the flu I've
>>been fighting for the last week just knocked me out.
>>
>>Anyway, on another topic, this is a response from Paul Hammant on the
>>Avalon Applications Developer list.  It regards the problem that
>>everyone has observed when going from the beta Phoenix 4.0 to the
>>release - all the log files are collapsed into the default.log.
>>According to Paul, this issue is resolved in Phoenix 4.0.1, which is
>>currently in Preview.  I'm going to find out the official release date,
>>and then we can have a meaningful on list discussion of our options with
>>regard to this issue.
>>
>>--Peter
>>
>>-Original Message-
>>From: Paul Hammant [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, October 15, 2002 11:07 PM
>>To: Avalon Applications Developers List
>>Subject: Re: Phoenix 4.0.1 preview release
>>
>>Peter
>>
>>
>>
>>>My second question is, if so, is it resolved in Phoenix 4.0.1?
>>>
>>>
>>>  
>>>
>>We believe it has...
>>
>>- Paul
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
>>For additional commands, e-mail:
>>
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
>>
>
>  
>
>>For additional commands, e-mail:
>>
>>
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Status of James load tests

[Stephen McConnell]

Noel J. Bergman wrote:

>>- Test with a month or few months old version of James after
>>  commenting out scheduler from SMTP Handler.
>>
>>
>
>I don't believe that the scheduler is the issue.  Peter's code uses the
>Watchdog, and that code doesn't create any new object instances during the
>main loop of the handler:
>
>  while (parseCommand(readCommandLine())) {
>  theWatchdog.resetWatchdog();
>  }
>
>
>  public void resetWatchdog() {
>  lastReset = System.currentTimeMillis();
>  }
>
>Since I can reproduce this problem on a single connection, we are never
>leaving that loop, and therefore it implies that the problem is most likely
>somewhere within the handling body.
>
>  
>
>>We should find out from Avalon lists or ask Avalon folks
>>
>>
>  if they know of any memory leak issues.
>
>Since we have commented out the sendMail operation, the same logic applied
>above should also tentatively eliminate the Avalon lifecycle components from
>consideration, as well as the Avalon thread pool.  Only the Avalon logger is
>used.
>

Just a quick comment on the Avalon logger.  First point is that you need to
address the particular logging implementation.  The default in James is the
LogKit implementation.  Something you should be aware of concerns the usage
of logging catagories in LogKit - i.e. if you declare a logging category
named "james", then a sub-category named "smtp" then both the "james" and
"smtp" catagories exist for the lifetype of the application.  If a componet
does something like the creation of a logging channel using an instance 
name,
then you can get into a memory problem:

  E.g. a log entry like the following is BAD if the number of
  subcategories is significant because catagories are not
  released.

james.smtp.0125369 hello world

Taking a quick look through the James sources, there are only a couple of
occurances of logging sub-category creation (James and FetchScheduled).  In
both cases the number of assigned sub-categories is either static or linked
to a static configuration set - in other words - I don't think you will
be seeing any problems that could be attributed to LogKit.

Cheers, Steve.


>
>>Another possible idea: Create a James version without Avalon
>>and see if that is better. Mixed feelings about this but may
>>be good to look into.
>>
>>
>
>ROFL.  Right, I'll get right on that, I will.
>
>What would be useful is if the handlers were more easily unit tested.  I'll
>run some tests with -verbosegc turned on (q.v.,
>http://www.javaworld.com/javaworld/jw-01-2002/jw-0111-hotspotgc.html).
>
>Perhaps other folks might like to help look through the main loop processing
>for a "HELO, MAIL FROM, RCPT TO, DATA" cycle, and see if they can spot any
>issues.
>
>   --- Noel
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Followup: AbstractJamesService and Watchdog

[Stephen McConnell]

Peter M. Goldstein wrote:

>Stephen,
>
>  
>
>>Just took a peek at the sources attached to your email - I was
>>
>>
>wondering
>  
>
>>about the following defintion in the .xinfo file:
>>
>>  
>>>version="1.0"/>
>>  
>>
>>This is basically saying the the POP3Server is providing a service
>>interface
>>corresponding to Component.
>>
>>That a little odd because:
>>
>>  (a) it means that a container may proxy this component to 
>>  expose only Component (which is nothing)
>>  (b) a container may complain because your exposing a internal 
>>  interfaces as opposed to a formal work interface
>>  (c) if the real case is that this is a component that does 
>>  not provide a publically accessible services then the 
>>  better approach is to simply drop the  element 
>>  from the .xinfo file.
>>
>>I would have though that this component was actually providing a
>>services - but I'm not familiar with POP3 stuff so I'm not in a 
>>position to say what that service interface would be.
>>
>>What do have in mind?
>>
>>
>
>Basically these lines are leftovers.  I didn't add them, but I didn't
>want to muck with removing them.  I agree with you - they probably
>shouldn't be there.
>  
>

It's safe to remove the  declaration - in fact I recommend it 
as the current declaration will probably generate warning in Phoenix 
(that last time I check Phonenix there was a handler that was checking 
from implementation classes but it was comented out probably because it 
was breaking too much stuff).

>Realistically, I don't think we'll be able to run in a non-Phoenix
>container before some of the changes coming with the next revision.  
>

Problems running in alternative containers are not linked to James.  The 
problem is related to Cornerstone (on which James in dependent).
Cornerstone resources depedent on the Phoenix platform include:

  DefaultDataSourceSelector
  AbstractFileRepository
  SSLFactoryBuilder

  (and a couple of the AltRMI classes)

 From memory James in depedent on the AbstractFileRepository (when using 
the default configuration).  I have James running under the Merlin 
container using a slightly patched version of Cornerstone (i.e. purged 
of container depedencies).

The real benefit of the next James revision will be reduced dependency 
on the framework (i.e. Avalon leverage instead of Avalon lock-in by 
migrating to the ServiceManager package).

>So
>I haven't really worried about (b).  But you're right - to generally
>support Avalon containers we need to modify the .xinfo file so we don't
>export internal interfaces.
>

Just drop the  element - things will work fine in Phoenix and 
Merlin.  It's perfectly OK to declare a compoent that does not export 
services.

Cheers, Steve.

>
>--Peter
>
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Socket Performance

[Stephen McConnell]

Danny Angus wrote:

>In my opinion James socket problems would be greatly reduced in impact if James 
>behaviour was as follows..
>
>connections are accepted
>-> resources are consumed
>-> limits are approached
>-> connections are refused
>-> resources are freed
>-> connections are accepted
>
>
>rather than the current situation which is that connections are accpeted until 
>resources are exhausted, and James never recovers.
>
>
>In addition it concerns me that we can't run James under the -server JVM otpion on 
>linux because Avalon causes a failure (attached message)
>

No seeing an attached message - can you resend ?

Steve.

>Tomcat 3 under heavy and sustained load ends up with an out of memory exception, 
>-server cures it, largely because of the more agressive garbage collection.
>
>In my opinion it is right for us to optimise our use of resources, but impossible to 
>create a server that will sustain any load applied, what we need to do is ensure that 
>the server will continue to function, even if this means rejecting connections.
>This route will provide a scalable and robust solution.
>
>d.
>
>
>--
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail:   
For additional commands, e-mail: