Peter M. Goldstein wrote:

Stephen,


Then ...

$ cd <avalon-dir>
$ ant

Done.


$ cd <excalibur-dir>
$ ant

Done.


$ cd <cornerstone-dir>
$ ant -buildfile cornerstone.xml

Done.

Note - I have just updated the corenerstone.xml buildfile (in CVS - now references excalibur-pool-1.2.jar).



$ cd <james-dir>
$ ant -buildfile james.xml

Done. Although I needed to make an interesting change here. Specifically,
I needed to change the import statement:

import org.apache.avalon.cornerstone.services.datasource.DataSourceSelector;

to

import
org.apache.avalon.cornerstone.services.datasources.DataSourceSelector;

I suspect this is a packaging issue with the cornerstone-datasource-1.0.jar,
since the former appears to still be present in source control.

Sorry about that - I've updated the james.xml build file to include a patch target to replace all occureses of "*.service.datasource." with "*.service.datasources." - this reflects a datasource package that uses the ServiceSelector as opposed to CompoentSelector. You will need to do the update on all your sources in James the reference service.datasource (including the James.xinfo file).


$ cd <avalon-sandbox>
$ cd merlin
$ ant

Done.  Found a bug in the config (it uses the old
File_Persistent_Stream_Repository, File_Persistent_Object_Repository).
Fixed it.

Thanks - fixed.

// edit the blocks.xml file to make sure the james block is enabled
// and that the demos are disabled then launch merlin

$
$ start demo

And here we have a problem.  When I type "start demo" I get:

C:\development\apache-cvs\avalon-sandbox\merlin>java -classpath
build\lib\avalon
-merlin-bootstrap-2.1.jar org.apache.avalon.merlin.bootstrap.Merlin
merlin.prope
rties
[INFO   ] (sys): initialization from:
C:\development\apache-cvs\avalon-sandbox\m
erlin on localhost
[INFO   ] (sys):

commencing block construction phase

[INFO   ] (sys): block count = 3
[INFO   ] (sys): [james/14780827]
[INFO   ] (sys): [playground/17905186]
[INFO   ] (sys): [demo/16316379]
[INFO   ] (sys):

commencing structural assembly phase

[ERROR  ] (sys): Message: Unable to deploy block: [james/14780827] due to a
structural assembly failure.
===================================================================

Exception: org.apache.avalon.assembly.lifecycle.AssemblyException
Assembly failure attributable to embedded appliance.

Cause: org.apache.avalon.assembly.lifecycle.AssemblyException
Unable to deploy a supplier for a service dependency:
[org.apache.james.services
.MailStore] org.apache.james.services.MailStore:1.0.0

Cause: org.apache.avalon.assembly.appliance.ApplianceException
Unresolvable assembly graph for appliance: [mailstore/29086271]

Two things here:

1. the exception handling in Merlin had a bug in that it was not passing the causal exception and as such the error report is not so helpful. This is now fixed and some of the related error message have been brushed up.

2. my guess is that you didn't update xinfo files contianing references to the *.service.datasource" to the ...s package name. This would cause the assembly stage exception (which would a lot clearer based on the updates in Merlin I've just mentioned)

[INFO   ] (sys):

commencing decommissioning phase

[INFO   ] (sys):

commencing termination phase

java.lang.NullPointerException

That should not have happen - have made some changes in Merlin - but anyway its not central to the James deployment question.

$ cd <james-dir>
$ cd tests
$ ant -buildfile test.xml
$

And obviously I don't get here.

I find the problem difficult to debug because I know absolutely nothing
about Merlin.  It happens both before and after I make the changes to the
configuration file, so it's not due to the changes I cite above.  Any help
in debugging this would be appreciated.  Thanks.

I confident the issue is inconsitentcy in the packkage names for the "...service.datasources". Also the updates on Merlin should make things clearer what is happening. IIf you want to see what is happening inside Merlin - go into the kernel.xml file and look for the fololowing categories defintion and set it to DEBUG instead of INFO (and you will get a lot more information about what is or is not happening).

<categories>
<category name="/sys" priority="INFO"/>
</categories>


Now, onto Phoenix. I've built a sar file out of the latest and greatest
files, and am having issues deploying it in Phoenix 4.0.3.

When I try and use the excalibur-thread-1.1 in this version of Phoenix,
nothing works. This is kind of what I expected from Peter D.'s earlier
comments, so I wasn't surprised.

I didn't have any problems (build against excalibur thread 1., replaced Phoenix thread jar with 1.1 and everything worked OK).

Then I tried something different - I reverted the DefaultThreadManager
change (side note, this change is wrong - the constructor arguments should
be minThreads,maxThreads not maxThreads,maxThreads) and reverted the
cornerstone dependencies to excalibur-thread-1.0.jar .

However when I tried to deploy these individual Cornerstone jar files, I got
an error on starting up Phoenix that referred to 7 missing extensions.

Yep - there seems to be a problem in Phoenix concerning extension handling. I've already committed updated to the cornerstone build procedure to disable the extension depedency declarations. It seems that Phoenix is not considering the jar files that are loaded from the sar lib as extension candidates. Anyway - with the current corenerstone.xml based build - you will not have this problem.

Finally, I deployed with a single cornerstone.jar built off the current
Cornerstone sources with the aforementioned revert.  This worked fine.  My
Phoenix deployment passed basic tests, including the EndToEnd test.   So my
current code appears to work fine, and there isn't a single
Component/ComponentManager to be found anywhere in it.

Based on these tests it seems that:

i) We need a version of Phoenix that runs with the Excalibur-thread-1.1.jar,
but that is reasonably stable (4.0.4?)

I agree - but my hunch is that there will be a few other updates for 4.0.4 relating to getting the Excalibur releases done (e.g. pool 1.2, configuration 1.0, etc.).

ii) The DefaultThreadManager patch needs to be fixed

It is fixed - not following you here.

iii) Someone needs to give me some advice on Merlin :)
Switch on DEBUG for the "/sys" category and what you will see will explain a lot.
Secodly - once we have something running I'll talking a lot more about packaging and deploying a james block - basically a deployment unit that hides all of the assembly and config and structures it as a single component. That will introduce questions about what services are exposed, and a lot of stuff about mailet registration and so on. This is only the starting point .. :-).

Or take my code base
and figure out what needs to be done to make it run in Merlin.

I think its a good idea - can you email it to me?

iv) The dependency issues for the individual Cornerstone jar files needs to
be clarified.

My position on this is that we should be using the standard extension mechanisms - but I'm going to have to dig into Phoienix to gfigure out what is broken. Once that it resolved - getting jar depedencies documetation can be done formally in the manifest.


Thoughts?

Lots - but in another email :-)

Cheers, Steve.

--Peter



--
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]>

Reply via email to