[jira] Commented: (AMQ-826) LDAP based authorization support

2006-08-25 Thread Nikola Goran Cutura (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36848 ] 

Nikola Goran Cutura commented on AMQ-826:
-

I've been working on ApacheDS integration and found some issues there. Those 
are planned to be fixed in RC4 which is coming in a week (1.9.2006.).

 LDAP based authorization support
 

 Key: AMQ-826
 URL: https://issues.apache.org/activemq/browse/AMQ-826
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: james strachan
 Assigned To: Nikola Goran Cutura
 Attachments: LdapAuth.zip


 Patch kindly added by ngcutura - discussion thread...
 http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-826) LDAP based authorization support

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36849 ] 

james strachan commented on AMQ-826:


Great - thanks for the heads up. Good luck :)

 LDAP based authorization support
 

 Key: AMQ-826
 URL: https://issues.apache.org/activemq/browse/AMQ-826
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: james strachan
 Assigned To: Nikola Goran Cutura
 Attachments: LdapAuth.zip


 Patch kindly added by ngcutura - discussion thread...
 http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Resolved: (AMQ-884) Ajax should support non-XML messages

2006-08-25 Thread Greg Wilkins (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-884?page=all ]

Greg Wilkins resolved AMQ-884.
--

Resolution: Fixed

Applied patch and tested against chat demo.
Also updated to jetty 6.0.0rc2


 Ajax should support non-XML messages
 

 Key: AMQ-884
 URL: https://issues.apache.org/activemq/browse/AMQ-884
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Danilo Tuler
 Assigned To: Greg Wilkins
 Attachments: _amq.js.patch


 _amq.js should not make an assumption that the received message is in XML 
 format.
 I'm using a plain text message and it was not being handled to my handler.
 The user handler must be aware of the type of object it receives.
 Patch below.
 Index: _amq.js
 ===
 --- _amq.js   (revision 419888)
 +++ _amq.js   (working copy)
 @@ -46,11 +46,7 @@
  {
for (var j = 0; j  responseElement.childNodes.length; j++)
{
 -var child = responseElement.childNodes[j]
 -if (child.nodeType == 1)
 -{
 -  handler(child);
 -}
 +handler(responseElement.childNodes[j]);
 }
  }
}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Patch submission process and turn around time

2006-08-25 Thread Sepand M

Hi,

I'm almost done coding for the SSL transport support project (refer to
the Creating a secure connection system and using JMSXUserID support
thread).

I was just wondering how I would submit the patch for approval, how
long approval would take, when the code might make it into a release,
etc.

I ask this because my company needs to use this code fairly soon and I
need to figure out if we should wait for your release (if you accept
my code) or try to get my stuff in independant of activemq.

Regards,
Sepand


Re: Patch submission process and turn around time

2006-08-25 Thread James Strachan

On 8/25/06, Sepand M [EMAIL PROTECTED] wrote:

Hi,

I'm almost done coding for the SSL transport support project (refer to
the Creating a secure connection system and using JMSXUserID support
thread).


Great


I was just wondering how I would submit the patch for approval, how
long approval would take, when the code might make it into a release,
etc.


Here's details
http://incubator.apache.org/activemq/contributing.html



I ask this because my company needs to use this code fairly soon and I
need to figure out if we should wait for your release (if you accept
my code) or try to get my stuff in independant of activemq.


We can't give any particular dates for releases - you might want to
use a local build until the release goes out
--

James
---
http://radio.weblogs.com/0112098/


[jira] Created: (SM-556) CIMERO Eclipse plugin

2006-08-25 Thread jerome camilleri (JIRA)
CIMERO Eclipse plugin
-

 Key: SM-556
 URL: https://issues.apache.org/activemq/browse/SM-556
 Project: ServiceMix
  Issue Type: New Feature
  Components: tooling
Affects Versions: 3.0-M2
Reporter: jerome camilleri
 Fix For: 3.0-M2
 Attachments: cimero.zip

This Eclipse plugin permits to create graphically a configuration of a 
ServiceMix flow.
The created graph can build an XML configuration file to ServiceMix or a JBI 
package.

See http://goopen.org/confluence/display/SM/CIMERO+Editor for more details


Bull RD

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SM-556) CIMERO Eclipse plugin

2006-08-25 Thread Guillaume Nodet (JIRA)
[ 
https://issues.apache.org/activemq/browse/SM-556?page=comments#action_36850 ] 

Guillaume Nodet commented on SM-556:


Thx,

Note that the file headers will have to change to comply with the new ASF 
policy:
   http://www.apache.org/legal/src-headers.html#headers

Still waiting for the legal stuff to be sorted

 CIMERO Eclipse plugin
 -

 Key: SM-556
 URL: https://issues.apache.org/activemq/browse/SM-556
 Project: ServiceMix
  Issue Type: New Feature
  Components: tooling
Affects Versions: 3.0-M2
Reporter: jerome camilleri
 Fix For: 3.0-M2

 Attachments: cimero.zip


 This Eclipse plugin permits to create graphically a configuration of a 
 ServiceMix flow.
 The created graph can build an XML configuration file to ServiceMix or a JBI 
 package.
 See http://goopen.org/confluence/display/SM/CIMERO+Editor for more details
 Bull RD

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Coding style, specifically 80 characters

2006-08-25 Thread James Strachan

+1 for 120 characters :)

And Sun coding standards for the rest.

On 8/25/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

I try to keep the meat of the statement to the first 80 characters
and if some string goes out to say 200 characters, I don't really
care.  I just don't want to be surprised by some important thing off
the screen.

-dain

On Aug 24, 2006, at 2:50 PM, Brian McCallister wrote:

 I generally do 120 as well :-)

 -Brian

 On Aug 24, 2006, at 2:20 PM, Guillaume Nodet wrote:

 Agreed.
 120 is much more useful :)

 On 8/24/06, Jason Dillon [EMAIL PROTECTED] wrote:

 I think the 80 char limit is antiquated... now that most folks have
 displays that can quite easily display more than 80 columns.
 Limiting lines to 80 tends to force folks to artificially reformat
 code which just uglies things up.

 --jason


 On Aug 24, 2006, at 1:56 PM, Sepand M wrote:

  Hi guys,
 
  Do you have a coding style that I should go by?
  Specifically, do you use the 80 chars/line limit?
  I see a lot of code that doesn't, so I haven't, but it's
 bugging me
  more and more by the second.
 
  Regards,
  Sepand




 --
 Cheers,
 Guillaume Nodet





--

James
---
http://radio.weblogs.com/0112098/


Re: Where to put new Callback and CallbackHandler classes

2006-08-25 Thread James Strachan

On 8/24/06, Sepand M [EMAIL PROTECTED] wrote:

Hi,

For certificate authentication, I'm adding two classes:
JaasCertificateCallbackHandler and CertificateCallback.
I've placed these classes in activemq-core along with
JaasCredentialCallback, etc. The problem is that activemq-jaas needs
access to these classes (since I have a new LoginModule that uses
them) and maven complains that we can't have a circular dependency
between activemq-core and activemq-jaas.
So, should I move these classes into activemq-jass? Should I move all
Callback classes to activemq-jaas? Any other way of doing this?


I'd put them in the module which uses them, so activemq-jaas sounds
about right. Does activemq-core need to access them?
--

James
---
http://radio.weblogs.com/0112098/


Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon

I have never seen this error.

What version of Maven are you using?  What version of Java?  Did you  
compile any Maven plugins locally?  Anything else that could be odd  
about your environment?


--jason


On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote:



Is there any new news on this (or a work around)?  It seems that  
Sergey had success with the 1.4.3 version of the jspc plugin.   
However, when I tried that I just get a different error (see below  
[1] ). The demo target includes just a web-fragment.xml file rather  
that a jsp-source directory.


BDudney then recommended I try with the jsp compilation removed  
from demo.  I gave that a shot this evening and got the next error  
([2] below).  I only removed the reference to the jspc-maven-plugin  
in the demo pom ... perhaps I needed to change something else?


Seems like using 1.4.3 is causing more problems than it's fixing  
for me.  Any other ideas?


Joe


[1]
[INFO]  
-- 
--

[INFO] Building Geronimo Applications :: Demo
[INFO]task-segment: [clean, install]
[INFO]  
-- 
--

[INFO] [clean:clean]
[INFO] Deleting directory C:\g\applications\demo\target
[INFO] Deleting directory C:\g\applications\demo\target\classes
[INFO] Deleting directory C:\g\applications\demo\target\test-classes
[INFO] [tools:require-java-version {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO]  
-- 
--

[ERROR] BUILD ERROR
[INFO]  
-- 
--

[INFO] Error

Embedded error: basedir C:\g\applications\demo\target\jsp-source is  
not a directory
[INFO]  
-- 
--

[INFO] For more information, run Maven with the -e switch
[INFO]  
-- 
--

[INFO] Total time: 6 minutes 25 seconds
[INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO]  
-- 
--





[2]
[INFO]  
-- 
--

[INFO] Building Geronimo Applications :: Demo
[INFO]task-segment: [install]
[INFO]  
-- 
--

[INFO] [tools:require-java-version {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Copy webapp webResources to C:\g\applications\demo\target 
\demo-1.2-SNAPSHOT
[INFO]  
-- 
--

[ERROR] BUILD FAILURE
[INFO]  
-- 
--
[INFO] The specified web.xml file 'C:\g\applications\demo\target 
\jspweb.xml' does not exist
[INFO]  
-- 
--

[INFO] For more information, run Maven with the -e switch
[INFO]  
-- 
--

[INFO] Total time: 53 seconds
[INFO] Finished at: Thu Aug 24 23:53:18 EDT 2006
[INFO] Final Memory: 23M/46M
[INFO]  
-- 
--




Jeff Genender wrote:

Ok...let me have a crack at it and try to fix the plugin.
Jeff
Rick McGuire wrote:

It still fails with 1.4.5-SNAPSHOT (at least on Linux).

Rick

Jeff Genender wrote:

Try upgrading the jspc maven plugin to 1.4.5-SNAPSHOT and let me  
know if

that fixes the problem.

Rick McGuire wrote:

I'm getting a strange build error on the latest trunk this  
morning.  For
some reason, building the JSPs in the applications can no  
longer locate
the javac compiler.  At first, I thought I had some set up  
problem on my
Windows system, but when I moved over to my Linux box, I got  
the same
error.  This occurs both on my working build and fresh builds  
on both

platforms.

[INFO]
-- 
--

[ERROR] BUILD ERROR
[INFO]
-- 
--

[INFO] Error

Embedded error: Unable to compile class for JSP

Generated servlet error:
Aug 24, 2006 7:38:42 AM org.apache.jasper.compiler.AntCompiler
generateClass
SEVERE: Javac exception
Unable to find a javac 

Re: Strange build error on trunk

2006-08-25 Thread Sergey Elin
In my case it's:[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(1)$ mvn -vMaven version: 2.0.4[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ java -version
java version 1.4.2-p7Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-p7-_17_may_2006_11_07)Java HotSpot(TM) Client VM (build 1.4.2-p7-_17_may_2006_11_07, mixed mode)[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ uname -sr
OpenBSD 4.0I just got sources from svn and try to build it according BUILDING.txtFirst try was 08/23/06 and it was successSecond - yesterday (after switching subversion and update) and it finished with this error.
2006/8/25, Jason Dillon [EMAIL PROTECTED]:
I have never seen this error.What version of Maven are you using?What version of Java?Did youcompile any Maven plugins locally?Anything else that could be oddabout your environment?--jason
On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote: Is there any new news on this (or a work around)?It seems that Sergey had success with the 1.4.3 version of the jspc plugin. However, when I tried that I just get a different error (see below
 [1] ). The demo target includes just a web-fragment.xml file rather that a jsp-source directory. BDudney then recommended I try with the jsp compilation removed from demo.I gave that a shot this evening and got the next error
 ([2] below).I only removed the reference to the jspc-maven-plugin in the demo pom ... perhaps I needed to change something else? Seems like using 1.4.3 is causing more problems than it's fixing
 for me.Any other ideas? Joe [1] [INFO] -- -- [INFO] Building Geronimo Applications :: Demo
 [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] [clean:clean] [INFO] Deleting directory C:\g\applications\demo\target
 [INFO] Deleting directory C:\g\applications\demo\target\classes [INFO] Deleting directory C:\g\applications\demo\target\test-classes [INFO] [tools:require-java-version {execution: default}] [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [jspc:compile {execution: jspc}] [INFO] Compiling new java files...
 [INFO] -- -- [ERROR] BUILD ERROR [INFO] --
 -- [INFO] Error Embedded error: basedir C:\g\applications\demo\target\jsp-source is not a directory [INFO] --
 -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 6 minutes 25 seconds
 [INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- --
 [2] [INFO] -- -- [INFO] Building Geronimo Applications :: Demo [INFO]task-segment: [install]
 [INFO] -- -- [INFO] [tools:require-java-version {execution: default}] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile
 [INFO] [surefire:test] [INFO] No tests to run. [INFO] [war:war] [INFO] Exploding webapp... [INFO] Copy webapp webResources to C:\g\applications\demo\target \demo-1.2-SNAPSHOT
 [INFO] -- -- [ERROR] BUILD FAILURE [INFO] --
 -- [INFO] The specified web.xml file 'C:\g\applications\demo\target \jspweb.xml' does not exist [INFO] -- --
 [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 53 seconds [INFO] Finished at: Thu Aug 24 23:53:18 EDT 2006
 [INFO] Final Memory: 23M/46M [INFO] -- -- Jeff Genender wrote: Ok...let me have a crack at it and try to fix the plugin.
 Jeff Rick McGuire wrote: It still fails with 1.4.5-SNAPSHOT (at least on Linux). Rick Jeff Genender wrote:
 Try upgrading the jspc maven plugin to 1.4.5-SNAPSHOT and let me know if that fixes the problem. Rick McGuire wrote:
 I'm getting a strange build error on the latest trunk this morning.For some reason, building the 

Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment):    /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar--jasonOn Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:[INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz/.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/ home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geronimo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError : org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute (JspC.java:1135)    at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:180)    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java :306)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :140)    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)    at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke(Method.java:324)    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)    at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  [EMAIL PROTECTED]:Is there any new news on this (or a work around)?  It seems that Sergey had success with the 1.4.3 version of the jspc plugin.  However, when Itried that I just get a different error (see below [1] ). The demotarget includes just a web-fragment.xml file rather that a jsp-source directory.BDudney then recommended I try with the jsp compilation removed fromdemo.  I gave that a shot this evening and got the next error ([2]below).  I only removed the reference to the jspc-maven-plugin in the demo pom ... perhaps I needed to change something else?Seems like using 1.4.3 is causing more problems than it's fixing for me.  Any other ideas?Joe[1][INFO] [INFO] Building Geronimo Applications :: Demo[INFO]task-segment: [clean, 

Re: Strange build error on trunk

2006-08-25 Thread Sergey Elin
Yes2006/8/25, Jason Dillon [EMAIL PROTECTED]:
Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment): /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-
compiler-jdt-5.5.15.jar--jason
On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:[INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: 
[EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz
/.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/ home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com
piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni
mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError : org/eclipse/jdt/internal/compiler/env/INameEnvironment at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler
(JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute (JspC.java:1135) at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(
AbstractJspcMojo.java:180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java
:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java :306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke
(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode
(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou 
rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment at 
java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  
[EMAIL PROTECTED]:
Is there any new news on this (or a work around)?It seems that Sergey had success with the 1.4.3 version of the jspc plugin.However, when Itried that I just get a different error (see below [1] ). The demo
target includes just a web-fragment.xml file rather that a jsp-source directory.BDudney then recommended I try with the jsp compilation removed fromdemo.I gave that a shot this evening and got the next error ([2]
below).I only removed the reference to the jspc-maven-plugin in the demo pom ... perhaps I needed to change something else?Seems like using 1.4.3 is causing more problems than it's fixing for me.Any other ideas?
Joe[1][INFO] [INFO] Building Geronimo Applications :: Demo[INFO]task-segment: [clean, install][INFO]
[INFO] [clean:clean][INFO] Deleting directory C:\g\applications\demo\target 

Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
Can you check to see what is in jasper-compiler-jdt-5.5.15.jar?Also, not that I think it matters, but you might try to svn co server/trunk.Let me know, I would like to understand why this failure just started... and more so why only some folks see it,--jasonOn Aug 25, 2006, at 12:26 AM, Sergey Elin wrote:In my case it's:[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(1)$ mvn -vMaven version: 2.0.4[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ java -version java version "1.4.2-p7"Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-p7-_17_may_2006_11_07)Java HotSpot(TM) Client VM (build 1.4.2-p7-_17_may_2006_11_07, mixed mode)[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ uname -sr OpenBSD 4.0I just got sources from svn and try to build it according BUILDING.txtFirst try was 08/23/06 and it was successSecond - yesterday (after switching subversion and update) and it finished with this error. 2006/8/25, Jason Dillon [EMAIL PROTECTED]: I have never seen this error.What version of Maven are you using?  What version of Java?  Did youcompile any Maven plugins locally?  Anything else that could be oddabout your environment?--jason On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote: Is there any new news on this (or a work around)?  It seems that Sergey had success with the 1.4.3 version of the jspc plugin. However, when I tried that I just get a different error (see below  [1] ). The demo target includes just a web-fragment.xml file rather that a jsp-source directory. BDudney then recommended I try with the jsp compilation removed from demo.  I gave that a shot this evening and got the next error  ([2] below).  I only removed the reference to the jspc-maven-plugin in the demo pom ... perhaps I needed to change something else? Seems like using 1.4.3 is causing more problems than it's fixing  for me.  Any other ideas? Joe [1] [INFO] -- -- [INFO] Building Geronimo Applications :: Demo  [INFO]task-segment: [clean, install] [INFO] -- -- [INFO] [clean:clean] [INFO] Deleting directory C:\g\applications\demo\target  [INFO] Deleting directory C:\g\applications\demo\target\classes [INFO] Deleting directory C:\g\applications\demo\target\test-classes [INFO] [tools:require-java-version {execution: default}] [INFO] [resources:resources]  [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [jspc:compile {execution: jspc}] [INFO] Compiling new java files...  [INFO] -- -- [ERROR] BUILD ERROR [INFO] --  -- [INFO] Error Embedded error: basedir C:\g\applications\demo\target\jsp-source is not a directory [INFO] --  -- [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 6 minutes 25 seconds  [INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006 [INFO] Final Memory: 43M/63M [INFO] -- --  [2] [INFO] -- -- [INFO] Building Geronimo Applications :: Demo [INFO]task-segment: [install]  [INFO] -- -- [INFO] [tools:require-java-version {execution: default}] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources.  [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] No sources to compile  [INFO] [surefire:test] [INFO] No tests to run. [INFO] [war:war] [INFO] Exploding webapp... [INFO] Copy webapp webResources to C:\g\applications\demo\target \demo-1.2-SNAPSHOT  [INFO] -- -- [ERROR] BUILD FAILURE [INFO] --  -- [INFO] The specified web.xml file 'C:\g\applications\demo\target \jspweb.xml' does not exist [INFO] -- --  [INFO] For more information, run Maven with the -e switch [INFO] -- -- [INFO] Total time: 53 seconds [INFO] Finished at: Thu Aug 24 23:53:18 EDT 2006  [INFO] Final Memory: 23M/46M [INFO] -- -- Jeff Genender wrote: Ok...let me have a crack at it and try to fix the 

Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jasonOn Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:Yes2006/8/25, Jason Dillon [EMAIL PROTECTED]: Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment):    /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar--jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:[INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/ home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError : org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)     at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute (JspC.java:1135)    at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180)    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java :306)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :140)    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)    at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke (Method.java:324)    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)    at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)    at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  [EMAIL PROTECTED]: Is there any new news on this (or a work around)?  It seems that Sergey had success with the 1.4.3 version of the jspc plugin.  However, when Itried that I just get a different error (see below [1] ). The demo target includes just a web-fragment.xml file rather that a jsp-source directory.BDudney then recommended I try with the jsp compilation removed fromdemo.  I gave that a shot this evening and got the next error ([2] below).  I only removed the reference to the jspc-maven-plugin in the demo pom ... perhaps I needed to change something else?Seems like using 1.4.3 is causing more 

Re: [ANNOUNCE] Welcome David Blevins as the newest member of the Geronimo PMC

2006-08-25 Thread Chris Cardona
Congrats David !!

chris

--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 Please welcome David Blevins as the newest member of
 the Geronimo PMC.  David recently accepted the 
 invitation to join the PMC.  David is part of the
 OpenEJB project that we depend on so heavily and 
 that is joining Apache as an Incubator project. 
 David is also a great mentor and community builder.
 
 Give it up for David :-0
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


[jira] Resolved: (SM-439) servicemix-beanflow - Workflow.joinAll failure to register onStop callback if first Activity stops during start handler

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/SM-439?page=all ]

james strachan resolved SM-439.
---

Resolution: Fixed

OK I think I've fixed it for good this time :)

This test case managed to bring to light a few timing issues in the code. 
Basically the Workflow class was a little too complex for its own good so I've 
simplified that a bit. Also there was a chance that in JoinSupport things could 
get started twice which is now fixed. Finally the one that really took me a 
while to figure out was that sometimes activities stop before they have 
completely finished starting; so the AbstractActivity start() method now only 
sets the status to Start if it is Starting (to avoid overwriting the 
Stopped/Failed status)

 servicemix-beanflow - Workflow.joinAll failure to register onStop callback if 
 first Activity stops during start handler
 ---

 Key: SM-439
 URL: https://issues.apache.org/activemq/browse/SM-439
 Project: ServiceMix
  Issue Type: Bug
  Components: beanflow
Affects Versions: incubation
 Environment: osx, jdk 1.5
Reporter: Jason Anderson
 Assigned To: james strachan
 Fix For: 3.0-M3


 if the following code is run the JoinFlow.stop state will never be thrown 
 because the internal JoinAll state is set to stopped after forking the first 
 activity in the JoinSupport(Activity ...) constructor before the onStop 
 callback is registered in WorkFlow.join
 public class JoinTest extends TestCase {
 public static class JoinFlow extends WorkflowJoinFlow.Step {
 public static enum Step {
 first, stop
 }
 public JoinFlow() {
 super(Step.first);
 }
 public void first() {
 final Activity a = new TimeoutActivity() {
 protected void onValidStateChange() {
 System.out.println(in a);
 stop();
 }
 };
 final Activity b = new TimeoutActivity() {
 protected void onValidStateChange() {
 System.out.println(in b);
 stop();
 }
 };
 System.out.println(in first);
 joinAll(Step.stop, 1, a, b);
 System.out.println(after join);
 }
 }
 public void testJoin() throws Exception {
 JoinFlow flow = new JoinFlow();
 flow.start();
 flow.join();
 }
 }
 I believe if the JoinSupport were to add all the activities to the children 
 list before forking them it would prevent the JoinAll.onChildStateChange from 
 being called prematurely with childCount=1, stoppedCount=1 when there should 
 be 2 children but I cannot currently get the maven build to run to test this 
 thoery

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Sergey Elin
It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in maven 2: required dependency to jasper-compiler-jdt is missing.I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom
 and successfully build geronimo-jsp-examples.2006/8/25, Jason Dillon [EMAIL PROTECTED]:
Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jason
On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:Yes2006/8/25, Jason Dillon 
[EMAIL PROTECTED]: Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment):
 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar
--jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:
[INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ 
target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/
 home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0
 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError
 : org/eclipse/jdt/internal/compiler/env/INameEnvironment at java.lang.Class.forName0(Native Method)  at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute
 (JspC.java:1135) at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java
:475)  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java
 :306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
 :140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java
:256)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch
 (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou 
rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment at 
java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  
[EMAIL PROTECTED]:
 Is there any new news on this (or a work around)?It seems that Sergey had success with the 1.4.3 version of the jspc plugin.However, when Itried that I just get a different error (see below [1] ). The demo 
target includes just a web-fragment.xml file rather that a jsp-source directory.BDudney then recommended I try with the jsp compilation removed fromdemo.I gave that a shot this evening and got the next error ([2] 
below).I only removed the reference to the jspc-maven-plugin in the demo pom ... 

Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC

2006-08-25 Thread Chris Cardona
Congrats Alan!

chris

--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 The Apache Geronimo PMC would like to let everyone
 know that Alan Cabrera has accepted the 
 invitation to join the Geronimo PMC.  We are excited
 to have Alan assisting with project oversight 
 in addition to his technical contributions to
 Geronimo.
 
 Alan has been active in Geronimo for many years and
 has helped not only to help in Geronimo directly 
 but in related efforts like Ode, Yoko and others.
 
 Give it up for Alan :)
 
 The Apache Geronimo PMC
 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: Geronimo site POC using Confluence Autoexport

2006-08-25 Thread Jason Dillon
Okay, I think that the sync that Jeff has setup will allow me to move  
further on setting up the proof of concept, taking GMOxSITE and  
GMOxKB and making them into something suitable to be used for http:// 
geronimo.apache.org


--jason


On Aug 24, 2006, at 3:02 PM, David Blevins wrote:



On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
Sounds like Jeff Turner may be willing to help us solve this  
problem... pending more details.


Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I  
open sources a stream editing library with the intention of  
confluence munging, just Peir beat me to it :)  But doing things  
like munging urls is a piece of cake:


http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/ 
test/java/org/codehaus/swizzle/stream/ 
ResolveUrlInputStreamTest.java?r=23


I could crank something out in short order if you give me an idea  
of what things need to be updated.


-David


--jason


On Aug 23, 2006, at 10:17 PM, David Blevins wrote:

Assuming you did have access to the box, what steps would be  
required to get things setup?  I know I'm asking an unnatural  
question as I typically start my thinking while staring at the  
command prompt and type commands iteratively till things work.   
But I'm just thinking if we could maybe figure that out, we could  
work with someone who does have access.


I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
seeing it solved.


-David

On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:

So, it looks like there is going to need some convincing to get  
access to the exported content, so that we can post process and  
massage these spaces into our main website.


I'm not even sure that it is going to be worth the effort to try  
and convince Apache infra that we need the access.  Seems like  
they are only willing to give accounts on systems to Apache  
members.


So, I wonder if we could just run our own Confluence instance on  
our zone, only use it to author, then export the content,  
massage and then svn ci.  I guess we could also do the same by  
moving the spaces to goopen.org too, which will provide us the  
required access to implement the site that we all want to  
implement.


I'm frustrated... we now have a Confluence instance on ASF, but  
we can't really use it to produce the results we want... unless  
you want to see http://geronimo.apache.org become a set of  
http://cwiki.apache.org* URs... which I find very distasteful.


There might be some way to configure httpd to rewrite urls so  
that http://cwiki.apache.org/GMOxSITE looks like http:// 
geronimo.apache.org and that http://cwiki.apache.org/GMOxKB  
looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder  
if that is really worth all of the effort.


I guess we could use wget to grab the entire http:// 
cwiki.apache.org/GMOxSITE and then massage and check in... but  
that is terribly inefficient and add more unwanted time lapse  
between updating content to making the content live.


So, in short... I can't do anything related to making GMOxSITE  
the official website until there is a way to get access to the  
exported content, or get the httpd configuration changed for our  
vhost.


I feel like we have a spiffy new Ferrari that we can only drive  
at 5 mph... and as soon as you hit 6 mph it starts to hit you on  
the head.


:-(

--jason











Re: Declarative Exception Handling in ServiceMix

2006-08-25 Thread Guillaume Nodet

I guess that if you want to handle exceptions in a JBI compliant way,
you should put in the flow some specific components to do that.

First, we need to make a distinction between faults and errors.
Imho, faults are unrecoverable problems, due to the message itself.
Errors are runtime problems, which may be able to be solved at
a later time.

In your example, depending on the reason why the data could not be
stored in the database, the component should return a fault
(if the data is corrupted) or an error (the database is down).

In your use case, the error should be catched by a simple component
(an EIP pattern) between the http component and  the business
component which would act as a normal proxy when no errors are
reported, and redirect the flow elsewhere when an error occurs.

Also, I don't really understand the friendly error concept ;)
The http component is not designed to be a jsp server, so you
won't have any nice interface there.  The output should be an xml.
If you want a nice interface, you should deploy a web app which
would call the jbi bus and return a nice html page when an error
occurs.

Last, while I think declarative transactions may be really useful
for POJO based components (servicemix-jsr181, or the yet to be
defined new component, see other threads on the list),
it would be difficult to apply it in a real JBI world.

Let's discuss it, it' s just my thoughts.

On 8/25/06, jpuro [EMAIL PROTECTED] wrote:



I think it would be useful to add declarative exception handling to
ServiceMix.  The usefullness of such a feature can be seen from the
following simple use case involving a client submitting an order to a
fulfillment company:

1)  The use case starts when the client sends an order to an HTTP endpoint
exposed in ServiceMix.  The message representing the order is routed to a
business service component.

2)  The business service component attempts to process the Order and save
it
to a database.  However, an exception occurs during this process and gets
bubbled up.  The fulfillment company would like to be notified via email
when an order fails to be processed.  Since we have configured the
business
service component to pass all exceptions to an email component, the flow
moves to step 3.

3)  The email component sends out an email notification to the fulfillment
company indicating that an error occurred while processing the order.

4)  After the email has been sent out, the flow moves to another component
that returns a more user friendly error message to the original HTTP
endpoint.  This way we do not send back a hard to read error message to
the
client.

The purpose of such a flow is that we handle exceptions more gracefully
than
currently is supported by ServiceMix.  Instead of bubbling up exceptions
to
the calling component, we should allow components to change the flow of a
message when an exception occurs.

The configuration could look something like the following:

activationSpec componentName=businessServiceComponent
service=example:businessService


exceptionDestionationService=example:emailService
sm:component
bean class=com.mycompany.MyClass
/
/sm:component
/activationSpec

Alternatively, perhaps we can just use AOP to catch exceptions that occur
within a component:

sm:exceptionHandler
exceptionType=javax.jbi.messaging.MessagingException
destinationService=example:emailService

activationSpec componentName=businessServiceComponent
service=example:businessService
sm:component
bean class=
com.mycompany.MyClass/
/sm:component
/activationSpec

/sm:exceptionHandler


Here are a few concerns of mine:

1)  The problem with the first example configuration is that it doesn't
allow you to get creative with how certain types of exceptions are
handled,
it just acts like a catch all.  We may need to create a more flexible way
of
configuring exception handling.

2)  Because of the way JBI service units/assemblies are packaged and
deployed, would this work?  Is there any discussion on declaratively
handling exceptions in the JBI spec?

Regards,

Jeff
--
View this message in context:
http://www.nabble.com/Declarative-Exception-Handling-in-ServiceMix-tf2161788.html#a5974450
Sent from the ServiceMix - Dev forum at Nabble.com.





--
Cheers,
Guillaume Nodet


Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
This still all builds fine for me w/o any modifications to the jspc plugin.Something else going on...--jasonOn Aug 25, 2006, at 1:00 AM, Sergey Elin wrote:It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in maven 2: required dependency to jasper-compiler-jdt is missing.I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and successfully build geronimo-jsp-examples.2006/8/25, Jason Dillon [EMAIL PROTECTED]: Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jason On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:Yes2006/8/25, Jason Dillon  [EMAIL PROTECTED]: Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment):     /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar --jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info: [INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/ home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError : org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)     at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute (JspC.java:1135)    at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180)    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java :475)     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java :306)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :140)    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)    at org.apache.maven.cli.MavenCli.main(MavenCli.java :256)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke (Method.java:324)    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)    at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)    at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  [EMAIL PROTECTED]: Is there any new news on this (or a work around)?  It seems that Sergey had success with the 1.4.3 version of the jspc plugin.  However, when 

Re: Strange build error on trunk

2006-08-25 Thread Sergey Elin
Hmm..Can you show your mirrors section from maven's settings.xml?2006/8/25, Jason Dillon [EMAIL PROTECTED]:
This still all builds fine for me w/o any modifications to the jspc plugin.Something else going on...--jason
On Aug 25, 2006, at 1:00 AM, Sergey Elin wrote:It seems there is the wrong configuration for jspc-maven-plugin 
1.4.4 in maven 2: required dependency to jasper-compiler-jdt is missing.I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom  and successfully build geronimo-jsp-examples.
2006/8/25, Jason Dillon [EMAIL PROTECTED]:
 Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jason On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:
Yes2006/8/25, Jason Dillon  [EMAIL PROTECTED]
: Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment): 
 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar
 --jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:
 [INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ 
target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/
 home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0
 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError
 : org/eclipse/jdt/internal/compiler/env/INameEnvironment at java.lang.Class.forName0(Native Method)  at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute
 (JspC.java:1135) at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java
 :475)  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java
 :306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
 :140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java
 :256)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch
 (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou 
rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment at 
java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute(JspC.java:1135)2006/8/25, Joe Bohn  
[EMAIL PROTECTED]:
 Is there any new news on this (or a work around)?It seems that Sergey had success with the 1.4.3 version of the jspc plugin.However, when Itried that I just get a different error (see below [1] ). The demo 
target includes just a 

Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
mirrors        mirror            idrepo.mergere.com/id            urlhttp://repo.mergere.com/maven2/url            mirrorOfcentral/mirrorOf        /mirror    /mirrors--jasonOn Aug 25, 2006, at 2:08 AM, Sergey Elin wrote:Hmm..Can you show your mirrors section from maven's settings.xml?2006/8/25, Jason Dillon [EMAIL PROTECTED]: This still all builds fine for me w/o any modifications to the jspc plugin.Something else going on...--jason On Aug 25, 2006, at 1:00 AM, Sergey Elin wrote:It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in maven 2: required dependency to jasper-compiler-jdt is missing.I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and successfully build geronimo-jsp-examples. 2006/8/25, Jason Dillon [EMAIL PROTECTED]: Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jason On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote: Yes2006/8/25, Jason Dillon  [EMAIL PROTECTED] : Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment):     /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar --jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info:  [INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/ home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError : org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)     at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213)    at org.apache.jasper.JspC.processFile(JspC.java:979)    at org.apache.jasper.JspC.execute (JspC.java:1135)    at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180)    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java :475)     at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java :306)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273)    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java :140)    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)     at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)    at org.apache.maven.cli.MavenCli.main(MavenCli.java :256)     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)    at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)    at java.lang.reflect.Method.invoke (Method.java:324)    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)    at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)    at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430)    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment    at java.lang.Class.forName0(Native Method)    at java.lang.Class.forName(Class.java:141)    at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233)    at org.apache.jasper.JspCompilationContext.createCompiler 

scout 0.5 jar still has bunk log4j.properties

2006-08-25 Thread Jason Dillon
Do we have any friends at the ws project that can re-release scout  
0.5 without a log4j.properties file?


Or else... I think we need to add some magic to the build to  
download, strip that file and then re-install the dependency to  
remove the bunk log4j.properties file.


--jason


[jira] Commented: (AMQ-878) JMX Exception: Destination already created when recovering gigantic queues from database

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-878?page=comments#action_36842 ] 

james strachan commented on AMQ-878:


FWIW the issue with 2 destinations being created due to concurrency issues 
should now be fixed. Not sure yet if we still need asynchronous recovery - but 
the original issue should be resolved

 JMX Exception: Destination already created when recovering gigantic queues 
 from database
 --

 Key: AMQ-878
 URL: https://issues.apache.org/activemq/browse/AMQ-878
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: incubation
 Environment: Embeded broker, Any platform (OS, JDK) - currentlly 
 embeded in JBoss 4.0.4.GA
Reporter: Nikolai Penkov
 Assigned To: Hiram Chirino
 Attachments: async-recovery.patch


 I think this issue is described in Hiram's blog: 
 http://blogbucket.blogspot.com/2006/05/scaling-to-gigantic-queues-and-topics.html.
 E.g. when broker is stopped with a lot of messages in queue. When started - 
 recovery process is fired (currently on creation of a queue), and if another 
 subscriber requests queue - it creates a new one, because previous process 
 hasn't finished.
 I think the simpliest solution for that problem is to start recovery process 
 in another thread with synchronization to sent process(sent process should be 
 suspended till full recovery is done) and subscriber notification method 
 (every sunscriber should be notified on recovery of message).
 I have attached a patch to activemq-core, which I have tested with my 
 environment - JBoss 4.0.4.GA with Embeded Broker ActiveMQ trunk release, jdbc 
 persistence.
 I am not a spec. in threads nor in ActiveMQ design, and I am sure that you 
 will find a more elegant sollution to what I have provided.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn

For me it's

Maven version: 2.0.4

java version 1.4.2_08
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)

I didn't compile any maven plugins locally.

Anything else?  I'm running on windows XP and most folks I know with 
this problem are also on windows.  However, as with Sergey, there are a 
few folks seeing it on *nix.


Joe


Sergey Elin wrote:

In my case it's:
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(1)$ 
mvn -v

Maven version: 2.0.4
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
java -version

java version 1.4.2-p7
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2-p7-_17_may_2006_11_07)

Java HotSpot(TM) Client VM (build 1.4.2-p7-_17_may_2006_11_07, mixed mode)
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
uname -sr

OpenBSD 4.0

