Harmeet Bedi wrote:
----- Original Message -----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.
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.
A Merlin install means following the directions in the THE_RED_PILL.TXTI am not sure what Merlin Install means. Is it build and add jar files from an Avalon source tag ?
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 ;-)
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.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.
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
.....in an error relating to the thread package. Changes to the thread package
+Running the generated sar file inside the releaed Phoneix will result
to support the max pool limit require excalibur-thread-1.1 wheas Phoenix
used the 1.0 package. To resolve this problem you probably will nbeeed to
rebuild Phoneix with thread-1.1, and replace the 1.0 with 1.1 threads
library in the phoenix distribution.
From: <[EMAIL PROTECTED]>
Subject: cvs commit: jakarta-james/tests README.txt
.....Phoenix that will need to be addressed (see notes in the james.xml file
+However that are conflicts related to the excalibur-thread-1.0 file in
under the sar target). In the meantime if you have Merlin installed you can
run James with the following command:
$ merlin -home tests -profile merlin\kernel.xml -system%MERLIN_HOME%
---------------------------------------------------------------------
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]
