[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Testsuite Compilation failed

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server -

[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Testsuite Compilation failed

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server -

RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref

2003-07-08 Thread Adrian Brock
On Tue, 2003-07-08 at 06:54, Jeremy Boynes wrote: I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external

Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref

2003-07-08 Thread Jan Bartel
Reply inline. I would say the opposite behavior should be the default since if there is an ejb-link it must be resolvable in the scope of the current deployment while a jndi-name cannot in general be resolved since this can refer to an external server that need not even be available during

[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Testsuite Compilation failed

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server -

[JBoss-dev] [ jboss-Bugs-767716 ] bad behaviour findByPK with null arg + commit A

2003-07-08 Thread SourceForge.net
Bugs item #767716, was opened at 2003-07-08 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767716group_id=22866 Category: JBossCMP Group: v3.2 Status: Open Resolution: None

RE: [JBoss-dev] multiple deployment info entries for invoker.war

2003-07-08 Thread Rod Burgett
I see what you are saying about breaking the mirror, the removal of deployers should be controlled by the deployer services. Code already exists in ServerImpl.ShutdownHook.shutdown() to invoke ServiceController.shutdown(), which walks backwards through it's service list to stop, destroy and

Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref

2003-07-08 Thread Victor Langelo
Jeremy Boynes wrote: Scott Stark wrote: There is no need for an ejb-local-ref in the JBoss specific descriptors as the ejb-link element handles this in the standard descriptor. There is no reason why the metadata needs to be expanded to allow for specifying the local home jndi

RE: [JBoss-dev] Handling of ejb-ref and ejb-local-ref

2003-07-08 Thread Jeremy Boynes
Victor Langelo wrote: I agree with Scott. Having a element be optional in the DTD doesn't mean it optional for a correct deployment. The intent is that a deployment descriptor may be written by a developer without the ejb-link. The link will be specified later by the deployer or integrator.

[JBoss-dev] [AUTOMATED] JBoss (HEAD/winxp) Testsuite Compilation failed

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== === NOTE: Sourceforge pserver cvs access is now using the backup server -

[JBoss-dev] Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 8-July-2003

2003-07-08 Thread scott . stark
Automated JBoss(Branch_3_2 WonderLand) Testsuite Results: 8-July-2003 JBoss daily test results SUMMARY Number of tests run: 1369 Successful tests: 1352 Errors:10 Failures: 7

[JBoss-dev] [ jboss-Bugs-767905 ] Farm re-deployment doesn't work

2003-07-08 Thread SourceForge.net
Bugs item #767905, was opened at 2003-07-08 10:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution:

[JBoss-dev] [ jboss-Bugs-767905 ] Farm re-deployment doesn't work

2003-07-08 Thread SourceForge.net
Bugs item #767905, was opened at 2003-07-08 10:00 Message generated for change (Settings changed) made by kevin-duffey You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=767905group_id=22866 Category: Clustering Group: v3.2 Status: Open Resolution: None

Re: [JBoss-dev] Handling of ejb-ref and ejb-local-ref

2003-07-08 Thread Scott M Stark
Ok, then I agree with adding the ejb-local-ref support. -- Scott Stark Chief Technology Officer JBoss Group, LLC Jeremy Boynes wrote: The spec makes the usage optional as well: The Application Assembler *can* use the ejb-link element in the

Re: [JBoss-dev] multiple deployment info entries for invoker.war

2003-07-08 Thread Scott M Stark
Theoretically, but a problem with not using the MainDeployer.shutdown is that the deployment shutdown order will change since the MainDeployer.removeDeployer method is not iterating over the deploymentList in reverse order as is the case for MainDeployer.shutdown. If this is corrected then the

[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Job Failed to Complete Successfully

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== ===

[JBoss-dev] [AUTOMATED] JBoss (HEAD/linux1) Test Results: % ( / ) - fantastic

2003-07-08 Thread Chris Kimpton
=== ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss1.kimptoc.net/ FOR DETAILS== ===

c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino
Hi guys, Over the past two weeks I have started to make a few improvements the current JBossMQ implementation that is in CVS HEAD. I would consider a large porting of what I did refactoring to simplify the current code base to allow future growth without having to sacrifice current features or

Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Scott M Stark
And what interaction has there been with Nathan who originally responded to the rewrite query? -- Scott Stark Chief Technology Officer JBoss Group, LLC Hiram Chirino wrote: Hi guys, Over the past two weeks I have started to make a few

RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Nathan Phelps
Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite so patches to the old JBossMQ have a limited lifetime. That means that changes made to the old JBossMQ will most likely not be part of HEAD or

Re: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino
Scott, Why does it matter? Nathan has not expressed interested in growing from the current JMS implementation. I've been waiting for several months for the new general purpose implementation to 'appear' and it has not. So it's time for me to start the engine again and make some needed

RE: c/s JBossMQ status, was: [JBoss-dev] JBossMQ rewrite

2003-07-08 Thread Hiram Chirino
On Tue, 2003-07-08 at 23:41, Nathan Phelps wrote: In line... Hiram, As you may know, we are going in a different direction with JMS than the original architecture coded by Norbert Lataille. We are doing a rewrite I guess I had it good. Norbert made a good start. At least basic pub/sub