I just got sources from svn and try to build it according BUILDING.txt
First try was 08/23/06 and it was success
Second - yesterday (after switching subversion and update) and it 
finished with this error.



2006/8/25, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

I have never seen this error.

What version of Maven are you using?  What version of Java?  Did you
compile any Maven plugins locally?  Anything else that could be odd
about your environment?

--jason


On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote:

 
  Is there any new news on this (or a work around)?  It seems that
  Sergey had success with the 1.4.3 version of the jspc plugin.
  However, when I tried that I just get a different error (see below
  [1] ). The demo target includes just a web-fragment.xml file rather
  that a jsp-source directory.
 
  BDudney then recommended I try with the jsp compilation removed
  from demo.  I gave that a shot this evening and got the next error
  ([2] below).  I only removed the reference to the jspc-maven-plugin
  in the demo pom ... perhaps I needed to change something else?
 
  Seems like using 1.4.3 is causing more problems than it's fixing
  for me.  Any other ideas?
 
  Joe
 
 
  [1]
  [INFO]
 
--
  --
  [INFO] Building Geronimo Applications :: Demo
  [INFO]task-segment: [clean, install]
  [INFO]
 
--
  --
  [INFO] [clean:clean]
  [INFO] Deleting directory C:\g\applications\demo\target
  [INFO] Deleting directory C:\g\applications\demo\target\classes
  [INFO] Deleting directory C:\g\applications\demo\target\test-classes
  [INFO] [tools:require-java-version {execution: default}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] No sources to compile
  [INFO] [jspc:compile {execution: jspc}]
  [INFO] Compiling new java files...
  [INFO]
 
--
  --
  [ERROR] BUILD ERROR
  [INFO]
 
--
  --
  [INFO] Error
 
  Embedded error: basedir C:\g\applications\demo\target\jsp-source is
  not a directory
  [INFO]
 
--
  --
  [INFO] For more information, run Maven with the -e switch
  [INFO]
 
--
  --
  [INFO] Total time: 6 minutes 25 seconds
  [INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006
  [INFO] Final Memory: 43M/63M
  [INFO]
 
--
  --
 
 
 
 
  [2]
  [INFO]
 
--
  --
  [INFO] Building Geronimo Applications :: Demo
  [INFO]task-segment: [install]
  [INFO]
 
--
  --
  [INFO] [tools:require-java-version {execution: default}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] No sources to compile
  [INFO] [resources:testResources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:testCompile]
  [INFO] No sources to compile
  [INFO] [surefire:test]
  [INFO] No tests to run.
  [INFO] [war:war]
  [INFO] Exploding webapp...
  [INFO] Copy webapp webResources to C:\g\applications\demo\target
  

Re: Strange build error on trunk

2006-08-25 Thread Sergey Elin
The same result...2006/8/25, Jason Dillon [EMAIL PROTECTED]:

mirrorsmirror  idrepo.mergere.com
/id  urlhttp://repo.mergere.com/maven2/url  mirrorOfcentral/mirrorOf
/mirror  /mirrors--jason
On Aug 25, 2006, at 2:08 AM, Sergey Elin wrote:Hmm..Can you show your mirrors section from maven's settings.xml?2006/8/25, Jason Dillon 

[EMAIL PROTECTED]: This still all builds fine for me w/o any modifications to the jspc plugin.
Something else going on...--jason On Aug 25, 2006, at 1:00 AM, Sergey Elin wrote:

It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in maven 2: required dependency to jasper-compiler-jdt is missing.I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom  and successfully build geronimo-jsp-examples.
 2006/8/25, Jason Dillon [EMAIL PROTECTED]:

 Can you send me to full `mvn -X` from the applications/geronimo-examples/geronimo-jsp-examples plz.--jason On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote: 
Yes2006/8/25, Jason Dillon  [EMAIL PROTECTED] 
: Does this file actually have that class (org/eclipse/jdt/internal/compiler/env/INameEnvironment): 
 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper- compiler-jdt-5.5.15.jar

 --jason On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:Here is a bit more info: 
 [INFO] [jspc:compile {execution: jspc}][DEBUG] execute() starting for 0 pages.[DEBUG] Parent class loader is: [EMAIL PROTECTED][DEBUG] Compilation classpath initialized: /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/ 
target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/

 home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0

 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni mo-servlet_2.4_spec-1.0.1.jar:[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError

 : org/eclipse/jdt/internal/compiler/env/INameEnvironment at java.lang.Class.forName0(Native Method)  at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler

 (JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at org.apache.jasper.JspC.execute

 (JspC.java:1135) at org.codehaus.mojo.jspc.AbstractJspcMojo.execute( AbstractJspcMojo.java:180) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java :534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java

 :475)  at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java :454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java

 :306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java

 :140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java

 :256)  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke

 (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke (Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch

 (Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375)[DEBUG] Generated /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/jsp-source/jsp/sou 
rce_jsp.java total=1401 generate=125 validate=1238[INFO] Built File: /source.jsp[DEBUG] No Java compiler availablejava.lang.NoClassDefFoundError: org/eclipse/jdt/internal/compiler/env/INameEnvironment
 at 
java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.jasper.JspCompilationContext.createCompiler(JspCompilationContext.java:233) at org.apache.jasper.JspCompilationContext.createCompiler

 (JspCompilationContext.java:213) at org.apache.jasper.JspC.processFile(JspC.java:979) at 

Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn

in-line

Jason Dillon wrote:

Can you check to see what is in jasper-compiler-jdt-5.5.15.jar?
I think this jar looks fine in my repo.It contains the 
INameEnvironment.class.




Also, not that I think it matters, but you might try to svn co server/trunk.
I did a fresh checkout.  Actually, I had to do a fresh checkout because 
the switch command failed for me (on two different windows machines).




Let me know, I would like to understand why this failure just started... 
and more so why only some folks see it,


--jason


On Aug 25, 2006, at 12:26 AM, Sergey Elin wrote:


In my case it's:
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(1)$ 
mvn -v

Maven version: 2.0.4
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
java -version

java version 1.4.2-p7
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2-p7-_17_may_2006_11_07)

Java HotSpot(TM) Client VM (build 1.4.2-p7-_17_may_2006_11_07, mixed mode)
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
uname -sr

OpenBSD 4.0

I just got sources from svn and try to build it according BUILDING.txt
First try was 08/23/06 and it was success
Second - yesterday (after switching subversion and update) and it 
finished with this error.



2006/8/25, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

I have never seen this error.

What version of Maven are you using?  What version of Java?  Did you
compile any Maven plugins locally?  Anything else that could be odd
about your environment?

--jason


On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote:


 Is there any new news on this (or a work around)?  It seems that
 Sergey had success with the 1.4.3 version of the jspc plugin.
 However, when I tried that I just get a different error (see below
 [1] ). The demo target includes just a web-fragment.xml file rather
 that a jsp-source directory.

 BDudney then recommended I try with the jsp compilation removed
 from demo.  I gave that a shot this evening and got the next error
 ([2] below).  I only removed the reference to the jspc-maven-plugin
 in the demo pom ... perhaps I needed to change something else?

 Seems like using 1.4.3 is causing more problems than it's fixing
 for me.  Any other ideas?

 Joe


 [1]
 [INFO]

--
 --
 [INFO] Building Geronimo Applications :: Demo
 [INFO]task-segment: [clean, install]
 [INFO]

--
 --
 [INFO] [clean:clean]
 [INFO] Deleting directory C:\g\applications\demo\target
 [INFO] Deleting directory C:\g\applications\demo\target\classes
 [INFO] Deleting directory C:\g\applications\demo\target\test-classes
 [INFO] [tools:require-java-version {execution: default}]
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] No sources to compile
 [INFO] [jspc:compile {execution: jspc}]
 [INFO] Compiling new java files...
 [INFO]

--
 --
 [ERROR] BUILD ERROR
 [INFO]

--

 --
 [INFO] Error

 Embedded error: basedir C:\g\applications\demo\target\jsp-source is
 not a directory
 [INFO]

--

 --
 [INFO] For more information, run Maven with the -e switch
 [INFO]

--
 --
 [INFO] Total time: 6 minutes 25 seconds
 [INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006
 [INFO] Final Memory: 43M/63M
 [INFO]

--
 --




 [2]
 [INFO]

--
 --
 [INFO] Building Geronimo Applications :: Demo
 [INFO]task-segment: [install]
 [INFO]

--
 --
 [INFO] [tools:require-java-version {execution: default}]
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:compile]
 [INFO] No sources to compile
 [INFO] [resources:testResources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [compiler:testCompile]
 [INFO] No sources to compile
 [INFO] [surefire:test]
 [INFO] No tests to run.
 [INFO] [war:war]
 [INFO] Exploding webapp...
 [INFO] Copy webapp 

[jira] Resolved: (AMQ-515) Add option so that producer.send() throws an exception if it would block due to the queue/broker being full.

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-515?page=all ]

james strachan resolved AMQ-515.


Fix Version/s: 4.1
   (was: 4.2)
   Resolution: Fixed

Patch applied with thanks John.

BTW I made a minor change of the name of the property on usageManager in an 
attempt to make it a bit easier to understand what it did and what setting it 
to true means - so I called it sendFailIfNoSpace


 Add option so that producer.send() throws an exception if it would block due 
 to the queue/broker being full.
 

 Key: AMQ-515
 URL: https://issues.apache.org/activemq/browse/AMQ-515
 Project: ActiveMQ
  Issue Type: New Feature
  Components: JMS client, Broker
Affects Versions: 4.0.2
Reporter: Hiram Chirino
 Assigned To: John Heitmann
 Fix For: 4.1

 Attachments: blockFreeBroker.patch.gz




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (AMQ-895) JMS to JMS Bridge never reconnects under remote broker restarts.

2006-08-25 Thread Manuel Teira (JIRA)
JMS to JMS Bridge never reconnects under remote broker restarts.


 Key: AMQ-895
 URL: https://issues.apache.org/activemq/browse/AMQ-895
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0.1, 4.0 RC2
Reporter: Manuel Teira



I'm using ActiveMQ (4.0.1) JMS to JMS Bridge functionality to connect to a  
SunMQ JMS Broker (3.6 SP3  (Build 02-A)). I'm using two queues, an input and an 
output one, with the following configuration:


jmsBridgeConnectors
  jmsQueueConnector outboundQueueConnectionFactory=#REMOTE
  outboundQueueBridges
outboundQueueBridge outboundQueueName=SUNRECV/
  /outboundQueueBridges
  inboundQueueBridges
inboundQueueBridge inboundQueueName=SUNSEND/
  /inboundQueueBridges
  /jmsQueueConnector
/jmsBridgeConnectors


The system works really well until the SunMQ broker needed to be restarted. 
This is what I found:
1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a while, 
but no log on ActiveMQ indicates knowledge about the new situation.
2.-When I send a message to the output queue SUNRECV, ActiveMQ complains that 
the producer is closed:

[ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to forward 
message: ActiveMQTextMessage {commandId = 5, responseRequired = false, 
messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1, originalDestination = 
null, originalTransactionId = null, producerId = 
ID:trabucco-43457-1156491843149-3:4:1:1, destination = queue://SUNRECV, 
transactionId = null, expiration = 0, timestamp = 1156492032027, arrival = 0, 
correlationId = null, replyTo = null, persistent = false, type = null, priority 
= 0, groupID = null, groupSequence = 0, targetConsumerId = null, compressed = 
false, userID = null, content = null, marshalledProperties = null, 
dataStructure = null, redeliveryCounter = 0, size = 2, properties = null, 
readOnlyProperties = true, readOnlyBody = true, text = 1}([C4064]: Cannot 
perform operation, producer is closed.)

 After this, it is automatically queueing messages without sending them, 
showing the log:

[DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No 
subscriptions registered, will not dispatch message at this time.

 Even if SunMQ is started again, ActiveMQ is not detecting the new situation, 
and continues queueing messages sent to SUNRECV.

Please, make me know if more information is needed to understand the situation.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: scout 0.5 jar still has bunk log4j.properties

2006-08-25 Thread Davanum Srinivas

Jason,

Let me check.. is there a ETA? when we need this by?

-- dims

On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote:

Do we have any friends at the ws project that can re-release scout
0.5 without a log4j.properties file?

Or else... I think we need to add some magic to the build to
download, strip that file and then re-install the dependency to
remove the bunk log4j.properties file.

--jason




--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)


[jira] Commented: (AMQ-895) JMS to JMS Bridge never reconnects under remote broker restarts.

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-895?page=comments#action_36844 ] 

james strachan commented on AMQ-895:


I've tried adding a fix to SVN trunk. I wonder could you try it out for me to 
see if it fixes your issue? Basically I've patched the code to try reconnecting 
(by default a maximum of 10 times per message) if the send() fails before 
stopping the bridge.

Grab the latest code here...
http://incubator.apache.org/activemq/source.html

then build it...
http://incubator.apache.org/activemq/building.html

 JMS to JMS Bridge never reconnects under remote broker restarts.
 

 Key: AMQ-895
 URL: https://issues.apache.org/activemq/browse/AMQ-895
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0 RC2, 4.0.1
Reporter: Manuel Teira

 I'm using ActiveMQ (4.0.1) JMS to JMS Bridge functionality to connect to a  
 SunMQ JMS Broker (3.6 SP3  (Build 02-A)). I'm using two queues, an input and 
 an output one, with the following configuration:
 jmsBridgeConnectors
   jmsQueueConnector outboundQueueConnectionFactory=#REMOTE
   outboundQueueBridges
 outboundQueueBridge outboundQueueName=SUNRECV/
   /outboundQueueBridges
   inboundQueueBridges
 inboundQueueBridge inboundQueueName=SUNSEND/
   /inboundQueueBridges
   /jmsQueueConnector
 /jmsBridgeConnectors
 The system works really well until the SunMQ broker needed to be restarted. 
 This is what I found:
 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a while, 
 but no log on ActiveMQ indicates knowledge about the new situation.
 2.-When I send a message to the output queue SUNRECV, ActiveMQ complains that 
 the producer is closed:
 [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to forward 
 message: ActiveMQTextMessage {commandId = 5, responseRequired = false, 
 messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1, originalDestination = 
 null, originalTransactionId = null, producerId = 
 ID:trabucco-43457-1156491843149-3:4:1:1, destination = queue://SUNRECV, 
 transactionId = null, expiration = 0, timestamp = 1156492032027, arrival = 0, 
 correlationId = null, replyTo = null, persistent = false, type = null, 
 priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null, 
 compressed = false, userID = null, content = null, marshalledProperties = 
 null, dataStructure = null, redeliveryCounter = 0, size = 2, properties = 
 null, readOnlyProperties = true, readOnlyBody = true, text = 1}([C4064]: 
 Cannot perform operation, producer is closed.)
  After this, it is automatically queueing messages without sending them, 
 showing the log:
 [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No 
 subscriptions registered, will not dispatch message at this time.
  Even if SunMQ is started again, ActiveMQ is not detecting the new situation, 
 and continues queueing messages sent to SUNRECV.
 Please, make me know if more information is needed to understand the 
 situation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Rick McGuire

Joe Bohn wrote:

For me it's

Maven version: 2.0.4

java version 1.4.2_08
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)

I didn't compile any maven plugins locally.

Anything else?  I'm running on windows XP and most folks I know 
with this problem are also on windows.  However, as with Sergey, there 
are a few folks seeing it on *nix.
I'm seeing this on both Windows XP and Linux (Fedora Core 4).  Problem 
showed up initially after doing a svn switch to the new repository + 
update.  I then did a fresh checkout to see if that fixed the problem 
(it didn't).  Did a fresh checkout on Linux also and it had the problem 
too.


My maven/jvm version is the same as yours.


Joe


Sergey Elin wrote:

In my case it's:
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(1)$ 
mvn -v

Maven version: 2.0.4
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
java -version

java version 1.4.2-p7
Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2-p7-_17_may_2006_11_07)
Java HotSpot(TM) Client VM (build 1.4.2-p7-_17_may_2006_11_07, mixed 
mode)
[EMAIL PROTECTED]:/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples(0)$ 
uname -sr

OpenBSD 4.0

I just got sources from svn and try to build it according BUILDING.txt
First try was 08/23/06 and it was success
Second - yesterday (after switching subversion and update) and it 
finished with this error.



2006/8/25, Jason Dillon [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED]:


I have never seen this error.

What version of Maven are you using?  What version of Java?  Did you
compile any Maven plugins locally?  Anything else that could be odd
about your environment?

--jason


On Aug 24, 2006, at 9:17 PM, Joe Bohn wrote:

 
  Is there any new news on this (or a work around)?  It seems that
  Sergey had success with the 1.4.3 version of the jspc plugin.
  However, when I tried that I just get a different error (see 
below
  [1] ). The demo target includes just a web-fragment.xml file 
rather

  that a jsp-source directory.
 
  BDudney then recommended I try with the jsp compilation removed
  from demo.  I gave that a shot this evening and got the next 
error
  ([2] below).  I only removed the reference to the 
jspc-maven-plugin

  in the demo pom ... perhaps I needed to change something else?
 
  Seems like using 1.4.3 is causing more problems than it's fixing
  for me.  Any other ideas?
 
  Joe
 
 
  [1]
  [INFO]
 

--

  --
  [INFO] Building Geronimo Applications :: Demo
  [INFO]task-segment: [clean, install]
  [INFO]
 

--

  --
  [INFO] [clean:clean]
  [INFO] Deleting directory C:\g\applications\demo\target
  [INFO] Deleting directory C:\g\applications\demo\target\classes
  [INFO] Deleting directory 
C:\g\applications\demo\target\test-classes

  [INFO] [tools:require-java-version {execution: default}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] No sources to compile
  [INFO] [jspc:compile {execution: jspc}]
  [INFO] Compiling new java files...
  [INFO]
 

--

  --
  [ERROR] BUILD ERROR
  [INFO]
 

--

  --
  [INFO] Error
 
  Embedded error: basedir 
C:\g\applications\demo\target\jsp-source is

  not a directory
  [INFO]
 

--

  --
  [INFO] For more information, run Maven with the -e switch
  [INFO]
 

--

  --
  [INFO] Total time: 6 minutes 25 seconds
  [INFO] Finished at: Thu Aug 24 16:29:58 EDT 2006
  [INFO] Final Memory: 43M/63M
  [INFO]
 

--

  --
 
 
 
 
  [2]
  [INFO]
 

--

  --
  [INFO] Building Geronimo Applications :: Demo
  [INFO]task-segment: [install]
  [INFO]
 

--

  --
  [INFO] [tools:require-java-version {execution: default}]
  [INFO] [resources:resources]
  [INFO] Using default encoding to copy filtered resources.
  [INFO] [compiler:compile]
  [INFO] No sources to 

[jira] Assigned: (AMQ-855) Add support for prefetchSize = 0

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-855?page=all ]

james strachan reassigned AMQ-855:
--

Assignee: Hiram Chirino

 Add support for prefetchSize = 0
 

 Key: AMQ-855
 URL: https://issues.apache.org/activemq/browse/AMQ-855
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Affects Versions: 4.0, 4.0.1, 4.0.2
 Environment: any
Reporter: Vadim Pesochinskiy
 Assigned To: Hiram Chirino
Priority: Critical
 Fix For: 4.1

 Attachments: ActiveMQMessageConsumer.patch, 
 ActiveMQMessageConsumer.patch2, PrefetchSubscription.patch


 This feature would enable to support following test case:
 2 servers are processing 3 submitted jobs with following processing times 10 
 min, 1 min, 1 min. This sequence should finish in 10 minutes as one service 
 will pick up the 10 minutes job, meanwhile the other one should manage the 
 two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute 
 jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes 
 instead of 10.
 This is simplification of the real scenario where I have about 30 consumers 
 submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems:
 • Messages are sitting in prefetch buffer are not available to processors, 
 which results in a lot of idle time.
 • Order of processing is random. For some reason Job # 20 is processed after 
 Job # 1500. Since senders are synchronously blocked this can result in 
 time-outs.
 • Some requests are real-time, i.e. there is a user waiting, so the system 
 cannot wait, so AMQ-850 does not fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-826) LDAP based authorization support

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-826?page=comments#action_36845 ] 

james strachan commented on AMQ-826:


Nikola - any progress on getting a test case to work?


 LDAP based authorization support
 

 Key: AMQ-826
 URL: https://issues.apache.org/activemq/browse/AMQ-826
 Project: ActiveMQ
  Issue Type: Improvement
Reporter: james strachan
 Assigned To: Nikola Goran Cutura
 Attachments: LdapAuth.zip


 Patch kindly added by ngcutura - discussion thread...
 http://www.nabble.com/LDAP-Authorization-tf1851705.html#a5344494

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-895) JMS to JMS Bridge never reconnects under remote broker restarts.

