[GUMP] Build Failure - jakarta-james

[Peter Donald]

This email is autogenerated from the output from:



Buildfile: build.xml

prepare-common:
 [echo] Preparing code
[mkdir] Created dir: /home/rubys/jakarta/jakarta-james/dist/james-3.0a1
 [copy] Copying 2 files to /home/rubys/jakarta/jakarta-james/dist/james-3.0a1
[mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/src
 [copy] Copying 2 files to /home/rubys/jakarta/jakarta-james/build/src

prepare-phoenix:
 [echo] Phoenix distribution present - adjusting linefeeds and permissions, 
copying files
 [copy] Copying 40 files to /home/rubys/jakarta/jakarta-james/dist/james-3.0a1

prepare-jdbc3:
 [echo] JDBC v3 in classpath - making code JDBC 3.0 compliant

prepare:

compile:
 [echo] Compiling James Java sources
[mkdir] Created dir: /home/rubys/jakarta/jakarta-james/build/classes
[javac] Compiling 171 source files to 
/home/rubys/jakarta/jakarta-james/build/classes
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/core/AvalonMailStore.java:37:
 org.apache.james.core.AvalonMailStore should be declared abstract; it does not define 
isSelectable(java.lang.Object) in org.apache.james.core.AvalonMailStore
[javac] public class AvalonMailStore
[javac]^
[javac] 
/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]   ^
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/core/AbstractJamesService.java:153:
 cannot resolve symbol
[javac] symbol  : method compose 
(org.apache.avalon.framework.component.ComponentManager)
[javac] location: class 
org.apache.avalon.cornerstone.services.connection.AbstractHandlerFactory
[javac] super.compose(comp);
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/mailrepository/filepair/RepositoryManager.java:33:
 org.apache.james.mailrepository.filepair.RepositoryManager should be declared 
abstract; it does not define isSelectable(java.lang.Object) in 
org.apache.james.mailrepository.filepair.RepositoryManager
[javac] public class RepositoryManager
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/mailrepository/filepair/RepositoryManager.java:111:
 select(java.lang.Object) in 
org.apache.james.mailrepository.filepair.RepositoryManager 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 Component select( final Object hint )
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/mailrepository/filepair/RepositoryManager.java:152:
 incompatible types
[javac] found   : org.apache.avalon.cornerstone.services.store.Repository
[javac] required: org.apache.avalon.framework.component.Component
[javac] return reply;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-james/src/java/org/apache/james/mailrepository/filepair/RepositoryManager.java:198:
 incompatible types
[javac] found   : org.apache.avalon.cornerstone.services.store.Repository
[javac] required: org.apache.avalon.framework.component.Component
[javac] return reply;
[javac]^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 7 errors

BUILD FAILED
file:///home/rubys/jakarta/jakarta-james/build.xml:238: Compile failed; see the 
compiler error output for details.

Total time: 10 seconds

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

Re: Synchronizing James and Cornerstone

[Nicola Ken Barozzi]

Noel J. Bergman wrote:

Gump should have warned us before, but it has not been working
for too much time. We have to fix it. Sam is helping everybody
to get back to making Gump build everything


[...]

One should support contracts for as long as possible, even if just for
binary compatibility.  

[...]

In other
words, if one is going to change a contract don't do so linearly.  I also
suggest that such changes only occur on major release boundaries.


Correct. Gump is not the solution, but an early warning system.


I have a better idea. We are floating the possibility of opening our
Component repository to the projects that are using Avalon, and that
would include James. Would that be a deal?



I just starting looking at your proposal.  It sounds as if it basically
would make Committers from Avalon-using projects Committers on the
components part of the Avalon landscape, and allow us to commit fixes to
Avalon components, e.g., Excalibur and Cornerstone.  Of course, you could do
that simply make us committers on those modules.


Yes. The unification is another aspect of the proposal, more targetted 
to the needs of Avalon as a project to reunite in a more coherent vision.

But we still need to change James because of interface changes, so unless
Avalon is proposing rolling back those changes (which might be even more
work at this point), I'm not sure how it is a better idea than updating
James with Stephen's help.


This proposal is made with in mind a better relationship between James 
and Avalon for the future.

I put myself in your situation, and thought that I would never use 
Avalon Components again unless I was able to have access to their CVS. I 
would also want to veto and revert changes if Gump fails badly, and 
partecipate in their life.

Hence the proposal.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


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

cvs commit: jakarta-james/src/java/org/apache/james/transport/mailets RemoteDelivery.java

[serge]

serge   2003/01/12 12:44:10

  Modified:src/java/org/apache/james/transport/mailets
RemoteDelivery.java
  Log:
  Split a heavy line into first declaring a boolean, and documenting what the boolean 
means.
  
  Revision  ChangesPath
  1.38  +15 -8 
jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java
  
  Index: RemoteDelivery.java
  ===
  RCS file: 
