[jira] Commented: (AMQ-826) LDAP based authorization support
[ 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
[ 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
[ 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
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
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
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
[ 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
+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
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
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
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
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
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
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
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
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
[ 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
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
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
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
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
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
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
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
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
[ 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
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
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
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.
[ 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.
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
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.
[
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
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
[ 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
[ 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.
[
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
[ 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
[ 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
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
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
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)
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
[ 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
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
[ 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
[ 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
[ 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)
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
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
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.
[
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.
[ 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
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
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
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
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
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
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
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)
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
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
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
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
[ 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
[ 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
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
[ 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
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
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
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
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.
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
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
[ 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
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
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
[ 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
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
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
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
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
[ 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
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
[ 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
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
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
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
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
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
[ 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 ?
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
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 ?
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
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
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
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?
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
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)
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