2006-08-25 Thread Manuel Teira (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-895?page=comments#action_36846 ] 

Manuel Teira commented on AMQ-895:
--

Thanks a lot, James. 

I'm not familiar with maven usage and I'm getting an error I don't know the 
cause of:

Downloading: http://ibiblio.org/maven2//directory-shared/ldap-common/0.9.1/ldap-
common-0.9.1.pom
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: directory-shared:ldap-common

Reason: Error getting POM for 'directory-shared:ldap-common' from the repository
: Error transferring file
  directory-shared:ldap-common:pom:0.9.1


Thanks.


 JMS to JMS Bridge never reconnects under remote broker restarts.
 

 Key: AMQ-895
 URL: https://issues.apache.org/activemq/browse/AMQ-895
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0 RC2, 4.0.1
Reporter: Manuel Teira

 I'm using ActiveMQ (4.0.1) JMS to JMS Bridge functionality to connect to a  
 SunMQ JMS Broker (3.6 SP3  (Build 02-A)). I'm using two queues, an input and 
 an output one, with the following configuration:
 jmsBridgeConnectors
   jmsQueueConnector outboundQueueConnectionFactory=#REMOTE
   outboundQueueBridges
 outboundQueueBridge outboundQueueName=SUNRECV/
   /outboundQueueBridges
   inboundQueueBridges
 inboundQueueBridge inboundQueueName=SUNSEND/
   /inboundQueueBridges
   /jmsQueueConnector
 /jmsBridgeConnectors
 The system works really well until the SunMQ broker needed to be restarted. 
 This is what I found:
 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a while, 
 but no log on ActiveMQ indicates knowledge about the new situation.
 2.-When I send a message to the output queue SUNRECV, ActiveMQ complains that 
 the producer is closed:
 [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to forward 
 message: ActiveMQTextMessage {commandId = 5, responseRequired = false, 
 messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1, originalDestination = 
 null, originalTransactionId = null, producerId = 
 ID:trabucco-43457-1156491843149-3:4:1:1, destination = queue://SUNRECV, 
 transactionId = null, expiration = 0, timestamp = 1156492032027, arrival = 0, 
 correlationId = null, replyTo = null, persistent = false, type = null, 
 priority = 0, groupID = null, groupSequence = 0, targetConsumerId = null, 
 compressed = false, userID = null, content = null, marshalledProperties = 
 null, dataStructure = null, redeliveryCounter = 0, size = 2, properties = 
 null, readOnlyProperties = true, readOnlyBody = true, text = 1}([C4064]: 
 Cannot perform operation, producer is closed.)
  After this, it is automatically queueing messages without sending them, 
 showing the log:
 [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No 
 subscriptions registered, will not dispatch message at this time.
  Even if SunMQ is started again, ActiveMQ is not detecting the new situation, 
 and continues queueing messages sent to SUNRECV.
 Please, make me know if more information is needed to understand the 
 situation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Resolved: (AMQ-890) JMX purge() fails with a ConcurrentModificationException

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-890?page=all ]

james strachan resolved AMQ-890.


Fix Version/s: 4.1
   Resolution: Fixed

Patch applied - many thanks!

 JMX purge() fails with a ConcurrentModificationException
 

 Key: AMQ-890
 URL: https://issues.apache.org/activemq/browse/AMQ-890
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0.2
Reporter: John Heitmann
Priority: Minor
 Fix For: 4.1

 Attachments: purge.patch.gz


 I think this must be an issue running under jdk 1.5 only. It shows up on Mac 
 OS X and Linux 1.5 jvms. Remove and gc() were stumbling over each other and 
 invalidating the iterator. I broke them apart a bit to avoid the exception. 
 Thanks to Alan Robbins for help tracking this down.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (GERONIMO-2274) realm-principal does not work in web app security

2006-08-25 Thread Vamsavardhana Reddy (JIRA)
 [ http://issues.apache.org/jira/browse/GERONIMO-2274?page=all ]

Vamsavardhana Reddy updated GERONIMO-2274:
--

Attachment: Geronimo-2274-tester.zip

Geronimo-2274-tester.zip:  Contains a realm plan and a test web app to verify 
if realm-principal is woking properly in security mapping.

 realm-principal does not work in web app security
 -

 Key: GERONIMO-2274
 URL: http://issues.apache.org/jira/browse/GERONIMO-2274
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.1
 Environment: WinXP, G1.1.1-SNAPSHOT, Tomcat
Reporter: Vamsavardhana Reddy
 Assigned To: Alan Cabrera
 Fix For: 1.2, 1.1.2

 Attachments: Geronimo-2274-tester.zip, GERONIMO-2274.patch, 
 geronimo-web.xml, sql-realm-advanced.xml


 I have deployed a security realm with wrap-principals set to true.  Then, I 
 have deployed a web application to authenticate against this security realm.  
 In the web app deployment plan, I have used realm-principal in role mapping.  
 Even though login is successful, I am getting Error HTTP 403 Forbidden.  
 Authorization works as expected if I use login-domain-principal or principal 
 instead of realm-principal.  Appears like realm-principal is not working as 
 expected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
now).  I added the jasper-compiler-jdt.  Please try this version and let
me know if all works.  If so I will start a vote at Mojo to release 1.4.5.

Thanks,

Jeff

Sergey Elin wrote:
 It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in
 maven 2: required dependency to jasper-compiler-jdt is missing.
 I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and
 successfully build geronimo-jsp-examples.
 
 
 2006/8/25, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
 
 Can you send me to full `mvn -X` from the
 applications/geronimo-examples/geronimo-jsp-examples plz.
 
 --jason
 
 
 On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:
 
 Yes


 2006/8/25, Jason Dillon  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]:

 Does this file actually have that class
 (org/eclipse/jdt/internal/compiler/env/INameEnvironment):

   
  /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-
 compiler-jdt-5.5.15.jar

 --jason


 On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:

 Here is a bit more info:

 [INFO] [jspc:compile {execution: jspc}]
 [DEBUG] execute() starting for 0 pages.
 [DEBUG] Parent class loader is: [EMAIL PROTECTED]
 [DEBUG] Compilation classpath initialized:
 
 /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/

 
 target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz

 
 /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/

 
 home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com

 
 piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0

 
 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni

 mo-servlet_2.4_spec-1.0.1.jar:
 [DEBUG] No Java compiler available
 java.lang.NoClassDefFoundError :
 org/eclipse/jdt/internal/compiler/env/INameEnvironment
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:141)
 at
 org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:233)
 at
 org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:213)
 at org.apache.jasper.JspC.processFile(JspC.java:979)
 at org.apache.jasper.JspC.execute (JspC.java:1135)
 at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(
 AbstractJspcMojo.java:180)
 at
 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java
 :534)
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java
 :475)
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java
 :454)
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java
 :306
 )
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments
 (DefaultLifecycleExecutor.java:273)
 at
 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
 :140)
 at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java
 :256)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke (Method.java:324)
 at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch
 (Launcher.java:255)
 at org.codehaus.classworlds.Launcher.mainWithExitCode
 (Launcher.java:430)
 at
 

Re: Strange build error on trunk

2006-08-25 Thread Bill Dudney
FWIW, I just finished a fresh checkout and 'mvn install' without  
error. No modifications of anything (I did not run the bootstrap  
though to delete my ~/.m2/repo).


TTFN,

-bd-

On Aug 25, 2006, at 8:30 AM, Jeff Genender wrote:


I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
now).  I added the jasper-compiler-jdt.  Please try this version  
and let
me know if all works.  If so I will start a vote at Mojo to release  
1.4.5.


Thanks,

Jeff

Sergey Elin wrote:
It seems there is the wrong configuration for jspc-maven-plugin  
1.4.4 in

maven 2: required dependency to jasper-compiler-jdt is missing.
I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and
successfully build geronimo-jsp-examples.


2006/8/25, Jason Dillon [EMAIL PROTECTED]  
mailto:[EMAIL PROTECTED]:


Can you send me to full `mvn -X` from the
applications/geronimo-examples/geronimo-jsp-examples plz.

--jason


On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:


Yes


2006/8/25, Jason Dillon  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:

Does this file actually have that class
(org/eclipse/jdt/internal/compiler/env/INameEnvironment):


 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/ 
5.5.15/jasper-

compiler-jdt-5.5.15.jar

--jason


On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:


Here is a bit more info:

[INFO] [jspc:compile {execution: jspc}]
[DEBUG] execute() starting for 0 pages.
[DEBUG] Parent class loader is:  
[EMAIL PROTECTED]

[DEBUG] Compilation classpath initialized:
/usr/home/cruz/java/geronimo/applications/geronimo- 
examples/geronimo-jsp-examples/


target/jsp-source:/usr/home/cruz/java/geronimo/ 
applications/geronimo-examples/geronimo-jsp-examples/target/ 
classes:/home/cruz


/.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/ 
home/cruz/.m2/repository/taglibs/standard/1.1.1/ 
standard-1.1.1.jar:/


home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/ 
jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/ 
jasper-com


piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/ 
cruz/.m2/repository/org/apache/geronimo/specs/geronimo- 
jsp_2.0_spec/1.0


.1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/ 
repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/ 
1.0.1/geroni


mo-servlet_2.4_spec-1.0.1.jar:
[DEBUG] No Java compiler available
java.lang.NoClassDefFoundError :
org/eclipse/jdt/internal/compiler/env/INameEnvironment
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at
org.apache.jasper.JspCompilationContext.createCompiler
(JspCompilationContext.java:233)
at
org.apache.jasper.JspCompilationContext.createCompiler
(JspCompilationContext.java:213)
at org.apache.jasper.JspC.processFile(JspC.java: 
979)

at org.apache.jasper.JspC.execute (JspC.java:1135)
at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(
AbstractJspcMojo.java:180)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo 
(DefaultPluginManager.java:412)

at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
(DefaultLifecycleExecutor.java

:534)
at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWith 
Lifecycle(DefaultLifecycleExecutor.java

:475)
at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
(DefaultLifecycleExecutor.java

:454)
at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndH 
andleFailures(DefaultLifecycleExecutor.java

:306
)
at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegm 
ents

(DefaultLifecycleExecutor.java:273)
at
 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute 
(DefaultLifecycleExecutor.java

:140)
at
org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:322)

at
org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 
115)

at org.apache.maven.cli.MavenCli.main(MavenCli.java
:256)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke (Method.java: 
324)

at
org.codehaus.classworlds.Launcher.launchEnhanced 
(Launcher.java:315)

at 

Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
1.4.5-SNAPSHOT is an important one besides due to the forking problems
in Maven.  The jspc plugin in 1.4.5 now forces a second compile after
source generation.  Under normal circumstances, this is fine, but in
certain situations (i.e. complex mixture of plugins), if forces a full
build again.  I am recommending 1.4.5-SNAPSHOT and if works going to
1.4.5 to avoid any future issues.

Jeff

Bill Dudney wrote:
 FWIW, I just finished a fresh checkout and 'mvn install' without error.
 No modifications of anything (I did not run the bootstrap though to
 delete my ~/.m2/repo).
 
 TTFN,
 
 -bd-
 
 On Aug 25, 2006, at 8:30 AM, Jeff Genender wrote:
 
 I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
 now).  I added the jasper-compiler-jdt.  Please try this version and let
 me know if all works.  If so I will start a vote at Mojo to release
 1.4.5.

 Thanks,

 Jeff

 Sergey Elin wrote:
 It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in
 maven 2: required dependency to jasper-compiler-jdt is missing.
 I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and
 successfully build geronimo-jsp-examples.


 2006/8/25, Jason Dillon [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]:

 Can you send me to full `mvn -X` from the
 applications/geronimo-examples/geronimo-jsp-examples plz.

 --jason


 On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:

 Yes


 2006/8/25, Jason Dillon  [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]:

 Does this file actually have that class
 (org/eclipse/jdt/internal/compiler/env/INameEnvironment):


 
 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-
 compiler-jdt-5.5.15.jar

 --jason


 On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:

 Here is a bit more info:

 [INFO] [jspc:compile {execution: jspc}]
 [DEBUG] execute() starting for 0 pages.
 [DEBUG] Parent class loader is:
 [EMAIL PROTECTED]
 [DEBUG] Compilation classpath initialized:

 /usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/



 target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz



 /.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/



 home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com



 piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0



 .1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni


 mo-servlet_2.4_spec-1.0.1.jar:
 [DEBUG] No Java compiler available
 java.lang.NoClassDefFoundError :
 org/eclipse/jdt/internal/compiler/env/INameEnvironment
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:141)
 at
 org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:233)
 at
 org.apache.jasper.JspCompilationContext.createCompiler
 (JspCompilationContext.java:213)
 at org.apache.jasper.JspC.processFile(JspC.java:979)
 at org.apache.jasper.JspC.execute (JspC.java:1135)
 at org.codehaus.mojo.jspc.AbstractJspcMojo.execute(
 AbstractJspcMojo.java:180)
 at

 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)

 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java

 :534)
 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java

 :475)
 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java

 :454)
 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java

 :306
 )
 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments

 (DefaultLifecycleExecutor.java:273)
 at

 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java

 :140)
 at
 org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
 at
 org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java
 :256)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke0(Native 

Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-08-25 Thread Paul McMahan

I don't necessarily think its a requirement for the site to run on
Apache hardware. But if the Geronimo dev community thinks this is
important then I'm definitely game.  All of the software currently
used to run the site is free/open source -- Apache HTTP, Joomla, PHP,
MySQL, SimpleForum, and xtdratings.  But I am looking into some
low-end commercial software to replace SimpleForum and xtdratings
since I'm really starting to feel the pain of you get what you pay
for :-)   I don't know where infra draws the line on what software
they'll agree to host on Apache hardware.

Best wishes,
Paul

On 8/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote:

On Aug 24, 2006, at 1:42 PM, Matt Hogstrom wrote:

 I don't think they are competing but complimentary.  If I'm looking
 at it right the site Paul is proposing is a clearing house for all
 plugin sites that is ASF Geronimo focused.  It then points to any
 number of other plugin sites (geronimoplugins.com would hopefully
 be the first of many).  At least for those that follow Eclipse the
 naming is similar as well (eclipseplugincentral.com).  So I see
 them as working together based on Paul's proposal and in line with
 another successful open source project.

 Another difference is this site was intended to be hosted on ASF
 infrastructure for the Geronimo project.  I think the
 geronimoplugins.com site was specifically hosted externally as it
 contains a variety of open source licensed code.
 Geronimoplugincentral.com is a clearing house and not a warehouse.

If it is intended to run on apache hardware, then why not use
geronimo.apache.org/plugins?

-dain



[jira] Commented: (GERONIMO-2348) Tomcat ConnectorGBean does not handle attribute values properly

2006-08-25 Thread Matt Hogstrom (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2348?page=comments#action_12430522
 ] 

Matt Hogstrom commented on GERONIMO-2348:
-

If there is a problem with Tomcat then this patch needs to be taken to the 
Tomcat dev list.  I suggest opening a bugzilla report over there and providing 
the Tomcat patch over there.

 Tomcat ConnectorGBean does not handle attribute values properly
 ---

 Key: GERONIMO-2348
 URL: http://issues.apache.org/jira/browse/GERONIMO-2348
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Tomcat
Affects Versions: 1.0, 1.1, 1.1.1
 Environment: Win XP, Geronimo Tomcat 1.1.1-SNAPSHOT
Reporter: Vamsavardhana Reddy
 Assigned To: Vamsavardhana Reddy
 Fix For: 1.2, 1.1.x, 1.1.2

 Attachments: GERONIMO-2348.patch, http11protocol.patch


 Tomcat ConnectorGBean does not handle the following attributes properly.
   1.  hostLookupEnabled
   2.  redirectPort
   3.  maxSavePostSize
   4.  useBodyEncodingForURI
 There may be other attributes that are not handled properly as well.  So, far 
 I have confirmed the above list.  I will continue investigation and update 
 the list.
 A similar problem GERONIMO-2343 is observed and fixed by Krishnakumar B.  And 
 the fix is also similar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Rick McGuire

Well, the result is different, but still a build failure:

[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Errors found during compilation.
[INFO] 


[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Errors found 
during compilation.
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java 
:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java 
:306)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java 
:140)

   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:324)
   at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

   at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException : Errors found 
during compilation.
   at 
org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:257)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)

   ... 16 more
[INFO] 


[INFO] Total time: 6 minutes 6 seconds
[INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO] 


[EMAIL PROTECTED] 1.2]$


Jeff Genender wrote:

I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
now).  I added the jasper-compiler-jdt.  Please try this version and let
me know if all works.  If so I will start a vote at Mojo to release 1.4.5.

Thanks,

Jeff

Sergey Elin wrote:
  