/home/cvs/jakarta-james/src/java/org/apache/james/transport/mailets/RemoteDelivery.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- RemoteDelivery.java   7 Jan 2003 12:02:13 -   1.37
  +++ RemoteDelivery.java   12 Jan 2003 20:44:09 -  1.38
  @@ -55,11 +55,11 @@
* You really want to read the JavaMail documentation if you are
* working in here, and you will want to view the list of JavaMail
* attributes, which are documented here:
  - * 
  + *
* 
http://java.sun.com/products/javamail/1.3/docs/javadocs/com/sun/mail/smtp/package-summary.html
*
* as well as other places.
  - * 
  + *
* @author Serge Knystautas <[EMAIL PROTECTED]>
* @author Federico Barbieri <[EMAIL PROTECTED]>
*
  @@ -258,7 +258,7 @@
   log(exceptionBuffer.toString());
   //Assume it is a permanent exception, or prove ourselves 
otherwise
   boolean permanent = true;
  -if ((me.getNextException() != null) && 
  +if ((me.getNextException() != null) &&
   (me.getNextException() instanceof java.io.IOException)) 
{
   //This is more than likely a temporary failure
   
  @@ -309,7 +309,14 @@
   // possibilities
   
   //Unable to deliver message after numerous tries... fail accordingly
  -return failMessage(mail, ex, (('5' == ex.getMessage().charAt(0)) ? true 
: false));
  +
  +//We check whether this is a 5xx error message, which indicates a 
permanent
  +//  failure (like account doesn't exist or mailbox is full or domain is
  +//  setup wrong).
  +boolean error5xx = ('5' == ex.getMessage().charAt(0));
  +
  +//We fail permanently if this was a 5xx error
  +return failMessage(mail, ex, error5xx);
   }
   return true;
   }
  @@ -352,7 +359,7 @@
   .append(mail.getName())
   .append(" into outgoing after ")
   .append(retries)
  -.append(" retries"); 
  +.append(" retries");
   log(logBuffer.toString());
   ++retries;
   mail.setErrorMessage(retries + "");
  @@ -365,7 +372,7 @@
   .append(mail.getName())
   .append(" after ")
   .append(retries)
  -.append(" retries"); 
  +.append(" retries");
   log(logBuffer.toString());
   }
   }
  @@ -569,7 +576,7 @@
   String key = outgoing.accept(delayTime);
   try {
   if (isDebug) {
  -StringBuffer logMessageBuffer = 
  +StringBuffer logMessageBuffer =
   new StringBuffer(128)
   .append(Thread.currentThread().getName())
   .append(" will process mail ")
  
  
  

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

RE: cvs commit ...

[Noel J. Bergman]

>   Converted tabs to 4 spaces.

Looks like the primary change was trimming trailing spaces.

While you're at it, I believe that we agreed to delete author tags from all
source files.  I do not see any reason to affect such a change in the v2
branch, but we might as well do it on the HEAD.

--- Noel


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

Re: cvs commit ...

[Serge Knystautas]

Noel J. Bergman wrote:

 Converted tabs to 4 spaces.



Looks like the primary change was trimming trailing spaces.


I did just do search and replace on tabs to 4 spaces, but in saving the 
files it does remove trailing spaces as well.


While you're at it, I believe that we agreed to delete author tags from all
source files.  I do not see any reason to affect such a change in the v2
branch, but we might as well do it on the HEAD.


Sounds good.. I'll commit the removal of the author tags in a bit.

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


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

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

[Serge Knystautas]

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.

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


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

Re: Synchronizing James and Cornerstone

[Peter Donald]

Noel, 

I know of only one backward incompatible change made that effects James. It 
was made to AbstractHandlerFactory to make it Serviceable rather than 
Composable. You need all of three line change to fix it up.

-- 
Cheers,

Peter Donald
--
 The fact that nobody understands you doesn't 
 mean you're an artist.
--


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

[Noel J. Bergman]

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

> [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.

--- Noel


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

[Noel J. Bergman]

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

I just verified that manually going to the old code and using ^M^J results
in a 500 error for the ^J, since it is treated as an eol after the ^M has
already been so treated.  The current code does that same.  I think that's
just a buffer timing issue.  My point is that the existing stable code would
also have provided an empty line under the same circumstances.  As a matter
of fact, I believe that the 500 should be sent for an empty line, as it has
been in previous releases.

Check me on something, please.  Look at readCommandLine and tell if me if
the in.mark(1) call should be moved.  I think that the correct code is:

...
b = (byte) in.read();
if (b == 13) {
//We're done, but we want to see if \n is next
in.mark(1);   <-- here, not before the prior read
b = (byte) in.read();
if (b != 10) {
in.reset();
}
break;
} ...

I've made no other changes on my end, and will leave a stress test running.
Right now it is running about 1200 messages per minute.

--- Noel


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