It seems there is the wrong configuration for jspc-maven-plugin 1.4.4 in
maven 2: required dependency to jasper-compiler-jdt is missing.
I just add dependency to plugin's jspc-maven-plugin-1.4.4.pom   and
successfully build geronimo-jsp-examples.


2006/8/25, Jason Dillon [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:

Can you send me to full `mvn -X` from the
applications/geronimo-examples/geronimo-jsp-examples plz.

--jason


On Aug 25, 2006, at 12:32 AM, Sergey Elin wrote:



Yes


2006/8/25, Jason Dillon  [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:

Does this file actually have that class
(org/eclipse/jdt/internal/compiler/env/INameEnvironment):

  
 /home/cruz/.m2/repository/tomcat/jasper-compiler-jdt/5.5.15/jasper-

compiler-jdt-5.5.15.jar

--jason


On Aug 25, 2006, at 12:13 AM, Sergey Elin wrote:

  

Here is a bit more info:

[INFO] [jspc:compile {execution: jspc}]
[DEBUG] execute() starting for 0 pages.
[DEBUG] Parent class loader is: [EMAIL PROTECTED]
[DEBUG] Compilation classpath initialized:

/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/


target/jsp-source:/usr/home/cruz/java/geronimo/applications/geronimo-examples/geronimo-jsp-examples/target/classes:/home/cruz


/.m2/repository/javax/servlet/jstl/1.1.1/jstl-1.1.1.jar:/home/cruz/.m2/repository/taglibs/standard/1.1.1/standard-1.1.1.jar:/


home/cruz/.m2/repository/tomcat/jasper-compiler/5.5.15/jasper-compiler-5.5.15.jar:/home/cruz/.m2/repository/tomcat/jasper-com


piler-jdt/5.5.15/jasper-compiler-jdt-5.5.15.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-jsp_2.0_spec/1.0


.1/geronimo-jsp_2.0_spec-1.0.1.jar:/home/cruz/.m2/repository/org/apache/geronimo/specs/geronimo-servlet_2.4_spec/1.0.1/geroni

   

[jira] Resolved: (AMQ-892) Allow the JMX RMI server port to be hard set

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-892?page=all ]

james strachan resolved AMQ-892.


Fix Version/s: 4.1
   Resolution: Fixed

Patch applied John thanks!

I've been thinking we should encourage folks to use the standard JMX 
configuration system properties and an optional security manager and policy 
file as opposed to the xbean.xml stuff - but its good to keep that working fine 
for folks who want to use it.

 Allow the JMX RMI server port to be hard set
 

 Key: AMQ-892
 URL: https://issues.apache.org/activemq/browse/AMQ-892
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 4.0.2
Reporter: John Heitmann
Priority: Minor
 Fix For: 4.1

 Attachments: jmxPort.patch


 When debugging a broker over the firewall with JMX it's often necessary to 
 use ssh tunneling. JMX uses 2 ports. The RMI registry port is what is 
 typically configured, but JMX also runs an RMI server on a different port-- 
 one that's typically chosen randomly. When you're ssh tunneling you need to 
 know what ports to tunnel to a priori so this is no good.
 This patch adds a setting to allow the RMI server port to be set in addition 
 to the registry port. This is what it looks like in xml:
 managementContext connectorPort=11099 rmiServerPort=9 
 jmxDomainName=org.apache.activemq/
 Also I snuck in a one-liner change that will create the connector if the user 
 configured jmx. This seems like the right thing to do, but my JMX experience 
 is pretty limited so it could break in something like Tomcat. Please take a 
 close look at that line before applying.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Resolved: (AMQ-889) Broker 'loses' messages and leaks resources when handling duplicate connections

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-889?page=all ]

james strachan resolved AMQ-889.


Fix Version/s: 4.1
   Resolution: Fixed

Patch applied - many thanks John! I had to make a minor patch to the MBeans to 
work with this patch (MBeanTest was failing) as we were being naughty and 
reusing the same consumerId on each createDurableSubscriber() MBean operation.

You're right that 1, 2, 4 are a concern too - any patches in those areas are 
most welcome :)

For 1) am thinking that the same IDs shoudl be used (so that then a broker is 
capable of deducing that a new connection is actually for an already existing 
client/subscription etc). We want to avoid tearing down and recreating a 
subscription if possible as for topics this could lead to message loss.

I do think we need some more logic in the broker that if it receives a 
duplicate client, it will first check to see if the old one is dead as it seems 
quite common to get duplicate clientID when the client things the socket is 
dead and reconnects before the broker notices that the client is dead. e.g. we 
should maybe wait until we try to ping the old client, if that times out, kill 
the old connection.

For 4) this seem to be a duplicate of AMQ-850 where we should timeout inactive 
consumers

 Broker 'loses' messages and leaks resources when handling duplicate 
 connections
 ---

 Key: AMQ-889
 URL: https://issues.apache.org/activemq/browse/AMQ-889
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0.2
Reporter: John Heitmann
 Fix For: 4.1

 Attachments: doubleConsumer.patch.gz


 A client that uses a transport like the failover transport can damage the 
 broker's ability to deliver messages to other clients and ultimately cause 
 broker resource leaks and message loss. I've found 4 issues starting on the 
 client and ending on the broker that could be improved to make the situation 
 a lot better. In this issue I've provided a patch for #3.
 1) A failover client stores session metadata commands like ConsumerInfo in a 
 local state tracker. When failover occurs it replays these commands verbatim 
 to the newly connected-to broker. If the failover transport fails back to the 
 original broker it will replay the same commands with the same ids as it 
 already sent the broker. If the failover happens before the broker notices 
 the old connection has gone this can result in bad mojo. Clients should 
 probably regenerate session, consumer, and maybe connection ids.
 2) When the broker detects a duplicate ClientId being sent to it it throws an 
 exception saying so, but this does not stop the broker from processing 
 subsequent messages on that connection. The broker should tear down the 
 connection immediately when it sees a client thrashing about.
 3) When a broker receives a certain series of ConsumerInfo add and remove 
 commands with the same ConsumerId it leaks resources. One of the resources 
 leaked is the knowledge of lock owners on messages out in prefetch buffers. 
 This means those messages are stuck forever on the broker and can never be 
 retrieved and never be gc()ed. More below.
 4) Messages locked and out in prefetch buffers have no broker-side timeout. 
 If a consumer is up, saying hello to the inactivity monitor, but otherwise 
 doing nothing then its messages are locked forever. The broker should have a 
 janitor that redrives stale messages. This seems like the hardest of the 4 to 
 fix, but is one of the most important.
 More on #3: One bad sequence of events is:
 1) Consumer 'c' connects to the broker over a failover transport. 
 2) c subscribes to a queue and addConsumer() gets called. 
 3) c fails away and then fails back.
 4) c replays ConsumerInfo to the broker. addConsumer() gets called again and 
 overwrites subscription tracking from the first.
 After this the broker will eventually get a double remove and there will be 
 noisy JMX complaints etc., but the serious problem has already occurred in 
 step 4. My patch synchronizes the add step so that the  broker is protected. 
 The individual client will still be a bit confused, and there will still be 
 noise when the second remove comes and JMX can't find the consumer to remove, 
 but the resource and message leaks are taken care of.
 I'll file issues on the other 3 problems if they sound valid to you and 
 aren't already entered.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Assigned: (AMQ-891) InterruptedException handling tweaks

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-891?page=all ]

james strachan reassigned AMQ-891:
--

Assignee: Hiram Chirino

Do you wanna handle this one - I seem to remember you doing some work on the 
interupted stuff?

 InterruptedException handling tweaks
 

 Key: AMQ-891
 URL: https://issues.apache.org/activemq/browse/AMQ-891
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.0.2
Reporter: John Heitmann
 Assigned To: Hiram Chirino
Priority: Minor
 Attachments: interrupted.patch.gz


 There were a few spots where the broker was masking the interrupt state after 
 handling an InterruptedException. This is a lint pass to clean some of that 
 up. I learned after I made this patch that it's actually slightly better 
 stylistically to call Thread.interrupt() instead of 
 Thread.currentThread().interrupt() since it's static and the interrupt state 
 is global(ish), but this is the version we've tested.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-08-25 Thread Paul McMahan

Dain,  One additional aspect I just thought of is that the Geronimo
team might decide to someday create a plugin repository that is
equivalent to geronimoplugins.com at the location you mentioned
(geronimo.apache.org/plugins) for hosting plugins that are developed
by/for the Apache projects.  geronimoplugincentral.org would point at
the plugins hosted at that site, Aaron's site, commercial sites, Joe's
mom's site, etc...

Best wishes,
Paul

On 8/25/06, Paul McMahan [EMAIL PROTECTED] wrote:

I don't necessarily think its a requirement for the site to run on
Apache hardware. But if the Geronimo dev community thinks this is
important then I'm definitely game.  All of the software currently
used to run the site is free/open source -- Apache HTTP, Joomla, PHP,
MySQL, SimpleForum, and xtdratings.  But I am looking into some
low-end commercial software to replace SimpleForum and xtdratings
since I'm really starting to feel the pain of you get what you pay
for :-)   I don't know where infra draws the line on what software
they'll agree to host on Apache hardware.

Best wishes,
Paul

On 8/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote:
 On Aug 24, 2006, at 1:42 PM, Matt Hogstrom wrote:

  I don't think they are competing but complimentary.  If I'm looking
  at it right the site Paul is proposing is a clearing house for all
  plugin sites that is ASF Geronimo focused.  It then points to any
  number of other plugin sites (geronimoplugins.com would hopefully
  be the first of many).  At least for those that follow Eclipse the
  naming is similar as well (eclipseplugincentral.com).  So I see
  them as working together based on Paul's proposal and in line with
  another successful open source project.
 
  Another difference is this site was intended to be hosted on ASF
  infrastructure for the Geronimo project.  I think the
  geronimoplugins.com site was specifically hosted externally as it
  contains a variety of open source licensed code.
  Geronimoplugincentral.com is a clearing house and not a warehouse.

 If it is intended to run on apache hardware, then why not use
 geronimo.apache.org/plugins?

 -dain




Re: [STATUS] (geronimo) Wed Aug 23 23:48:53 2006

2006-08-25 Thread Matt Hogstrom



Rodent of Unusual Size wrote:

APACHE GERONIMO STATUS: -*-text-*-
Last modified at [$Date: 2006-08-17 21:07:33 -0400 (Thu, 17 Aug 2006) $]

The current version of this file can be found at:

  * http://svn.apache.org/repos/asf/geronimo/trunk/STATUS

Upcoming Releases:

  Geronimo 1.2 -- geronimo/trunk/
Release Manager:  Matt Hogstrom

Release manager is not yet voted.  I'm leading the discussion to get it rolling.

Estimated Date: September ??

  November 15th or so.

  Geronimo 1.1.1 -- geronimo/branches/1.1

Release Manager:  Matt Hogstrom
Estimated Date: August ??

  September 8th


RELEASE SHOWSTOPPERS:

Currently the 1.1.1 release is addressing security issues that are related to CTS failures as well 
as reworking our build and release process to address potential violations of Sun's License for the 
specification related XSDs.  Our work around includes using XML beans to download and generate the 
code necessary to manipulate the XSDs without including Sun's content in SVN or our released code.


Outstanding patches awaiting votes:


On JIRA, the following patches are oustanding:

XBEAN-45	Move classloaders to their own module	 Patch Available	 Alan Cabrera			Opened 19/Aug/06 
Status: review needed.  1 +1 vote provided...need two more


GERONIMO-2332	RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module 
so we don't need the schemas in svn at all	 Patch Available	 David Jencks			Opened: 18/Aug/06 
Status: in progress


GERONIMO-2248	Applications portlets: List Parent and Child components against each component	 
Patch Available	 Unassigned		

Opened: 30/Jul/06   Status: Needs to complete voting and apply to 
1.1.2 and trunk

GERONIMO-2163   WADI Integration for Jetty   Patch Available Gianny 
Damour  
*Opened*: 02/Jul/06 *Status*: Not actually in a state for 
voting...this is in a discussion state.

GERONIMO-2015   Let's replace JKS to PKCS12 key store type
*Opened*:   *Status*: In discussion...although not totally 
active





Release history:
  2006-06-26  Geronimo 1.1
  2006-01-05  Geronimo 1.0
  2005-10-04  Geronimo 1.0 milestone 5
  2005-08-10  Geronimo 1.0 milestone 4
  2004-11-11  Geronimo 1.0 milestone 3
  2004-09-09  Geronimo 1.0 milestone 2
  2004-04-29  Geronimo 1.0 milestone 1


If you're a contributor looking for something to do:

  * Review the documentation and suggest improvements
  * Review the bug list and suggest fixes or report reproducibility
  * Report bugs yourself





Re: Declarative Exception Handling in ServiceMix

2006-08-25 Thread jpuro

I hear these arguments.  My use case may not have been the best example, but
I have run into many other situations where the business requires that we
handle runtime exceptions more gracefully and allow for smarter routing. 
Perhaps just adding a new EIP pattern that specifically can handle
exceptions would do the trick.

-Jeff


Philip Dodds-2 wrote:
 
 I Agree that I'm not sure you should build in exception routing when it is
 better placed as another component that handles the Call and return of an
 exception.  It would seem that when building up services you should be
 handling exceptions and returning faults/exceptions in a clean fashion and
 that the routing of exceptions is better placed since I can see there
 becoming increasing details rquired for the routing.  Just thinking of a
 SQLException and then needing the sqlCode in order to determine the
 meaning of the exception before routing.
 
 Philip
 
 On 8/25/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

 I guess that if you want to handle exceptions in a JBI compliant way,
 you should put in the flow some specific components to do that.

 First, we need to make a distinction between faults and errors.
 Imho, faults are unrecoverable problems, due to the message itself.
 Errors are runtime problems, which may be able to be solved at
 a later time.

 In your example, depending on the reason why the data could not be
 stored in the database, the component should return a fault
 (if the data is corrupted) or an error (the database is down).

 In your use case, the error should be catched by a simple component
 (an EIP pattern) between the http component and  the business
 component which would act as a normal proxy when no errors are
 reported, and redirect the flow elsewhere when an error occurs.

 Also, I don't really understand the friendly error concept ;)
 The http component is not designed to be a jsp server, so you
 won't have any nice interface there.  The output should be an xml.
 If you want a nice interface, you should deploy a web app which
 would call the jbi bus and return a nice html page when an error
 occurs.

 Last, while I think declarative transactions may be really useful
 for POJO based components (servicemix-jsr181, or the yet to be
 defined new component, see other threads on the list),
 it would be difficult to apply it in a real JBI world.

 Let's discuss it, it' s just my thoughts.

 On 8/25/06, jpuro [EMAIL PROTECTED] wrote:
 
 
  I think it would be useful to add declarative exception handling to
  ServiceMix.  The usefullness of such a feature can be seen from the
  following simple use case involving a client submitting an order to a
  fulfillment company:
 
  1)  The use case starts when the client sends an order to an HTTP
 endpoint
  exposed in ServiceMix.  The message representing the order is routed to
 a
  business service component.
 
  2)  The business service component attempts to process the Order and
 save
  it
  to a database.  However, an exception occurs during this process and
 gets
  bubbled up.  The fulfillment company would like to be notified via
 email
  when an order fails to be processed.  Since we have configured the
  business
  service component to pass all exceptions to an email component, the
 flow
  moves to step 3.
 
  3)  The email component sends out an email notification to the
 fulfillment
  company indicating that an error occurred while processing the order.
 
  4)  After the email has been sent out, the flow moves to another
 component
  that returns a more user friendly error message to the original HTTP
  endpoint.  This way we do not send back a hard to read error message to
  the
  client.
 
  The purpose of such a flow is that we handle exceptions more gracefully
  than
  currently is supported by ServiceMix.  Instead of bubbling up
 exceptions
  to
  the calling component, we should allow components to change the flow of
 a
  message when an exception occurs.
 
  The configuration could look something like the following:
 
  activationSpec componentName=businessServiceComponent
  service=example:businessService
 
 
 exceptionDestionationService=example:emailService
  sm:component
  bean class=
 com.mycompany.MyClass
  /
  /sm:component
  /activationSpec
 
  Alternatively, perhaps we can just use AOP to catch exceptions that
 occur
  within a component:
 
  sm:exceptionHandler
  exceptionType=javax.jbi.messaging.MessagingException
  destinationService=example:emailService
 
  activationSpec
 componentName=businessServiceComponent
 
 service=example:businessService
  sm:component
  bean class=
  com.mycompany.MyClass/
  /sm:component

[jira] Commented: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-877?page=comments#action_36854 ] 

james strachan commented on AMQ-877:


I tried to apply this patch to the current trunk and it broke test cases. I 
wonder if trunk has moved along a bit since your patch.

Could you try create another patch please and we can try again? Do the test 
cases all work for you with your patch applied?

 Patch: refactoring to allow alternative (using different storage interface) 
 Destinations implementations.
 -

 Key: AMQ-877
 URL: https://issues.apache.org/activemq/browse/AMQ-877
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
 Assigned To: Rob Davies
 Fix For: 4.1

 Attachments: destinationFactoryActiveMQPatch.txt


 We were looking at alternate message persistence mechanisms that can co-exist 
 in current ActiveMQ code base and we are thinking of a mechanism that is 
 somewhat incompatible with the current MessageStore and PersistenceAdapter 
 APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a 
 change as the PersistenceAdapter and MessageStore interfaces are referenced 
 directly by the RegionBroker and by both the Queue and Topic region 
 implementations. Therefore, we are proposing a relatively small backwards 
 compatible refactoring of the broker code that would eliminate all 
 dependencies on the PersistenceAdapter and MessageStore interfaces from those 
 classes that do not use them directly. This refactoring would also allow 
 creation of a custom Destination implementation that may use an alternative 
 persistence mechanism on a destination by destination basis (which is exactly 
 what we need to do).
   The main idea behind the refactoring is to replace many references to 
 PersistenceAdapter with a new interface: DestinationFactory:
   public abstract class DestinationFactory { 
   abstract public Destination createDestination(ConnectionContext 
 context, ActiveMQDestination destination, DestinationStatistics 
 destinationStatistics) throws Exception;
   abstract public Set getDestinations(); 
   abstract public SubscriptionInfo[] 
 getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException; 
   abstract public long getLastMessageBrokerSequenceId() throws 
 IOException; 
   abstract public void setRegionBroker(RegionBroker regionBroker); 
   } 
   Note that DestinationFactory doesn't mandate any specific persistence 
 mechanism. The classes that would reference it instead of PersistenceAdapter 
 are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the 
 AbstractRegion.createDestination method would be changed from abstract to an 
 implementation that uses DestinationFactory to create a destination.
   BrokerService could be changed to use DestinationFactory if one is 
 provided. If none is provided, it will create a DestinationFactory 
 implementation that instantiates Queue and Topic using PersistenceAdapter as 
 it does currently. Hence, full backwards compatibility will be maintained.
 Patch is attached.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Assigned: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]

james strachan reassigned AMQ-877:
--

Assignee: james strachan  (was: Rob Davies)

 Patch: refactoring to allow alternative (using different storage interface) 
 Destinations implementations.
 -

 Key: AMQ-877
 URL: https://issues.apache.org/activemq/browse/AMQ-877
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 4.x
Reporter: Maxim Fateev
 Assigned To: james strachan
 Fix For: 4.1

 Attachments: destinationFactoryActiveMQPatch.txt


 We were looking at alternate message persistence mechanisms that can co-exist 
 in current ActiveMQ code base and we are thinking of a mechanism that is 
 somewhat incompatible with the current MessageStore and PersistenceAdapter 
 APIs. Unfortunately, the current ActiveMQ broker doesn't allow for such a 
 change as the PersistenceAdapter and MessageStore interfaces are referenced 
 directly by the RegionBroker and by both the Queue and Topic region 
 implementations. Therefore, we are proposing a relatively small backwards 
 compatible refactoring of the broker code that would eliminate all 
 dependencies on the PersistenceAdapter and MessageStore interfaces from those 
 classes that do not use them directly. This refactoring would also allow 
 creation of a custom Destination implementation that may use an alternative 
 persistence mechanism on a destination by destination basis (which is exactly 
 what we need to do).
   The main idea behind the refactoring is to replace many references to 
 PersistenceAdapter with a new interface: DestinationFactory:
   public abstract class DestinationFactory { 
   abstract public Destination createDestination(ConnectionContext 
 context, ActiveMQDestination destination, DestinationStatistics 
 destinationStatistics) throws Exception;
   abstract public Set getDestinations(); 
   abstract public SubscriptionInfo[] 
 getAllDurableSubscriptions(ActiveMQTopic topic) throws IOException; 
   abstract public long getLastMessageBrokerSequenceId() throws 
 IOException; 
   abstract public void setRegionBroker(RegionBroker regionBroker); 
   } 
   Note that DestinationFactory doesn't mandate any specific persistence 
 mechanism. The classes that would reference it instead of PersistenceAdapter 
 are: RegionBroker, AbstractRegion, QueueRegion, and TopicRegion. Also, the 
 AbstractRegion.createDestination method would be changed from abstract to an 
 implementation that uses DestinationFactory to create a destination.
   BrokerService could be changed to use DestinationFactory if one is 
 provided. If none is provided, it will create a DestinationFactory 
 implementation that instantiates Queue and Topic using PersistenceAdapter as 
 it does currently. Hence, full backwards compatibility will be maintained.
 Patch is attached.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
classpath.  Please delete your
~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and try
again.

Jeff

Rick McGuire wrote:
 Added as an attachment, since Thunderbird's choking on the cut and paste
 for some reason.  I'm not sure there's anything useful in the additional
 detail.
 
 Rick


Re: Strange build error on trunk

2006-08-25 Thread Rick McGuire

Jeff Genender wrote:

Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
classpath.  Please delete your
~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and try
again.

  
Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin 
directory after completion.


Rick



Jeff

Rick McGuire wrote:
  

Added as an attachment, since Thunderbird's choking on the cut and paste
for some reason.  I'm not sure there's anything useful in the additional
detail.

Rick



  




Re: servicemix-http and normalization

2006-08-25 Thread Alex Boisvert

Hi all,

To follow-up on prior discussion around normalization, I've now created 
a patch https://issues.apache.org/activemq/browse/SM-557 [1] that 
provides WSDL 1.1 normalization for the servicemix-http component.   
More specifically, the code provides a set of reusable classes for 
converting between SOAP 1.1 messages and JBI messages using WSDL 1.1 
definitions.  This code now sits in the servicemix-soap shared library 
and I should mention that it's fairly strict about WS-I BasicProfile 
compliance to reduce complexity and encourage people to write 
interoperable service definitions.


I have not implemented a flag to turn normalization on/off.   It should 
be pretty simple but I figured I'd throw it out there to see how people 
want to configure this (e.g. in the WSDL?)


Feedback on the patch itself or the configuration aspect would be 
appreciated.


cheers,
alex

[1] https://issues.apache.org/activemq/browse/SM-557



[jira] Created: (SM-557) WSDL 1.1 message normalization for the servicemix-http component

2006-08-25 Thread Alex Boisvert (JIRA)
WSDL 1.1 message normalization for the servicemix-http component


 Key: SM-557
 URL: https://issues.apache.org/activemq/browse/SM-557
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-http, servicemix-soap
Affects Versions: 3.0-M2
Reporter: Alex Boisvert
 Fix For: 3.0-M3
 Attachments: normalization-diff.zip

The attached patch provides WSDL 1.1 message normalization for the 
servicemix-http component and provides a set of reusable classes for converting 
between SOAP 1.1 messages and JBI messages using WSDL 1.1 definitions (assuming 
WS-I BasicProfile compliance)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
And what happens when you use 1.4.4 and you add the jasper-compiler-jdt
as a dependency to the pom?

Jeff

Rick McGuire wrote:
 Jeff Genender wrote:
 Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
 classpath.  Please delete your
 ~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and try
 again.

   
 Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin
 directory after completion.
 
 Rick
 
 
 Jeff

 Rick McGuire wrote:
  
 Added as an attachment, since Thunderbird's choking on the cut and paste
 for some reason.  I'm not sure there's anything useful in the additional
 detail.

 Rick
 

   


Re: Geronimo site POC using Confluence Autoexport

2006-08-25 Thread Jeff Turner
On Fri, Aug 25, 2006 at 01:25:25AM -0700, Jason Dillon wrote:
 Okay, I think that the sync that Jeff has setup will allow me to move  
 further on setting up the proof of concept, taking GMOxSITE and  
 GMOxKB and making them into something suitable to be used for http:// 
 geronimo.apache.org

FWIW, http://cwiki.apache.org/ is now being mirrored to
http://people.apache.org/~jefft/confluence/ on every autoexport. There's
a 'lastupdated' file that can be polled to check for updates.

I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index. Unfortunately tabs
('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so I'm not
sure why - needs some investigation.

Discussions are proceeding on infrastructure@ as to how to get generated
HTML into SVN and thus to the live site. It's painful doing trailblazing
but the end goal seems worthwhile. I imagine many other projects will be
interested in this kind of system.


--Jeff

 --jason
 
 
 On Aug 24, 2006, at 3:02 PM, David Blevins wrote:
 
 
  On Aug 24, 2006, at 11:27 AM, Jason Dillon wrote:
  Sounds like Jeff Turner may be willing to help us solve this  
  problem... pending more details.
 
  Thanks Jeff and Jason!  Hey you guys let me know if I can help.  I  
  open sources a stream editing library with the intention of  
  confluence munging, just Peir beat me to it :)  But doing things  
  like munging urls is a piece of cake:
 
  http://fisheye.codehaus.org/browse/swizzle/trunk/swizzle-stream/src/ 
  test/java/org/codehaus/swizzle/stream/ 
  ResolveUrlInputStreamTest.java?r=23
 
  I could crank something out in short order if you give me an idea  
  of what things need to be updated.
 
  -David
 
  --jason
 
 
  On Aug 23, 2006, at 10:17 PM, David Blevins wrote:
 
  Assuming you did have access to the box, what steps would be  
  required to get things setup?  I know I'm asking an unnatural  
  question as I typically start my thinking while staring at the  
  command prompt and type commands iteratively till things work.   
  But I'm just thinking if we could maybe figure that out, we could  
  work with someone who does have access.
 
  I'd also like to use this for GBuild and OpenEJB, so I'm keen on  
  seeing it solved.
 
  -David
 
  On Aug 23, 2006, at 5:39 PM, Jason Dillon wrote:
 
  So, it looks like there is going to need some convincing to get  
  access to the exported content, so that we can post process and  
  massage these spaces into our main website.
 
  I'm not even sure that it is going to be worth the effort to try  
  and convince Apache infra that we need the access.  Seems like  
  they are only willing to give accounts on systems to Apache  
  members.
 
  So, I wonder if we could just run our own Confluence instance on  
  our zone, only use it to author, then export the content,  
  massage and then svn ci.  I guess we could also do the same by  
  moving the spaces to goopen.org too, which will provide us the  
  required access to implement the site that we all want to  
  implement.
 
  I'm frustrated... we now have a Confluence instance on ASF, but  
  we can't really use it to produce the results we want... unless  
  you want to see http://geronimo.apache.org become a set of  
  http://cwiki.apache.org* URs... which I find very distasteful.
 
  There might be some way to configure httpd to rewrite urls so  
  that http://cwiki.apache.org/GMOxSITE looks like http:// 
  geronimo.apache.org and that http://cwiki.apache.org/GMOxKB  
  looks like http://cwiki.apache.org/GMOxKB, etc... but I wonder  
  if that is really worth all of the effort.
 
  I guess we could use wget to grab the entire http:// 
  cwiki.apache.org/GMOxSITE and then massage and check in... but  
  that is terribly inefficient and add more unwanted time lapse  
  between updating content to making the content live.
 
  So, in short... I can't do anything related to making GMOxSITE  
  the official website until there is a way to get access to the  
  exported content, or get the httpd configuration changed for our  
  vhost.
 
  I feel like we have a spiffy new Ferrari that we can only drive  
  at 5 mph... and as soon as you hit 6 mph it starts to hit you on  
  the head.
 
  :-(
 
  --jason
 
 
 
 


Re: Strange build error on trunk

2006-08-25 Thread Rick McGuire

Jeff Genender wrote:

And what happens when you use 1.4.4 and you add the jasper-compiler-jdt
as a dependency to the pom?
  
I'm sorry, I not sure I understood that last bit.  Where do I add the 
jasper-compiler-jdt (and which version?).


Rick


Jeff

Rick McGuire wrote:
  

Jeff Genender wrote:


Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
classpath.  Please delete your
~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and try
again.

  
  

Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin
directory after completion.

Rick




Jeff

Rick McGuire wrote:
 
  

Added as an attachment, since Thunderbird's choking on the cut and paste
for some reason.  I'm not sure there's anything useful in the additional
detail.

Rick


  
  


  




Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-08-25 Thread Mario Ruebsam

Paul McMahan wrote:

I don't necessarily think its a requirement for the site to run on
Apache hardware. But if the Geronimo dev community thinks this is
important then I'm definitely game.  All of the software currently
used to run the site is free/open source -- Apache HTTP, Joomla, PHP,
MySQL, SimpleForum, and xtdratings.  But I am looking into some
low-end commercial software to replace SimpleForum and xtdratings
since I'm really starting to feel the pain of you get what you pay
for :-)   


Take a look, at Invision Power Board
http://www.invisionpower.com/ip.dynamic/products/board/index.html

The best I know for an affordable price. The SimpleForum is sometimes
really a pain even for small forums.

Thanks,
Mario


Re: Geronimo site POC using Confluence Autoexport

2006-08-25 Thread Dain Sundstrom

On Aug 25, 2006, at 9:24 AM, Jeff Turner wrote:


I installed the Composition plugin. See test at
http://cwiki.apache.org/confluence/display/test/Index.  
Unfortunately tabs

('cards') don't work on the autoexported HTML at
http://cwiki.apache.org/test/. The CSS and JS URLs are correct so  
I'm not

sure why - needs some investigation.


That is super cool and exactly what I needed the other day.  I was  
writing some docs for xbean-spring and wanted to show a few different  
styles of configuration for the same example.  Stacking the examples  
would have been a much better layout.  Instead I ended up with a very  
long page.


Discussions are proceeding on infrastructure@ as to how to get  
generated
HTML into SVN and thus to the live site. It's painful doing  
trailblazing
but the end goal seems worthwhile. I imagine many other projects  
will be

interested in this kind of system.


Thanks for all the help Jeff.

-dain


Re: servicemix-http and normalization

2006-08-25 Thread Guillaume Nodet

Great, thx a lot.
I will take a look asap.

On 8/25/06, Alex Boisvert [EMAIL PROTECTED] wrote:


Hi all,

To follow-up on prior discussion around normalization, I've now created
a patch https://issues.apache.org/activemq/browse/SM-557 [1] that
provides WSDL 1.1 normalization for the servicemix-http component.
More specifically, the code provides a set of reusable classes for
converting between SOAP 1.1 messages and JBI messages using WSDL 1.1
definitions.  This code now sits in the servicemix-soap shared library
and I should mention that it's fairly strict about WS-I BasicProfile
compliance to reduce complexity and encourage people to write
interoperable service definitions.

I have not implemented a flag to turn normalization on/off.   It should
be pretty simple but I figured I'd throw it out there to see how people
want to configure this (e.g. in the WSDL?)

Feedback on the patch itself or the configuration aspect would be
appreciated.

cheers,
alex

[1] https://issues.apache.org/activemq/browse/SM-557






--
Cheers,
Guillaume Nodet


[jira] Created: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector

2006-08-25 Thread james strachan (JIRA)
allow messages to be copied, moved or deleted using a JMS selector
--

 Key: AMQ-896
 URL: https://issues.apache.org/activemq/browse/AMQ-896
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector

2006-08-25 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-896?page=comments#action_36855 ] 

james strachan commented on AMQ-896:


Providing helper methods on the Queue or the MBeans

 allow messages to be copied, moved or deleted using a JMS selector
 --

 Key: AMQ-896
 URL: https://issues.apache.org/activemq/browse/AMQ-896
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (XBEAN-47) The generated XSDs do not contain any documentation while the html / wiki pages do

2006-08-25 Thread Guillaume Nodet (JIRA)
 [ http://issues.apache.org/jira/browse/XBEAN-47?page=all ]

Guillaume Nodet closed XBEAN-47.


Resolution: Fixed

Author: gnodet
Date: Fri Aug 25 10:22:13 2006
New Revision: 436863

URL: http://svn.apache.org/viewvc?rev=436863view=rev
Log:
XBEAN-47: Add missing docs to the generated xsd

Modified:
   
geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/generator/XsdGenerator.java


 The generated XSDs do not contain any documentation while the html / wiki 
 pages do
 --

 Key: XBEAN-47
 URL: http://issues.apache.org/jira/browse/XBEAN-47
 Project: XBean
  Issue Type: Bug
  Components: spring
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.6




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (XBEAN-48) When using an array of a know type, the generated xsd does not reference the generate types

2006-08-25 Thread Guillaume Nodet (JIRA)
When using an array of a know type, the generated xsd does not reference the 
generate types
---

 Key: XBEAN-48
 URL: http://issues.apache.org/jira/browse/XBEAN-48
 Project: XBean
  Issue Type: Bug
  Components: spring
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.6




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (XBEAN-48) When using an array of a know type, the generated xsd does not reference the generate types

2006-08-25 Thread Guillaume Nodet (JIRA)
 [ http://issues.apache.org/jira/browse/XBEAN-48?page=all ]

Guillaume Nodet closed XBEAN-48.


Resolution: Fixed

Author: gnodet
Date: Fri Aug 25 10:31:58 2006
New Revision: 436867

URL: http://svn.apache.org/viewvc?rev=436867view=rev
Log:
XBEAN-48: When using an array of a know type, the generated xsd does not 
reference the generate

Modified:
   
geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/generator/Utils.java
   
geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/generator/XsdGenerator.java


 When using an array of a know type, the generated xsd does not reference the 
 generate types
 ---

 Key: XBEAN-48
 URL: http://issues.apache.org/jira/browse/XBEAN-48
 Project: XBean
  Issue Type: Bug
  Components: spring
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.6




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
Add it to your web app pom. use version 5.5.15.

Jeff

Rick McGuire wrote:
 Jeff Genender wrote:
 And what happens when you use 1.4.4 and you add the jasper-compiler-jdt
 as a dependency to the pom?
   
 I'm sorry, I not sure I understood that last bit.  Where do I add the
 jasper-compiler-jdt (and which version?).
 
 Rick
 
 Jeff

 Rick McGuire wrote:
  
 Jeff Genender wrote:

 Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
 classpath.  Please delete your
 ~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and try
 again.

 
 Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin
 directory after completion.

 Rick



 Jeff

 Rick McGuire wrote:
  
  
 Added as an attachment, since Thunderbird's choking on the cut and
 paste
 for some reason.  I'm not sure there's anything useful in the
 additional
 detail.

 Rick
 
 

   


Re: scout 0.5 jar still has bunk log4j.properties

2006-08-25 Thread Jason Dillon
Thanks, not hard ETA... sooner the better.  I don't know if this  
affects 1.1.x, but it does affect 1.2.


Its an easy fix... just remove the log4j.properties... or comment the  
DEBUG.  I prefer the first option though.


--jason


On Aug 25, 2006, at 4:01 AM, Davanum Srinivas wrote:


Jason,

Let me check.. is there a ETA? when we need this by?

-- dims

On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote:

Do we have any friends at the ws project that can re-release scout
0.5 without a log4j.properties file?

Or else... I think we need to add some magic to the build to
download, strip that file and then re-install the dependency to
remove the bunk log4j.properties file.

--jason




--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service  
Developers)




Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon
Jeff, do you have any idea why some folks don't see this problem?   
And more so why it just started?


--jason


On Aug 25, 2006, at 10:47 AM, Jeff Genender wrote:


Add it to your web app pom. use version 5.5.15.

Jeff

Rick McGuire wrote:

Jeff Genender wrote:
And what happens when you use 1.4.4 and you add the jasper- 
compiler-jdt

as a dependency to the pom?


I'm sorry, I not sure I understood that last bit.  Where do I add the
jasper-compiler-jdt (and which version?).

Rick


Jeff

Rick McGuire wrote:


Jeff Genender wrote:


Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
classpath.  Please delete your
~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory  
and try

again.



Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin
directory after completion.

Rick




Jeff

Rick McGuire wrote:


Added as an attachment, since Thunderbird's choking on the cut  
and

paste
for some reason.  I'm not sure there's anything useful in the
additional
detail.

Rick










Re: Where to put new Callback and CallbackHandler classes

2006-08-25 Thread Sepand M

It does since the CertificateAuthenticationBroker I'm making will need
to use the CertificateCallbacks.
I have put the classes in jaas (core already has a dependancy on jaas
so that's not a problem). I do think the other callbacks should go in
jass now, but I don't want to touch your stuff since I'm not sure
when/if you will accept my patch.

On 8/24/06, James Strachan [EMAIL PROTECTED] wrote:

On 8/24/06, Sepand M [EMAIL PROTECTED] wrote:
 Hi,

 For certificate authentication, I'm adding two classes:
 JaasCertificateCallbackHandler and CertificateCallback.
 I've placed these classes in activemq-core along with
 JaasCredentialCallback, etc. The problem is that activemq-jaas needs
 access to these classes (since I have a new LoginModule that uses
 them) and maven complains that we can't have a circular dependency
 between activemq-core and activemq-jaas.
 So, should I move these classes into activemq-jass? Should I move all
 Callback classes to activemq-jaas? Any other way of doing this?

I'd put them in the module which uses them, so activemq-jaas sounds
about right. Does activemq-core need to access them?
--

James
---
http://radio.weblogs.com/0112098/



[jira] Created: (GERONIMO-2353) Reduce the number of places where CORBA config parameters are specified.

2006-08-25 Thread Rick McGuire (JIRA)
Reduce the number of places where CORBA config parameters are specified.


 Key: GERONIMO-2353
 URL: http://issues.apache.org/jira/browse/GERONIMO-2353
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: CORBA
Affects Versions: 1.2
Reporter: Rick McGuire
 Assigned To: Rick McGuire
 Fix For: 1.2


The CORBA configuration situation is a bit of a mess currently, with 
information scattered over multiple locations.  Much of this information is ORB 
implementation specific, which makes it very difficult to switch between ORBs.  
For example, various CORBABean configurations manage bits of the ORB 
configuration using:

1)  The name of an ORB config adapter class. 
2)  ORB.init() properties specified on the CorbaBean declaration
3)  ORB.init() arguments specified on the 
4)  CORBASystemProperties values that must be set in System.properties before 
initializing the ORB.  

2), 3), and 4) above are values that are handled in a non-portable fashion, and 
are scattered over seemingly unreleated portions of the configs.

A better solution would be to have GBeans that encapsulate the knowledge about 
what ORB is going to be used as the server and pull these pieces together into 
a simple GBean declaration, which would make it much easier to switch between 
ORB implementations.  The ORB config adapter seems tailor made for this.  It 
just needs to be turned into a GBean rather than a classname argument to 
CorbaBean and CSSBean. 


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn
hmmm  I get a different error now which seems unrelated.  I'm 
failing trying to build openejb-deployer because it can't fulfill the 
builder dependency.


Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache-snapshots 
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading: 
http://snapshots.repository.codehaus.org/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository codehaus-snapshots 
(http://snapshots.repository.codehaus.org)
Downloading: 
http://people.apache.org/maven-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache.snapshots 
(http://people.apache.org/maven-snapshot-repository)
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

Missing:
--
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.openejb 
-DartifactId=openejb-builder \

  -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

--
1 required artifact is missing.

for artifact:
  org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/maven-snapshot-repository),
  codehaus (http://repository.codehaus.org),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)

Rick McGuire wrote:

Well, the result is different, but still a build failure:

[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Errors found during compilation.
[INFO] 


[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Errors found 
during compilation.
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java 
:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java 
:306)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java 
:140)

   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

   at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:324)
   at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

   at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException : Errors found 
during compilation.
   at 
org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:257)
   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) 


   ... 16 more
[INFO] 


[INFO] Total time: 6 minutes 6 seconds
[INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO] 


[EMAIL PROTECTED] 1.2]$


Jeff Genender wrote:


I just released a new version 1.4.5-SNAPSHOT of the jspc plugin (just
now).  

[jira] Updated: (AMQ-837) add a moveTo() method on the QueueViewMBean for doing dead letter queue processing

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-837?page=all ]

james strachan updated AMQ-837:
---

Component/s: Broker
 (was: CMS (C++ client))
   Assignee: james strachan

updated component

 add a moveTo() method on the QueueViewMBean for doing dead letter queue 
 processing
 --

 Key: AMQ-837
 URL: https://issues.apache.org/activemq/browse/AMQ-837
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Where to put new Callback and CallbackHandler classes

2006-08-25 Thread James Strachan

On 8/25/06, Sepand M [EMAIL PROTECTED] wrote:

It does since the CertificateAuthenticationBroker I'm making will need
to use the CertificateCallbacks.
I have put the classes in jaas (core already has a dependancy on jaas
so that's not a problem). I do think the other callbacks should go in
jass now, but I don't want to touch your stuff since I'm not sure
when/if you will accept my patch.


Since its all JAAS/security related and to avoid recursive
dependencies, how about putting the CertificateAuthenticationBroker in
the activemq-jaas module too? The idea behind activemq-core is that it
has as few dependencies as possible.

Which reminds me - it might be nice to remove the dependency on
activeio and make that an optional module.
--

James
---
http://radio.weblogs.com/0112098/


Re: Strange build error on trunk

2006-08-25 Thread Jason Dillon

Try `bootstrap openejb2`

--jason


On Aug 25, 2006, at 11:24 AM, Joe Bohn wrote:

hmmm  I get a different error now which seems unrelated.  I'm  
failing trying to build openejb-deployer because it can't fulfill  
the builder dependency.


Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2- 
SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache-snapshots  
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/openejb/ 
openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository codehaus-snapshots  
(http://snapshots.repository.codehaus.org)
Downloading: http://people.apache.org/maven-snapshot-repository/org/ 
openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache.snapshots  
(http://people.apache.org/maven-snapshot-repository)
[INFO]  
-- 
--

[ERROR] BUILD ERROR
[INFO]  
-- 
--

[INFO] Failed to resolve artifact.

Missing:
--
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.openejb - 
DartifactId=openejb-builder \

  -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

--
1 required artifact is missing.

for artifact:
  org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/maven-snapshot- 
repository),

  codehaus (http://repository.codehaus.org),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot- 
repository),

  codehaus-snapshots (http://snapshots.repository.codehaus.org)

Rick McGuire wrote:

Well, the result is different, but still a build failure:
[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO]  
- 
---

[ERROR] BUILD ERROR
[INFO]  
- 
---

[INFO] Errors found during compilation.
[INFO]  
- 
---

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Errors  
found during compilation.
   at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
(DefaultLifecycleExecutor.java:559)at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi 
fecycle(DefaultLifecycleExecutor.java :475)
   at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal 
(DefaultLifecycleExecutor.java:454)at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan 
dleFailures(DefaultLifecycleExecutor.java :306)
   at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen 
ts(DefaultLifecycleExecutor.java:273)at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute 
(DefaultLifecycleExecutor.java :140)
   at org.apache.maven.DefaultMaven.doExecute 
(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: 
115)

   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:39)at  
sun.reflect.DelegatingMethodAccessorImpl.invoke  
(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:324)
   at org.codehaus.classworlds.Launcher.launchEnhanced 
(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch (Launcher.java: 
255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode 
(Launcher.java:430)at  
org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException : Errors  
found during compilation.
   at org.codehaus.mojo.jspc.AbstractJspcMojo.execute 
(AbstractJspcMojo.java:257)
   at org.apache.maven.plugin.DefaultPluginManager.executeMojo 
(DefaultPluginManager.java:412)at  
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals 
(DefaultLifecycleExecutor.java:534)... 16 more
[INFO]  
- 
---

[INFO] Total time: 6 minutes 6 seconds
[INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO]  

[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all

2006-08-25 Thread Jason Dillon (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12430574
 ] 

Jason Dillon commented on GERONIMO-2332:


I am going to verify and apply GERONIMO-2332-trunk-v2.patch to server/trunk as 
it overlaps with some of the restructure work to use the standard layout.

 RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a 
 spec module so we don't need the schemas in svn at all
 

 Key: GERONIMO-2332
 URL: http://issues.apache.org/jira/browse/GERONIMO-2332
 Project: Geronimo
  Issue Type: RTC
  Security Level: public(Regular issues) 
  Components: specs
Affects Versions: 1.2, 1.1.1, 1.1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.2, 1.1.1, 1.1.2

 Attachments: GERONIMO-2332-1.1-openejb-v2.patch, 
 GERONIMO-2332-1.1-v2.patch, GERONIMO-2332-1.1.patch, 
 GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk-v2.patch, 
 GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, 
 geronimo-schema_1.4_spec-src.zip


 See GERONIMO-2307.  It seems that the option with the least legal exposure is 
 to not distribute and sun schema files and not have any in our svn.  This is 
 a proposed spec module that uses a m2 profile to pull the schemas from suns 
 website (where they are freely available), run xmlbeans on them, and remove 
 the copies of the schemas that xmlbeasn helpfully tries to include in the 
 output.  We can then check this stuff into svn.
 A normal non-profile build then just builds these sources into a jar.  We can 
 replace the xmlbeans step in j2ee-schema with a geronimo dependency on this 
 new spec jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
No...not at all...its been stable and working for many.  There is an
open JIRA on one guy who has a problem with Linux...but other than
that...no problems :/

Jason Dillon wrote:
 Jeff, do you have any idea why some folks don't see this problem?  And
 more so why it just started?
 
 --jason
 
 
 On Aug 25, 2006, at 10:47 AM, Jeff Genender wrote:
 
 Add it to your web app pom. use version 5.5.15.

 Jeff

 Rick McGuire wrote:
 Jeff Genender wrote:
 And what happens when you use 1.4.4 and you add the jasper-compiler-jdt
 as a dependency to the pom?

 I'm sorry, I not sure I understood that last bit.  Where do I add the
 jasper-compiler-jdt (and which version?).

 Rick

 Jeff

 Rick McGuire wrote:

 Jeff Genender wrote:

 Are you using 1.4.5-SNAPSHOT?  I do not see your tools.jar in your
 classpath.  Please delete your
 ~/.m2/reporitory/org/codehaus/mojo/jspc-maven-plugin directory and
 try
 again.


 Same result.  Only the 1.4.5-SNAPSHOT is in the jspc-maven-plugin
 directory after completion.

 Rick



 Jeff

 Rick McGuire wrote:


 Added as an attachment, since Thunderbird's choking on the cut and
 paste
 for some reason.  I'm not sure there's anything useful in the
 additional
 detail.

 Rick






Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn
BTW, I should have been more specific.  This is with the jspc 
1.4.3-SNAPSHOT plugin Jeff recommended.


Joe


Joe Bohn wrote:
hmmm  I get a different error now which seems unrelated.  I'm 
failing trying to build openejb-deployer because it can't fulfill the 
builder dependency.


Downloading: 
http://people.apache.org/repo/m2-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar 

[WARNING] Unable to get resource from repository apache-snapshots 
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading: 
http://snapshots.repository.codehaus.org/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar 

[WARNING] Unable to get resource from repository codehaus-snapshots 
(http://snapshots.repository.codehaus.org)
Downloading: 
http://people.apache.org/maven-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar 

[WARNING] Unable to get resource from repository apache.snapshots 
(http://people.apache.org/maven-snapshot-repository)
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

Missing:
--
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.openejb 
-DartifactId=openejb-builder \

  -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

--
1 required artifact is missing.

for artifact:
  org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/maven-snapshot-repository),
  codehaus (http://repository.codehaus.org),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)

Rick McGuire wrote:


Well, the result is different, but still a build failure:

[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Errors found during compilation.
[INFO] 


[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Errors found 
during compilation.
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java 
:475)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java 
:306)
   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java 
:140)

   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 

   at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:25)

   at java.lang.reflect.Method.invoke(Method.java:324)
   at 
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)

   at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
   at 
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException : Errors 
found during compilation.
   at 
org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:257) 

   at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) 

   at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) 


   ... 16 more
[INFO] 


[INFO] Total time: 6 minutes 6 seconds
[INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO] 

Re: Where to put new Callback and CallbackHandler classes

2006-08-25 Thread Sepand M

Well there's already a JaasAuthenticationBroker in core, shouldn't the
JaasCertificateAuthenticationBroker (that's the full name) be in the
same package?
Also, would I still be able to use it easily (just by specifying it in
the config xml) if I move it to the jaas module?

On 8/25/06, James Strachan [EMAIL PROTECTED] wrote:

On 8/25/06, Sepand M [EMAIL PROTECTED] wrote:
 It does since the CertificateAuthenticationBroker I'm making will need
 to use the CertificateCallbacks.
 I have put the classes in jaas (core already has a dependancy on jaas
 so that's not a problem). I do think the other callbacks should go in
 jass now, but I don't want to touch your stuff since I'm not sure
 when/if you will accept my patch.

Since its all JAAS/security related and to avoid recursive
dependencies, how about putting the CertificateAuthenticationBroker in
the activemq-jaas module too? The idea behind activemq-core is that it
has as few dependencies as possible.

Which reminds me - it might be nice to remove the dependency on
activeio and make that an optional module.
--

James
---
http://radio.weblogs.com/0112098/



Re: Strange build error on trunk

2006-08-25 Thread Jeff Genender
1.4.5-SNAPSHOT

Joe Bohn wrote:
 BTW, I should have been more specific.  This is with the jspc
 1.4.3-SNAPSHOT plugin Jeff recommended.
 
 Joe
 
 
 Joe Bohn wrote:
 hmmm  I get a different error now which seems unrelated.  I'm
 failing trying to build openejb-deployer because it can't fulfill the
 builder dependency.

 Downloading:
 http://people.apache.org/repo/m2-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

 [WARNING] Unable to get resource from repository apache-snapshots
 (http://people.apache.org/repo/m2-snapshot-repository)
 Downloading:
 http://snapshots.repository.codehaus.org/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

 [WARNING] Unable to get resource from repository codehaus-snapshots
 (http://snapshots.repository.codehaus.org)
 Downloading:
 http://people.apache.org/maven-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

 [WARNING] Unable to get resource from repository apache.snapshots
 (http://people.apache.org/maven-snapshot-repository)
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Failed to resolve artifact.

 Missing:
 --
 1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

   Try downloading the file manually from the project website.

   Then, install it using the command:
   mvn install:install-file -DgroupId=org.openejb
 -DartifactId=openejb-builder \
   -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

   Path to dependency:
 1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
 2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

 --
 1 required artifact is missing.

 for artifact:
   org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

 from the specified remote repositories:
   central (http://repo1.maven.org/maven2),
   apache.snapshots (http://people.apache.org/maven-snapshot-repository),
   codehaus (http://repository.codehaus.org),
   apache-snapshots
 (http://people.apache.org/repo/m2-snapshot-repository),
   codehaus-snapshots (http://snapshots.repository.codehaus.org)

 Rick McGuire wrote:

 Well, the result is different, but still a build failure:

 [INFO] [jspc:compile {execution: jspc}]
 [INFO] Compiling new java files...
 [INFO]
 
 [ERROR] BUILD ERROR
 [INFO]
 
 [INFO] Errors found during compilation.
 [INFO]
 
 [INFO] Trace
 org.apache.maven.lifecycle.LifecycleExecutionException: Errors found
 during compilation.
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)

at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java
 :475)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)

at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java
 :306)
at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)

at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
 :140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke
 (DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
 org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
at
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)   
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 Caused by: org.apache.maven.plugin.MojoExecutionException : Errors
 found during compilation.
at
 org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:257)

at
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)

at
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)

... 16 more
 [INFO]
 
 [INFO] Total time: 6 minutes 6 seconds
 [INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
 [INFO] Final 

[jira] Resolved: (AMQ-837) add a moveTo() method on the QueueViewMBean for doing dead letter queue processing

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-837?page=all ]

james strachan resolved AMQ-837.


Fix Version/s: 4.1
   Resolution: Fixed

See 
http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/jmx/QueueViewMBean.java?revision=436899view=markup

 add a moveTo() method on the QueueViewMBean for doing dead letter queue 
 processing
 --

 Key: AMQ-837
 URL: https://issues.apache.org/activemq/browse/AMQ-837
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




JMX MBean changes to make it easier to manage Queues

2006-08-25 Thread James Strachan

As part of fixing AMQ-896 and AMQ-837 I tidied up the Queue /
QueueView / QueueViewMBean code a little to make it easier to work
with queues via Java / JMX.

I've added support for removing, moving and copying messages by
selectors, with an optional maximum number of messages so that you can
do things in smaller batches if need be. There are some test cases in
the MBeanTest if you want to see them in action - or surf the
QueueViewMBean javadoc when it gets regenerated to see the new methods
available.

It'd be nice to use these new methods in the activemq-web-console to
allow easier moving, copying, removal etc.

e.g. to remove messages we could move them to a 'trash bin' queue.

If you can't wait for the new javadoc you could surf the new methods
on the MBean
http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/jmx/QueueViewMBean.java?revision=436899view=markup
--

James
---
http://radio.weblogs.com/0112098/


[jira] Resolved: (AMQ-896) allow messages to be copied, moved or deleted using a JMS selector

2006-08-25 Thread james strachan (JIRA)
 [ https://issues.apache.org/activemq/browse/AMQ-896?page=all ]

james strachan resolved AMQ-896.


Resolution: Fixed

For details of the new methods see

http://svn.apache.org/viewvc/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/broker/jmx/QueueViewMBean.java?revision=436899view=markup

 allow messages to be copied, moved or deleted using a JMS selector
 --

 Key: AMQ-896
 URL: https://issues.apache.org/activemq/browse/AMQ-896
 Project: ActiveMQ
  Issue Type: New Feature
  Components: Broker
Reporter: james strachan
 Assigned To: james strachan
 Fix For: 4.1




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn

Yes, I'm using 1.4.5-SNAPSHOT (typo in my note).

Joe

Jeff Genender wrote:

1.4.5-SNAPSHOT

Joe Bohn wrote:


BTW, I should have been more specific.  This is with the jspc
1.4.3-SNAPSHOT plugin Jeff recommended.

Joe


Joe Bohn wrote:


hmmm  I get a different error now which seems unrelated.  I'm
failing trying to build openejb-deployer because it can't fulfill the
builder dependency.

Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

[WARNING] Unable to get resource from repository apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading:
http://snapshots.repository.codehaus.org/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

[WARNING] Unable to get resource from repository codehaus-snapshots
(http://snapshots.repository.codehaus.org)
Downloading:
http://people.apache.org/maven-snapshot-repository/org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar

[WARNING] Unable to get resource from repository apache.snapshots
(http://people.apache.org/maven-snapshot-repository)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Failed to resolve artifact.

Missing:
--
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

 Try downloading the file manually from the project website.

 Then, install it using the command:
 mvn install:install-file -DgroupId=org.openejb
-DartifactId=openejb-builder \
 -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

 Path to dependency:
   1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
   2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

--
1 required artifact is missing.

for artifact:
 org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

from the specified remote repositories:
 central (http://repo1.maven.org/maven2),
 apache.snapshots (http://people.apache.org/maven-snapshot-repository),
 codehaus (http://repository.codehaus.org),
 apache-snapshots
(http://people.apache.org/repo/m2-snapshot-repository),
 codehaus-snapshots (http://snapshots.repository.codehaus.org)

Rick McGuire wrote:



Well, the result is different, but still a build failure:

[INFO] [jspc:compile {execution: jspc}]
[INFO] Compiling new java files...
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Errors found during compilation.
[INFO]

[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Errors found
during compilation.
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)

  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java
:475)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)

  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java
:306)
  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)

  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java
:140)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

  at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
  at java.lang.reflect.Method.invoke(Method.java:324)
  at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
  at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
  at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)   
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

Caused by: org.apache.maven.plugin.MojoExecutionException : Errors
found during compilation.
  at
org.codehaus.mojo.jspc.AbstractJspcMojo.execute(AbstractJspcMojo.java:257)

  at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)

  at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)

  ... 16 more
[INFO]

[INFO] Total time: 6 minutes 6 seconds
[INFO] Finished at: Fri Aug 25 10:55:50 EDT 2006
[INFO] Final Memory: 43M/63M
[INFO]

Re: Where to put new Callback and CallbackHandler classes

2006-08-25 Thread James Strachan

On 8/25/06, Sepand M [EMAIL PROTECTED] wrote:

Well there's already a JaasAuthenticationBroker in core, shouldn't the
JaasCertificateAuthenticationBroker (that's the full name) be in the
same package?


Sure


Also, would I still be able to use it easily (just by specifying it in
the config xml) if I move it to the jaas module?


Yes.; though we might have to hack the xbean-plugin configuration in
the activemq-core module to also search other modules to keep them all
in the same namespace as right now the xbean plugin isn't too great at
creating a single schema  document reference for multiple modules in
a single namespace.

FWIW I'd like activemq-core, activemq-ra, activemq-jaas and maybe
activemq-optional all to be in the same namespace  schema 
reference.

e.g. right now the activemq-ra stuff is in a different namespace; when
its only a couple of elements; we really should unify them all
together.
--

James
---
http://radio.weblogs.com/0112098/


Re: Strange build error on trunk

2006-08-25 Thread Joe Bohn

Here's what I see when building openejb2:


log4j: Finished configuring.
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 14.939 sec
Running org.openejb.deployment.EjbJarModuleDeploymentTest
Retrieving document at 'META-INF/wsdl/test-ejb.wsdl'.
org.apache.maven.surefire.booter.SurefireExecutionException: 
org.openejb.deployment.EjbJarModuleDeploymentTest; nested exception is 
java.lang.reflec
ThrowableException: null; nested exception is 
org.apache.maven.surefire.testset.TestSetFailedException: 
org.openejb.deployment.EjbJarModuleDeploymen

d exception is java.lang.reflect.UndeclaredThrowableException: null
org.apache.maven.surefire.testset.TestSetFailedException: 
org.openejb.deployment.EjbJarModuleDeploymentTest; nested exception is 
java.lang.reflect.U

owableException: null
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.addError(Unknown Source)
at junit.framework.TestResult.addError(TestResult.java:36)
at junit.framework.TestResult.runProtected(TestResult.java:133)
at 
org.openejb.deployment.DeploymentTestSuite.run(DeploymentTestSuite.java:121)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)

at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
Caused by: java.lang.NoSuchMethodException: 
org.openejb.deployment.DeploymentTestSuite.getName()

at java.lang.Class.getMethod(Class.java:986)
at 
org.apache.maven.surefire.junit.TestListenerInvocationHandler.getStackTraceWriter(TestListenerInvocationHandler.java:171)
at 
org.apache.maven.surefire.junit.TestListenerInvocationHandler.handleAddError(TestListenerInvocationHandler.java:160)
at 
org.apache.maven.surefire.junit.TestListenerInvocationHandler.invoke(TestListenerInvocationHandler.java:134)

... 18 more
[INFO] 


[ERROR] BUILD FAILURE
[INFO] 


[INFO] There are test failures.

Jason Dillon wrote:

Try `bootstrap openejb2`

--jason


On Aug 25, 2006, at 11:24 AM, Joe Bohn wrote:

hmmm  I get a different error now which seems unrelated.  I'm  
failing trying to build openejb-deployer because it can't fulfill  the 
builder dependency.


Downloading: http://people.apache.org/repo/m2-snapshot-repository/ 
org/openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2- 
SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache-snapshots  
(http://people.apache.org/repo/m2-snapshot-repository)
Downloading: http://snapshots.repository.codehaus.org/org/openejb/ 
openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository codehaus-snapshots  
(http://snapshots.repository.codehaus.org)
Downloading: http://people.apache.org/maven-snapshot-repository/org/ 
openejb/openejb-builder/2.2-SNAPSHOT/openejb-builder-2.2-SNAPSHOT.jar
[WARNING] Unable to get resource from repository apache.snapshots  
(http://people.apache.org/maven-snapshot-repository)
[INFO]  
-- --

[ERROR] BUILD ERROR
[INFO]  
-- --

[INFO] Failed to resolve artifact.

Missing:
--
1) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.openejb - 
DartifactId=openejb-builder \

  -Dversion=2.2-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file

  Path to dependency:
1) org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT
2) org.openejb:openejb-builder:jar:2.2-SNAPSHOT

--
1 required artifact is missing.

for artifact:
  org.apache.geronimo.configs:openejb-deployer:car:1.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  

Endorsed dirs

2006-08-25 Thread Jason Dillon
Anyone know if the jars in the endorsed dir need to be added to the  
classpath... or will the jvm just suck up all *.jar files and load  
them anyways?


Was just wondering that if that is the case, and we add them to the  
classpath, does that just waste bytes for an unused classloader and/ 
or slow down the initial boot?


--jason


Re: Endorsed dirs

2006-08-25 Thread Dain Sundstrom

IIRC, they have to be on the classpath.

-dain

On Aug 25, 2006, at 12:21 PM, Jason Dillon wrote:

Anyone know if the jars in the endorsed dir need to be added to the  
classpath... or will the jvm just suck up all *.jar files and load  
them anyways?


Was just wondering that if that is the case, and we add them to the  
classpath, does that just waste bytes for an unused classloader and/ 
or slow down the initial boot?


--jason




[jira] Commented: (GERONIMO-2332) RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a spec module so we don't need the schemas in svn at all

2006-08-25 Thread Jason Dillon (JIRA)
[ 
http://issues.apache.org/jira/browse/GERONIMO-2332?page=comments#action_12430599
 ] 

Jason Dillon commented on GERONIMO-2332:


GERONIMO-2332-trunk-v2.patch has been applied in #436915

 RTC Put the generated xmlbeans files for the j2ee 1.4 schemas in svn in a 
 spec module so we don't need the schemas in svn at all
 

 Key: GERONIMO-2332
 URL: http://issues.apache.org/jira/browse/GERONIMO-2332
 Project: Geronimo
  Issue Type: RTC
  Security Level: public(Regular issues) 
  Components: specs
Affects Versions: 1.2, 1.1.1, 1.1.2
Reporter: David Jencks
 Assigned To: David Jencks
 Fix For: 1.2, 1.1.1, 1.1.2

 Attachments: GERONIMO-2332-1.1-openejb-v2.patch, 
 GERONIMO-2332-1.1-v2.patch, GERONIMO-2332-1.1.patch, 
 GERONIMO-2332-openejb-2.1.patch, GERONIMO-2332-trunk-v2.patch, 
 GERONIMO-2332-trunk.patch, geronimo-schema_1.4_spec-generated-src.zip, 
 geronimo-schema_1.4_spec-src.zip


 See GERONIMO-2307.  It seems that the option with the least legal exposure is 
 to not distribute and sun schema files and not have any in our svn.  This is 
 a proposed spec module that uses a m2 profile to pull the schemas from suns 
 website (where they are freely available), run xmlbeans on them, and remove 
 the copies of the schemas that xmlbeasn helpfully tries to include in the 
 output.  We can then check this stuff into svn.
 A normal non-profile build then just builds these sources into a jar.  We can 
 replace the xmlbeans step in j2ee-schema with a geronimo dependency on this 
 new spec jar.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re: Release XBean 2.6 ?

2006-08-25 Thread Dain Sundstrom

What is going on with 2.6?

I'd like to cut it and get on to 2.7.

-dain

On Aug 23, 2006, at 11:40 PM, James Strachan wrote:


On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'd like to release XBean 2.6 asap.


+1


I wanted to delay it until qdox 1.6 is out, which is now done.
Unfortunately, it is compiled with JDK 5, and thus i think we
can not use it, unless we all agree to put a JDK 5 dependency
at compilation time (as qdox is only used to generate the mapping).


Sounds fine to me.


There is also one JIRA in RTC about the classloader module, so
if people could vote on it ... Or should be delay it until next  
release ?


We could always release again after that classloader fix - but could
folks on the PMC take a look and vote please?

--

James
---
http://radio.weblogs.com/0112098/




Re: Reviewing and committing

2006-08-25 Thread Dain Sundstrom

Any comments?  Should I let this go?

-dain

On Aug 24, 2006, at 9:45 AM, Dain Sundstrom wrote:


I think David's comments on geronimo dev are spot on.

Begin forwarded message:


More thoughts on the where and how topic.

So far my thoughts on how; review to your satisfaction and +1,  
72 hour cut off.


As far as where 

I'm inclined to say at your discretion where the following are  
encouraged:

 - Significant new functionality
 - Significant changes
 - Patches from Contributors
 - Borderline fixes to a stable branch

Whether or not it merits RTC would be at your discretion.  It is to
your advantage in these situations because:

- Significant new functionality and Significant changes: It's a
   Get out of jail free card.  Having more people understand your
   code keeps you from spending all day on the user list.  You do
   support your code on the user list, right?

- Patches from Contributors: Getting three votes for your patches
   is not a bad way to, in time, get your three votes to be a
   committer.  Let's be clear, someone who commits all your patches
   with no review from others on the project isn't doing you any
   favors.  It's in your interest to push to get your votes on every
   patch.

- Borderline 'fixes' to a stable branch: It's a given you will
   think everything you want to put in a stable branch is important.
   But, is it a fix or is it a new feature?  If you think others may
   disagree, you may want to put it up for review or you may find
   yourself running the TCK all alone with no help.


Those are the advantages you stand to gain should you choose to  
use RTC for any of the above situations.  RTC is not the only way  
to get the above benefits, so it is at your discretion whether or  
not your situation merits it.


The only think I would change is the how section at the top.  I  
propose we follow this process:


To commit you need either 3 +1 (no -1s) from a committer or 72  
hours pass which ever happens first.  I suggest you complain loudly  
if you get no comments after 48 hours.  As above a +1 means you  
have reviewed to you


-dain





Re: Release XBean 2.6 ?

2006-08-25 Thread Guillaume Nodet

Jason is about to release genesis this weekend.
I' ll make the release on monday.

On 8/25/06, Dain Sundstrom [EMAIL PROTECTED] wrote:


What is going on with 2.6?

I'd like to cut it and get on to 2.7.

-dain

On Aug 23, 2006, at 11:40 PM, James Strachan wrote:

 On 8/22/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
 I'd like to release XBean 2.6 asap.

 +1

 I wanted to delay it until qdox 1.6 is out, which is now done.
 Unfortunately, it is compiled with JDK 5, and thus i think we
 can not use it, unless we all agree to put a JDK 5 dependency
 at compilation time (as qdox is only used to generate the mapping).

 Sounds fine to me.

 There is also one JIRA in RTC about the classloader module, so
 if people could vote on it ... Or should be delay it until next
 release ?

 We could always release again after that classloader fix - but could
 folks on the PMC take a look and vote please?

 --

 James
 ---
 http://radio.weblogs.com/0112098/





--
Cheers,
Guillaume Nodet


Re: Endorsed dirs

2006-08-25 Thread Jacek Laskowski

On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote:

Anyone know if the jars in the endorsed dir need to be added to the
classpath... or will the jvm just suck up all *.jar files and load
them anyways?


No, they needn't.

An excerpt from 'Endorsed Standards Classes Deployment'
(http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html):

Classes implementing newer versions of endorsed standards should be
placed in JAR files. The system property java.endorsed.dirs specifies
one or more directories that the Java runtime environment will search
for such JAR files. If more than one directory path is specified by
java.endorsed.dirs, they must be separated by File.pathSeparatorChar.
If no value is set for java.endorsed.dirs, then Sun Microsystem's
implementation of the Java 2 Platform looks for JAR files in a default
standard location:

   java-home\lib\endorsed  [Microsoft Windows]
   java-home/lib/endorsed  [Solaris or Linux]

Here java-home refers to the directory where the runtime software is
installed (which is the top-level directory of the Java 2 Runtime
Environment or the jre directory in the Java 2 SDK).

The Java runtime environment will use classes in such JAR files to
override the corresponding classes provided in the Java 2 Platform as
shipped by Sun.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl


Re: Reviewing and committing

2006-08-25 Thread Guillaume Nodet

On 8/24/06, Dain Sundstrom [EMAIL PROTECTED] wrote:


I think David's comments on geronimo dev are spot on.

Begin forwarded message:

 More thoughts on the where and how topic.

 So far my thoughts on how; review to your satisfaction and +1, 72
 hour cut off.

 As far as where 

 I'm inclined to say at your discretion where the following are
 encouraged:
  - Significant new functionality
  - Significant changes
  - Patches from Contributors
  - Borderline fixes to a stable branch

 Whether or not it merits RTC would be at your discretion.  It is to
 your advantage in these situations because:

 - Significant new functionality and Significant changes: It's a
Get out of jail free card.  Having more people understand your
code keeps you from spending all day on the user list.  You do
support your code on the user list, right?

 - Patches from Contributors: Getting three votes for your patches
is not a bad way to, in time, get your three votes to be a
committer.  Let's be clear, someone who commits all your patches
with no review from others on the project isn't doing you any
favors.  It's in your interest to push to get your votes on every
patch.

 - Borderline 'fixes' to a stable branch: It's a given you will
think everything you want to put in a stable branch is important.
But, is it a fix or is it a new feature?  If you think others may
disagree, you may want to put it up for review or you may find
yourself running the TCK all alone with no help.


 Those are the advantages you stand to gain should you choose to use
 RTC for any of the above situations.  RTC is not the only way to
 get the above benefits, so it is at your discretion whether or not
 your situation merits it.

The only think I would change is the how section at the top.  I
propose we follow this process:

To commit you need either 3 +1 (no -1s) from a committer or 72 hours
pass which ever happens first.  I suggest you complain loudly if you
get no comments after 48 hours.  As above a +1 means you have
reviewed to you

-dain




I agree with these guidelines.  Though, I would add that if there is an
ongoing
discussion about the patch / feature, the discussion should be settled
before
being able to commit without having to cast a -1 (even if the 72 hours
period
is off).


--
Cheers,
Guillaume Nodet


Re: Endorsed dirs

2006-08-25 Thread Jason Dillon
But, do they automatically make it onto the classpath?  This snip  
does not really lead me to believe that it does or does not.


--jason


On Aug 25, 2006, at 12:43 PM, Jacek Laskowski wrote:


On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote:

Anyone know if the jars in the endorsed dir need to be added to the
classpath... or will the jvm just suck up all *.jar files and load
them anyways?


No, they needn't.

An excerpt from 'Endorsed Standards Classes Deployment'
(http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html):

Classes implementing newer versions of endorsed standards should be
placed in JAR files. The system property java.endorsed.dirs specifies
one or more directories that the Java runtime environment will search
for such JAR files. If more than one directory path is specified by
java.endorsed.dirs, they must be separated by File.pathSeparatorChar.
If no value is set for java.endorsed.dirs, then Sun Microsystem's
implementation of the Java 2 Platform looks for JAR files in a default
standard location:

   java-home\lib\endorsed  [Microsoft Windows]
   java-home/lib/endorsed  [Solaris or Linux]

Here java-home refers to the directory where the runtime software is
installed (which is the top-level directory of the Java 2 Runtime
Environment or the jre directory in the Java 2 SDK).

The Java runtime environment will use classes in such JAR files to
override the corresponding classes provided in the Java 2 Platform as
shipped by Sun.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl




Re: j2ee-builder tests?

2006-08-25 Thread Jason Dillon
I think it would be good to turn those mock test apps into a set of  
real m2 modules that build the j2ee deployables, then j2ee-deployer  
can depend on them  and not have to hack up its build to generate  
them... and then those mock apps could be reused outside of that  
module too... say to test the cli deployer and more.


You want to take a whack at this?

Should be easy enough... I'd like to use these mock apps instead of  
converting all of those hacks to use the m2 standard layout for j2ee- 
builder.


--jason


On Aug 23, 2006, at 3:59 PM, Bill Dudney wrote:


Hi All,

The tests in the j2ee-builder do not currently have valid  
deployment descriptors. While that's ok for this module because of  
the mocked out deployment bits I was hoping to use them in other  
tests. I have most of the stuff fixed up but there are a few things  
that I don't want to do without feedback.


1) there rar is empty, no jar's no xml in the deployment  
descriptors its just a place holder. Thoughts on what to do with  
that? cook up a simple rar? delete it? I lean towards making a  
simple rar.


2) The web.xml references a bogus bunch of ejb's with refs like  
'fake-ejb-ref'. Couple of things we could do with this, make them  
point to valid ejb references in the ejb jar files that are part of  
this ear or delete them. I would/could add some extra EJB's to the  
ejb jar to make sure we covered all the reference types.


3) This is less important but I'd like to change the artifactId's  
so they are unique (i.e. test-ear-j2ee-1.{3,4}) so that I can  
deploy both of the ear files when its all said and done.


4) I'm not sure exactly how to do this with ear/war/ejb-jar but I'd  
like to have this module produce a 'tests' jar (we do this in  
cayenne with simple junit tests so we can reuse it across modules)  
and then reuse these deployment units in other automated tests. I'm  
game to poke at it but figure I might get a few of Jason's brain  
cells so I can be a bit lazier :-)


I posted this jira;

https://issues.apache.org/jira/browse/GERONIMO-2352

to track this issue.

Thanks!

-bd-




Re: Endorsed dirs

2006-08-25 Thread Jacek Laskowski

On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote:

But, do they automatically make it onto the classpath?  This snip
does not really lead me to believe that it does or does not.


Well, I wish I could test it out, but don't know how. I have never
used it explicitly. I'm pretty sure it doesn't have to be on
CLASSPATH. Wait, I'm not sure if I did not mess it up with ext
classloader.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl


Re: [CONSENSUS] Default plugin site (was Re: Frustrations of a Release Manager)

2006-08-25 Thread Jacek Laskowski

On 8/25/06, Dain Sundstrom [EMAIL PROTECTED] wrote:


If it is intended to run on apache hardware, then why not use
geronimo.apache.org/plugins?


I don't think it's a requirement to run on ASF hardware, but a natural
solution - the closer the better.

All in all, your proposal is the best I've seen lately. Easy to
remember and noone would think it's hosted outside the project. I like
it so much that it's going to be profoundly hard to convince me to use
something else. Thanks Dain!

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl


  1   2   >