Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
What is the MaxPermSize you have set? --jason On Aug 30, 2006, at 10:49 PM, Heinz Drews wrote: If it would be my OS I would have enough money to produce a better one :-) In my case was jspc 1.4.5-SNAPSHOT and increasing MaxPermSize was the remedy. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not offended... well, not by your email at least... your os... well that is another story :-P Hopefully we will have the magic recipe for building on windows soon. --jason On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote: Please don't see my comments as offense. They are born from frustration. It seemed that build has been promoted from being the way to being the destination. For me it seems that setting MaxPermSize is helping a lot. The situation that the total process stopped because of a failing test has not happened again. Just finished a successful build using bootstrap under WinXP. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: To clarify... the move of the downloaded sources to target/ external was intended, as I did want to make sure that mvn clean removed them. These sources are not intended to be modified by hand. Anything that you end up having problems with need to make it back to those repositories as changes, so that bootstrap by itself functions. This is not a problem with bootstrap, but a problem with those dependent projects in addition to your local environment/os. While I would very much like to get these build problems fixed for you, changing bootstrap is not the right answer IMO. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006 @@ -19,5 +19,5 @@ PWD=`cygpath --windows $PWD` fi -ant $BUILD_OPTIONS -f bootstrap.xml $@ +ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@ Modified: geronimo/server/trunk/bootstrap.bat URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.bat?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.bat (original) +++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006 @@ -10,7 +10,7 @@ set PROGNAME=%~nx0% set ARGS=%* -ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS% +ant %BUILD_OPTIONS% -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS% :END Modified: geronimo/server/trunk/bootstrap.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.xml?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.xml (original) +++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006 @@ -14,19 +14,19 @@ /sequential /macrodef -macrodef name=build-thirdparty +macrodef name=build-external attribute name=url/ attribute name=name/ sequential -mkdir
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
128m was sufficient. --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: What is the MaxPermSize you have set? --jason On Aug 30, 2006, at 10:49 PM, Heinz Drews wrote: If it would be my OS I would have enough money to produce a better one :-) In my case was jspc 1.4.5-SNAPSHOT and increasing MaxPermSize was the remedy. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not offended... well, not by your email at least... your os... well that is another story :-P Hopefully we will have the magic recipe for building on windows soon. --jason On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote: Please don't see my comments as offense. They are born from frustration. It seemed that build has been promoted from being the way to being the destination. For me it seems that setting MaxPermSize is helping a lot. The situation that the total process stopped because of a failing test has not happened again. Just finished a successful build using bootstrap under WinXP. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: To clarify... the move of the downloaded sources to target/ external was intended, as I did want to make sure that mvn clean removed them. These sources are not intended to be modified by hand. Anything that you end up having problems with need to make it back to those repositories as changes, so that bootstrap by itself functions. This is not a problem with bootstrap, but a problem with those dependent projects in addition to your local environment/os. While I would very much like to get these build problems fixed for you, changing bootstrap is not the right answer IMO. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006 @@ -19,5 +19,5 @@ PWD=`cygpath --windows $PWD` fi -ant $BUILD_OPTIONS -f bootstrap.xml $@ +ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@ Modified: geronimo/server/trunk/bootstrap.bat URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.bat?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.bat (original) +++ geronimo/server/trunk/bootstrap.bat Sat Aug 26 20:25:18 2006 @@ -10,7 +10,7 @@ set PROGNAME=%~nx0% set ARGS=%* -ant %BUILD_OPTIONS% -f bootstrap.xml %ARGS% +ant %BUILD_OPTIONS% -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml %ARGS% :END Modified: geronimo/server/trunk/bootstrap.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.xml?rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap.xml (original) +++ geronimo/server/trunk/bootstrap.xml Sat Aug 26 20:25:18 2006 @@ -14,19 +14,19 @@ /sequential /macrodef -macrodef
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
MaxPermSize specifies the amount of space used for class and method objects. Creating classes dynamically e.g. proxies, using cglib or other dynamic byte code enhancers require more space than the default. The Sun document explicitly names JSP implementations as culprits for running out of space. Seems that we have to monitor the value for the runtime also. The parameter is used by the Sun JVM on all platforms. But they might be different default values. I could not find the default value documented. --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I still dunno what -XXMaxPermSize does... will this wok on all JVM's? Or is this just for windows. I notice that someone updated the wiki to show this... I think we may need to have an example for Windows and an example for others... as I've never needed to set this... and it appears that the Mac OS X JVM does not recognize it either. Anyone know if this is Windows specific? --jason On Aug 30, 2006, at 10:49 PM, Heinz Drews wrote: If it would be my OS I would have enough money to produce a better one :-) In my case was jspc 1.4.5-SNAPSHOT and increasing MaxPermSize was the remedy. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not offended... well, not by your email at least... your os... well that is another story :-P Hopefully we will have the magic recipe for building on windows soon. --jason On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote: Please don't see my comments as offense. They are born from frustration. It seemed that build has been promoted from being the way to being the destination. For me it seems that setting MaxPermSize is helping a lot. The situation that the total process stopped because of a failing test has not happened again. Just finished a successful build using bootstrap under WinXP. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: To clarify... the move of the downloaded sources to target/ external was intended, as I did want to make sure that mvn clean removed them. These sources are not intended to be modified by hand. Anything that you end up having problems with need to make it back to those repositories as changes, so that bootstrap by itself functions. This is not a problem with bootstrap, but a problem with those dependent projects in addition to your local environment/os. While I would very much like to get these build problems fixed for you, changing bootstrap is not the right answer IMO. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006 @@ -19,5 +19,5 @@ PWD=`cygpath --windows $PWD` fi -ant $BUILD_OPTIONS -f bootstrap.xml $@ +ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@ Modified: geronimo/server/trunk/bootstrap.bat URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap.bat?rev=437291r1=437290r2=437291view=diff =
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
Um... then what does Perm stand for? --jason On Aug 30, 2006, at 11:24 PM, Heinz Drews wrote: MaxPermSize specifies the amount of space used for class and method objects. Creating classes dynamically e.g. proxies, using cglib or other dynamic byte code enhancers require more space than the default. The Sun document explicitly names JSP implementations as culprits for running out of space. Seems that we have to monitor the value for the runtime also. The parameter is used by the Sun JVM on all platforms. But they might be different default values. I could not find the default value documented. --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I still dunno what -XXMaxPermSize does... will this wok on all JVM's? Or is this just for windows. I notice that someone updated the wiki to show this... I think we may need to have an example for Windows and an example for others... as I've never needed to set this... and it appears that the Mac OS X JVM does not recognize it either. Anyone know if this is Windows specific? --jason On Aug 30, 2006, at 10:49 PM, Heinz Drews wrote: If it would be my OS I would have enough money to produce a better one :-) In my case was jspc 1.4.5-SNAPSHOT and increasing MaxPermSize was the remedy. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not offended... well, not by your email at least... your os... well that is another story :-P Hopefully we will have the magic recipe for building on windows soon. --jason On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote: Please don't see my comments as offense. They are born from frustration. It seemed that build has been promoted from being the way to being the destination. For me it seems that setting MaxPermSize is helping a lot. The situation that the total process stopped because of a failing test has not happened again. Just finished a successful build using bootstrap under WinXP. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: To clarify... the move of the downloaded sources to target/ external was intended, as I did want to make sure that mvn clean removed them. These sources are not intended to be modified by hand. Anything that you end up having problems with need to make it back to those repositories as changes, so that bootstrap by itself functions. This is not a problem with bootstrap, but a problem with those dependent projects in addition to your local environment/os. While I would very much like to get these build problems fixed for you, changing bootstrap is not the right answer IMO. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18 2006 @@ -19,5 +19,5 @@ PWD=`cygpath --windows $PWD` fi -ant $BUILD_OPTIONS -f bootstrap.xml $@ +ant $BUILD_OPTIONS -emacs -logger org.apache.tools.ant.NoBannerLogger -f bootstrap.xml $@ Modified: geronimo/server/trunk/bootstrap.bat URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
They are not part of standard GC, therefore permanent. They are owned by their classloader, only if the classloader is destroyed then the objects are dropped. --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: Um... then what does Perm stand for? --jason On Aug 30, 2006, at 11:24 PM, Heinz Drews wrote: MaxPermSize specifies the amount of space used for class and method objects. Creating classes dynamically e.g. proxies, using cglib or other dynamic byte code enhancers require more space than the default. The Sun document explicitly names JSP implementations as culprits for running out of space. Seems that we have to monitor the value for the runtime also. The parameter is used by the Sun JVM on all platforms. But they might be different default values. I could not find the default value documented. --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I still dunno what -XXMaxPermSize does... will this wok on all JVM's? Or is this just for windows. I notice that someone updated the wiki to show this... I think we may need to have an example for Windows and an example for others... as I've never needed to set this... and it appears that the Mac OS X JVM does not recognize it either. Anyone know if this is Windows specific? --jason On Aug 30, 2006, at 10:49 PM, Heinz Drews wrote: If it would be my OS I would have enough money to produce a better one :-) In my case was jspc 1.4.5-SNAPSHOT and increasing MaxPermSize was the remedy. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm not offended... well, not by your email at least... your os... well that is another story :-P Hopefully we will have the magic recipe for building on windows soon. --jason On Aug 30, 2006, at 10:01 PM, Heinz Drews wrote: Please don't see my comments as offense. They are born from frustration. It seemed that build has been promoted from being the way to being the destination. For me it seems that setting MaxPermSize is helping a lot. The situation that the total process stopped because of a failing test has not happened again. Just finished a successful build using bootstrap under WinXP. --Heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: To clarify... the move of the downloaded sources to target/ external was intended, as I did want to make sure that mvn clean removed them. These sources are not intended to be modified by hand. Anything that you end up having problems with need to make it back to those repositories as changes, so that bootstrap by itself functions. This is not a problem with bootstrap, but a problem with those dependent projects in addition to your local environment/os. While I would very much like to get these build problems fixed for you, changing bootstrap is not the right answer IMO. --jason On Aug 30, 2006, at 7:38 AM, Joe Bohn wrote: Jason, I'm not sure if this was intended or not ... but having these thirdparty items under target results in the source being purged when doing an mvn clean. This is unfortunate for those of us that are hitting the failures on the openejb tests. My memory may not be correct but I thought that prior to this change I could do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - run mvn clean install -Dmaven.test.skip=true However, now that openejb is under target the clean deletes the source and before it attempts to build and the result is that I still don't get the openejb jar created in my local repo. Now I think I have to do the following: - bootstrap (with the change to use the jspc 1.4.5- SNAPSHOT to avoid the jspc problem). - watch it fail to build openejb due to the test failures. - cd to target\external\openejb2 - run mvn -Dmaven.test.skip=true - run mvn clean install Am I doing something wrong? Thanks, Joe [EMAIL PROTECTED] wrote: Author: jdillon Date: Sat Aug 26 20:25:18 2006 New Revision: 437291 URL: http://svn.apache.org/viewvc?rev=437291view=rev Log: Changed bootstrap to put external stuff into target/external instead of thirdparty Reduced ant output using -emacs and logger Modified: geronimo/server/trunk/bootstrap geronimo/server/trunk/bootstrap.bat geronimo/server/trunk/bootstrap.xml Modified: geronimo/server/trunk/bootstrap URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ bootstrap? rev=437291r1=437290r2=437291view=diff = = --- geronimo/server/trunk/bootstrap (original) +++ geronimo/server/trunk/bootstrap Sat Aug 26 20:25:18
Re: windows build hell
I have released v1.4.5. Feel free to update the pom(s) to use that version.
Jeff
Jason Dillon wrote:
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get past that
other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is
planning to make 1.4.5 an official release for this. We're not sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in 1.4.5
I actually hunt down the tools.jar file...in a similar fashion as done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be able to
release it today as the 72 hours is up. I'll let this list know when I
have released it.
Jeff
Re: windows build hell
Kay, I'm checking now...
--jason
On Aug 30, 2006, at 11:49 PM, Jeff Genender wrote:
I have released v1.4.5. Feel free to update the pom(s) to use that
version.
Jeff
Jason Dillon wrote:
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get past
that
other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-
SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff
Genender is
planning to make 1.4.5 an official release for this. We're not
sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in
1.4.5
I actually hunt down the tools.jar file...in a similar fashion as
done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be
able to
release it today as the 72 hours is up. I'll let this list know
when I
have released it.
Jeff
JPA Plugin patch
Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Andrus
Re: [VOTE] Release car-maven-plugin 1.1
The vote is nearly over ... but so far, only Jason cast a +0.If nobody cares about it, it may be better to host this pluginelsewhere, at mojo.codehaus.org or http://sourceforge.net/projects/gplugins ?On 8/29/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins.As stated in a previous proposal, I have forked the car-maven-plugin from trunk to branches/1.1 and updated it to use 1.1 binaries and to generate 1.1 plugins.Hence, I start this vote to publish the 1.1 version of this plugin.The binaries are available at http://people.apache.org/~gnodet/car-maven-plugin-1.1/org/apache/geronimo/plugins/ car-maven-plugin/1.1/and the site has been deployed at http://geronimo.apache.org/maven/car-maven-plugin-1.1/ I will upload and sign these binaries on the m2-ibiblio-rsync-repository, once this vote is over.Btw, I have uploaded the site at people.apache.org:/www/geronimo.apache.org/ maven/car-maven-plugin-1.1/ but I have been unable to browse it and I did make sure the permissions were ok. If someone has anyhints on how to make it accessible ...-- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet
[jira] Commented: (SM-410) Component Uninstallation : ClassLoader not removed from JVM
[ https://issues.apache.org/activemq/browse/SM-410?page=comments#action_36886 ] Nicolas Biri commented on SM-410: - Same problem on win nt + jdk5.0.7 : loan broker and soap binding uninstall is unable to remove component directories Component Uninstallation : ClassLoader not removed from JVM --- Key: SM-410 URL: https://issues.apache.org/activemq/browse/SM-410 Project: ServiceMix Issue Type: Bug Components: servicemix-components Affects Versions: 3.0-M1 Reporter: Philippe Pinheiro After component uninstallation, the corresponding component classloader is not removed from the JVM and the jars in the wdir are locked. To reproduce this bug you just need to : - install the component : servicemix-jms by putting the jar on the install folder - install a service assembly containing a service unit with some endpoints : copy the zip in the deploy folder - uninstall the service assembly : delete the zip file - uninstall the component : delete the jar file Then you will see that some files are still locked on the wdir folder. Furthermore I use JSwat to remotely debug the JVM, with this tool you can see that the ParentFirstClassloader of the servicemix-jms component is still loaded. I also found that if a service assembly is not installed then this bug doesn't occur. -- 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: Classes in trunk
I think it should be removed from trunk...2006/8/30, Jason Dillon [EMAIL PROTECTED]: I dunno... but seems like a bad idea.--jasonOn Aug 29, 2006, at 12:13 AM, Sergey Elin wrote: Hi, there is a number of class files in trunk. Any reasons for it? ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet1.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter1.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet2.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter2.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/mx4j/MBeanDescription.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/javax/foo/Foo.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/javax/servlet/Servlet.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorld.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorldWS.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/mx4j/MBeanDescription.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/javax/foo/Foo.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/javax/servlet/Servlet.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/mx4j/ MBeanDescription.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/ javax/foo/Foo.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/ javax/servlet/Servlet.class
Re: windows build hell
Done.
--jason
On Aug 30, 2006, at 11:49 PM, Jeff Genender wrote:
I have released v1.4.5. Feel free to update the pom(s) to use that
version.
Jeff
Jason Dillon wrote:
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get past
that
other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-
SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff
Genender is
planning to make 1.4.5 an official release for this. We're not
sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in
1.4.5
I actually hunt down the tools.jar file...in a similar fashion as
done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be
able to
release it today as the 72 hours is up. I'll let this list know
when I
have released it.
Jeff
[jira] Created: (GERONIMO-2366) Server terminates if problems occur with keystores
Server terminates if problems occur with keystores -- Key: GERONIMO-2366 URL: http://issues.apache.org/jira/browse/GERONIMO-2366 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: security Environment: Linux, Windows XP, Reporter: Heinz Drews ServiceModule does not handle exceptions originating from keystore problems completely. This causes that the server is terminated instaed of placing the GBean into failed state. ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geron imo/j2ee-security/1.1/car?ServiceModule=geronimo/j2ee-security/1.1/car,j2eeType=Keystore,name=vimes.org.keystore java.lang.IllegalArgumentException: Invalid keystore file (var/security/keystores/vimes.org.keystore = /opt/geronimo-1.1/var/security/keystores/vimes.org.ke ystore) at org.apache.geronimo.security.keystore.FileKeystoreInstance.doStart(FileKeystoreInstance.java:113) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$c5b9d230.startConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:297) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) -- 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] Updated: (GERONIMO-2366) Server terminates if problems occur with keystores
[ http://issues.apache.org/jira/browse/GERONIMO-2366?page=all ] Heinz Drews updated GERONIMO-2366: -- Affects Version/s: 1.1 Server terminates if problems occur with keystores -- Key: GERONIMO-2366 URL: http://issues.apache.org/jira/browse/GERONIMO-2366 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.1 Environment: Linux, Windows XP, Reporter: Heinz Drews ServiceModule does not handle exceptions originating from keystore problems completely. This causes that the server is terminated instaed of placing the GBean into failed state. ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geron imo/j2ee-security/1.1/car?ServiceModule=geronimo/j2ee-security/1.1/car,j2eeType=Keystore,name=vimes.org.keystore java.lang.IllegalArgumentException: Invalid keystore file (var/security/keystores/vimes.org.keystore = /opt/geronimo-1.1/var/security/keystores/vimes.org.ke ystore) at org.apache.geronimo.security.keystore.FileKeystoreInstance.doStart(FileKeystoreInstance.java:113) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:374) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:512) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:493) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.kernel.config.EditableConfigurationManager$$EnhancerByCGLIB$$c5b9d230.startConfiguration(generated) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:297) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:74) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:377) -- 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: windows build hell
It would be nice to know if tomcat-builder can be built using mvn -o clean install from the following directories after these errors: 1. modules directory 2. modules/geronimo-tomcat-builder directory Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: If you get a bsod while running a bootstrap please let me see your bootstrap.log (or at least the end of it) to see if the pattern remains consistent. Since I sent this original note out I've heard from Rick McGuire with another bsod in TomcatModuleBuilderTest Joe . 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Reopened: (GERONIMODEVTOOLS-83) Build fails for plugin org.apache.geronimo.st.v11.ui
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Affects Version/s: 1.x
Build fails for plugin org.apache.geronimo.st.v11.ui
Key: GERONIMODEVTOOLS-83
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 1.x
Environment: WinXP, Sun Java 1.4.2_12, Maven 2.0.4
Reporter: Donald Woods
Assigned To: Sachin Patel
Priority: Blocker
Have not been able to build trunk Rev411643. During the build, I'm getting
the following failure for plugins\org.apache.geronimo.st.v1.core
. . .snip
[INFO]
[INFO] Building org.apache.geronimo.st.v1.core
[INFO]task-segment: [install]
[INFO]
[INFO] [geronimodevtools:download {execution: install-dependencies}]
[INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
[INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
[INFO] GEF-SDK-3.1.1.zip already exists in local repository
[INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
[INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
[INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
[INFO] [geronimodevtools:install {execution: install-dependencies}]
[INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
[INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local
repository.
[INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
[INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local
repository.
[INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local
repository.
[INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local
repository.
[INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
[INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
[INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
[INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in
local repository.
[INFO] org.eclipse.jdt.launching : 3.1.0 already exists in local repository.
[INFO] org.eclipse.xsd.edit : 2.1.0 already exists in local repository.
[INFO] org.eclipse.jst.server.core : 1.0.2.v20060402 already exists in local
repository.
[INFO] org.eclipse.wst.common.project.facet.core : 1.0.1.v200603242204
already exists in local repository.
[INFO] org.eclipse.emf.mapping.ui : 2.1.0 already exists in local repository.
[INFO] org.eclipse.wst.common.frameworks : 1.0.1.v200602070050 already exists
in local repository.
[INFO] org.eclipse.jst.server.generic.core : 1.0.0.v200602112126 already
exists in local repository.
[INFO] org.eclipse.wst.common.modulecore : 1.0.1.v200604191828 already exists
in local repository.
[INFO] org.eclipse.osgi : 3.1.2 already exists in local repository.
[INFO] [geronimodevtools:download {execution: install-dependencies}]
[INFO] emf-sdo-xsd-SDK-2.1.2.zip already exists in local repository
[INFO] JEM-SDK-1.1.0.1.zip already exists in local repository
[INFO] GEF-SDK-3.1.1.zip already exists in local repository
[INFO] wtp-sdk-R-1.0.2-200604280245.zip already exists in local repository
[INFO] eclipse-SDK-3.1.2-win32.zip already exists in local repository
[INFO] [geronimodevtools:manifestbundles {execution: install-dependencies}]
[INFO] [geronimodevtools:install {execution: install-dependencies}]
[INFO] org.eclipse.jdt.core : 3.1.2 already exists in local repository.
[INFO] org.eclipse.emf.mapping.xsd2ecore : 2.1.0 already exists in local
repository.
[INFO] org.eclipse.emf.common : 2.1.0 already exists in local repository.
[INFO] org.eclipse.wst.server.core : 1.0.2.v20060406 already exists in local
repository.
[INFO] org.eclipse.wst.web : 1.0.1.v200603160007 already exists in local
repository.
[INFO] org.eclipse.jst.j2ee : 1.0.1.v200604191828 already exists in local
repository.
[INFO] org.eclipse.core.runtime : 3.1.2 already exists in local repository.
[INFO] org.eclipse.debug.core : 3.1.2 already exists in local repository.
[INFO] org.eclipse.emf.ecore : 2.1.0 already exists in local repository.
[INFO] org.eclipse.emf.mapping.xsd2ecore.editor : 2.1.0 already exists in
local repository.
[INFO] org.eclipse.jdt.launching : 3.1.0 already exists in local repository.
[INFO] org.eclipse.xsd.edit : 2.1.0 already exists in local repository.
[INFO] org.eclipse.jst.server.core : 1.0.2.v20060402 already exists in local
repository.
[INFO] org.eclipse.wst.common.project.facet.core : 1.0.1.v200603242204
already exists in local repository.
[INFO]
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, target/login-audit.log);
instead of
File auditlog = new File(target/login-audit.log);
The relative file references in java are resolved using the current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The workingDirectory specifies the dir the jvm is forked from. If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File(login-audit.log);
This is the most natural way. WDYT?
Thanks
Anita
--- Jason Dillon (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting
to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=AuditLoginModuleUse
DEBUG [main] GBeanInstanceState
[jira] Created: (GERONIMO-2367) Keystore portlet adds any file in ./var/security/keystore as keystore and does not provide a delete function
Keystore portlet adds any file in ./var/security/keystore as keystore and does not provide a delete function - Key: GERONIMO-2367 URL: http://issues.apache.org/jira/browse/GERONIMO-2367 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1 Environment: Linux, Windows XP Reporter: Heinz Drews the keystore portlet adds any file in the directory as keystore. there is no option to remove the entries from the menu. if the files are deleted from the file system next start of Geronimo fails with symptoms described in GERONIMO-2366 -- 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: windows build hell
I can do the individual builds but I'm sure they'll be successful (or at least successful most, if not all, of the time). The bsod is an intermittent problem and I suspect that it has to do with high stress scenarios during the big builds (where big means either bootstrap or mvn install from root). I was getting it about every 3-6 attempts on two different machines. I then got hold of a loaner machine, switched my drive, and it took me 14 attempts to hit it again. However, after that I hit it on the second attempt after reboot. Joe anita kulshreshtha wrote: It would be nice to know if tomcat-builder can be built using mvn -o clean install from the following directories after these errors: 1. modules directory 2. modules/geronimo-tomcat-builder directory Thanks Anita --- Joe Bohn [EMAIL PROTECTED] wrote: If you get a bsod while running a bootstrap please let me see your bootstrap.log (or at least the end of it) to see if the pattern remains consistent. Since I sent this original note out I've heard from Rick McGuire with another bsod in TomcatModuleBuilderTest Joe . 4) Blue screen of death (bsod) Problem: This has been reported by multiple users on various machines. When running an M1 or M2 build the user encounters a bsod due to a memory failure. PAGE_FAULT_IN_NONPAGED_AREA *** STOP: 0x0050 (0xBADDB148, 0x, 0x8056C77B, 0x) Dump of physical memory Work-around/Possible Solution: Haven't found one yet. I've tried updated drivers, replaced hardware, tried various heap size settings, etc At times this can be fairly frequent (every 3rd build attempt or so). I'm collecting bootstrap.log files from folks when this happens during a bootstrap to see if there is a common thread. So far, with the bootstrap logs, it always seems to happen at about the same place: Running tests after building a module (usually tomcat.ApplicationTest or TomcatModuleBuilderTest) and the final lines in the log are always the Creation of an MBeanServer like this: [exec] Running org.apache.geronimo.tomcat.ApplicationTest [exec] Created MBeanServer with ID: 5dcec6:10d5a184aed:-8000:jbohn2:1 Please respond to this note if you are seeing the bsod failures on windows. At first I thought this was just me and was hardware related. However, the more I talk to folks on windows the more I hear of other folks encountering this same problem. I've updated all drivers, replaced my entire system, and several other folks have reported seeing this on completely different systems. I think that pretty much rules out a hardware problem. ideas welcome! Joe __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: servicemix-http and normalization
I'm working on that now. A few comments inline. On 8/30/06, Alex Boisvert [EMAIL PROTECTED] wrote: Guillaume Nodet wrote: Some existing components may already expose a WSDL 1.1 (as WSDL 2.0 is not supported yet) which may contain a soap binding. While this is not a good thing, we need to cope with them. How difficult would it be to fix these components? It might be more worthwhile to attack the problem at the root... Agreed. I will do it after. That' s the reason why I don't really like the mechanism to auto-discover the WSDL and engage the WSDL 1.1 normalization if the target endpoint WSDL contain a soap binding. I think this should be configured with a flag on the http consumer endpoint. And existing components should be enhanced to use this normalization (but that' s another problem). That's understood. I was looking for feedback on how to configure this behavior. I'll look into adding a flag on the http consumer endpoint. The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Another slight oversight I think, is that the SoapHelper#findOperation should only check the WSDL for the current endpoint, and this WSDL should be modified according to the binding used. We should also provide a way to easily configure the binding with default values (let's say just doclit / rpc) by setting a flag on the http endpoint. I'm not sure I follow here. Do you mean that #findOperation should not check the WSDL of the target ServiceEndpoint? If so, I can remove that. On the second point, it sounds like fixing the WSDL document is easier and better than adding configuration on the endpoint... unless I'm missing something. See previous comment. So, while I think this is a really good patch that enhance the current http component, it is part of a bigger feature. It may even be linked to WSDL 2.0 support, or full rest support. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. If I find enough time (may not be this week), I'll try to handle these two points in a simple way for the moment, so that this great and needed feature can be used. But if you want to take a look at it, feel free to do so. Also, I think I have seen some removed / commented features about security. I think this is a patch I applied recently... Ok, I'll double-check. alex -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431875
]
Bill Dudney commented on GERONIMO-2352:
---
Hi Jason,
Thanks for taking the time to review and apply the patch!
One quick comment: the lack of inheritance from parent was because of a problem
with the jspc-maven-plugin configuration. I kept getting errors
('...geronimo/test-deployables/test-ear-j2ee-1.3/war/target/jspweb.xml' does
not exist). I tried messing with the configuration but could not quickly get
the build to work so I dropped the parent reference. I forgot to circle back
around and work through that. Is it possible to remove or block a build plugin
that was inherited from a parent pom? There are no jsp's in these war files, as
a workaround though I could add one to each and make the war look like what the
jspc plugin expects.
Thanks again!
j2ee-builder test deployment modules won't actually deploy
--
Key: GERONIMO-2352
URL: http://issues.apache.org/jira/browse/GERONIMO-2352
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Bill Dudney
Assigned To: Jason Dillon
Attachments: GERONIMO-2352.bdudney.patch
The ear/war/ejb-jar/rar files wont actually deploy to the server.
I have a partial patch avalible but I'd like to get some discussion going on
how to fix some of the problems, that is happening in the dev list.
I will post the complete patch here when that discussion is wrapped up.
--
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: Anyone know how to make the kernel tests be quiet?
In M1 there was a way to say swallow ouput. I can not find a reference to it. But trying.. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [RTC] WADI Integration for Jetty
Gianny Damour wrote: Thanks for having a look at it. As a matter of fact, I have been pretty useless with respect to reviewing patches; so, it is me who owes the apologies. Well as we are all doing the apology dance even with my email filters highlighting this one in RED - I missed it and it is definitely one I should pay attention to. I'm applying it now. cheers -- Greg Wilkins[EMAIL PROTECTED] US: +1 3104915462 IT: +39 3349267680 http://www.webtide.com UK: +44(0)2079932589 AU: +61(0)417786631
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
One more thing..
In m1 the jvm was forked from basedir, hence we have all the file
references as target/
http://maven.apache.org/maven-1.x/plugins/test/properties.html
So we should modify all the tests to not used target!
Thanks
Anita
--- anita kulshreshtha [EMAIL PROTECTED] wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, target/login-audit.log);
instead of
File auditlog = new File(target/login-audit.log);
The relative file references in java are resolved using the
current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The workingDirectory specifies the dir the jvm is forked from.
If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File(login-audit.log);
This is the most natural way. WDYT?
Thanks
Anita
--- Jason Dillon (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all
]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security ::
**/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2
build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting
to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the
patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped
to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from
stopped
to starting
DEBUG [main] GBeanInstanceState for:
[jira] Resolved: (AMQ-877) Patch: refactoring to allow alternative (using different storage interface) Destinations implementations.
[ https://issues.apache.org/activemq/browse/AMQ-877?page=all ]
Rob Davies resolved AMQ-877.
Resolution: Fixed
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: destinationFactoryActiveMQ_438704.patch,
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: Standard for serialVersionUID
Heinz, Adding serialVersionUIDs to Serializable classes is sure a great idea! It's strongly recommended by Sun, and all the way helps when dealing with serialization in large projects. It's not in fact important what particular value you specify for serialVersionUID field, the only thing important is you change the serialVersionUID for a class when its serialized form changes, and ONLY if its serialized form changes. From this perspective, using class version number is not a good idea, as a class may be modified (and thus version number changed), but a serialized form may stay the same, and changing serialVersionUID would introduce an unnecessary serialization incompatibility. The traditional way is to use 'serialver' program from Sun's JDK. If this way is for some reason uncomfortable for you, you may use some other way to calculate serialVersionUIDs, like Eclipse built-in feature or the like. The particular value is not important, only changes to it are. Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. Thank you! Vasily Zakharov Intel Middleware Products Division -Original Message- From: Heinz Drews [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:46 AM To: geronimo-dev Subject: Standard for serialVersionUID As I have mentioned in another message I have accidently used class files in modules created by Eclipse embeded compiler. This calculates serialVersionUID different way then javac. I think that adding serialVersionUID to all serializable class would address the situation best. There are quite a number of class without the uid. I would volunteer to add them but which standard should be used? Eclipse provides the option set it to 1 or to calculate the uid. But the calculation is different to the one doen by javac. In other projects I have found the convention to use version number to support detection of incompatible modifications. The version number a much nicer to read in the message reporting mismatches than the generated ones. Least impact would be to calculate the value with the serialver tool. This avoids the need for redeploying. Which standard should be chosen? --Heinz
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431882
]
Jeff Genender commented on GERONIMO-2352:
-
I wouldn't remove parent references. You have a couple of options. Either A)
open a JIRA on the jspc over at Mojo as that is a relatively easy fix, and/or
B) create an emply jspcweb.xml file in src/test/jspc/ and add the following to
your configuration:
webXml${basedir}/src/test/jspc/jspweb.xml/webXml
and be sure there is a !-- [INSERT FRAGMENT HERE] -- in the web.xml.
This will pick up the empty file. However if you use any JSPs for that war,
you will need to remove that configuration.
In any case...open up a JIRA at http://jira.codehaus.org/browse/MJSPC.
j2ee-builder test deployment modules won't actually deploy
--
Key: GERONIMO-2352
URL: http://issues.apache.org/jira/browse/GERONIMO-2352
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Bill Dudney
Assigned To: Jason Dillon
Attachments: GERONIMO-2352.bdudney.patch
The ear/war/ejb-jar/rar files wont actually deploy to the server.
I have a partial patch avalible but I'd like to get some discussion going on
how to fix some of the problems, that is happening in the dev list.
I will post the complete patch here when that discussion is wrapped up.
--
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: [VOTE] 1.1.1-rc1 for Release
Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1-src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee-jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema-j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty-minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat-minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen-builder-2.1.1.jar . Hello, I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at
Re: Restructuring trunk, then next steps
I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. Do I understand correctly that with this proposal what is currently modules/geronimo-j2ee-builder would become system/geronimo-j2ee/geronimo-j2ee-builder and what is currently modules/geronimo-j2ee would become system/geronimo-j2ee/geronimo-j2ee? If so, then I think we are introducing some unnecessary redundancy once again. BTW, do I understand correctly that you're proposing the removal of modules or is this presumed to be prior to each of the new names? I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat geronimo-tomcat-builder geronimo-jetty geronimo-jetty-builder geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade
[jira] Created: (AMQ-906) Exception does not lead to redelivery for AUTO_ACKNOWLEDGE
Exception does not lead to redelivery for AUTO_ACKNOWLEDGE
--
Key: AMQ-906
URL: https://issues.apache.org/activemq/browse/AMQ-906
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0.1
Reporter: Daniel Aioanei
I have a message driven pojo configured configured with with auto_acknowledge,
nontransactional and some persistent message in a queue. All my mdp does it to
throw new RuntimeException(please retry) but unfortunately the messages are
not retried:
SEVERE: error dispatching message:
java.lang.RuntimeException: Please retry
at
net.activem.jms.ExceptionTestOutboundMdp.onMessage(ExceptionTestOutboundMdp.java:46)
at
org.jencks.LocalTransactionEndpoint.onMessage(LocalTransactionEndpoint.java:68)
at
org.apache.activemq.ra.MessageEndpointProxy$MessageEndpointAlive.onMessage(MessageEndpointProxy.java:120)
at
org.apache.activemq.ra.MessageEndpointProxy.onMessage(MessageEndpointProxy.java:60)
at org.apache.activemq.ActiveMQSession.run(ActiveMQSession.java:692)
at
org.apache.activemq.ra.ServerSessionImpl.run(ServerSessionImpl.java:163)
at
org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
Source)
Looking in the ActiveMQ source code I think the problem might be in these lines:
try {
messageListener.onMessage(message);
} catch ( Throwable e ) {
// TODO: figure out proper way to handle error.
log.error(error dispatching message: ,e);
connection.onAsyncException(e);
}
at java.lang.Thread.run(Thread.java:595)
found in org.apache.activemq.ActiveMQSession.
According to JMS spec, I'd say that with auto_ack a msg should be retried in
case the message listener throws an exception, even if the operation is
non-transactional:
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#AUTO_ACKNOWLEDGE
public static final int AUTO_ACKNOWLEDGE
With this acknowledgment mode, the session automatically acknowledges a
client's receipt of a message either when the session has successfully returned
from a call to receive or when the message listener the session has called to
process the message successfully returns.
--
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: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431892 ] Bill Dudney commented on GERONIMO-2352: --- Hi Jeff, Thanks for helping with this. If I don't have a reference to the plugin in my war's pom.xml file the build fails with the lack of jspweb.xml file, if I put in a reference the build works, i.e. if I put this; build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdjspc-maven-plugin/artifactId /plugin /plugins /build into the war module's pom file it builds fine, without that it fails. Shouldn't this be there by default once the parent reference is in place? Thanks again! j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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: Restructuring trunk, then next steps
+1 on this proposal On 8/31/06, Joe Bohn [EMAIL PROTECTED] wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. Do I understand correctly that with this proposal what is currently modules/geronimo-j2ee-builder would become system/geronimo-j2ee/geronimo-j2ee-builder and what is currently modules/geronimo-j2ee would become system/geronimo-j2ee/geronimo-j2ee? If so, then I think we are introducing some unnecessary redundancy once again. BTW, do I understand correctly that you're proposing the removal of modules or is this presumed to be prior to each of the new names? I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/ geronimo-testsupport (may need to be in other tree? so can include in all modules by default) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel system/ geronimo-management geronimo-security geronimo-security-builder geronimo-service-builder geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-connector-builder geronimo-jmx-remoting geronimo-naming geronimo-naming-builder geronimo-test-ddbean (wtf is this for?) geronimo-deployment/ geronimo-deployment (rename to -core) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-hot-deploy geronimo-client geronimo-client-builder geronimo-j2ee/ geronimo-j2ee geronimo-j2ee-builder geronimo-j2ee-schema geronimo-web-builder plugins/ geronimo-activemq/ ge-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-axis-builder geronimo-derby geronimo-directory geronimo-tomcat
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431896 ] Jeff Genender commented on GERONIMO-2352: - No...you need that there if you are going to override the configution which I explained earlier in this JIRA. You are overriding *only* for that WAR. j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431897 ] Bill Dudney commented on GERONIMO-2352: --- AFAIK I'm not overiding the configuration. There is no intent to overide it. If I copy the whole config out of the root pom the build works fine as well. j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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: (GERONIMO-2368) Unable to create a (MySQL) database pool
Unable to create a (MySQL) database pool Key: GERONIMO-2368 URL: http://issues.apache.org/jira/browse/GERONIMO-2368 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: databases Affects Versions: 1.1.1 Environment: Fedora Core 5 MySQL 5.0.22 Reporter: Jay D. McHugh I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) I was only able to get through the first page of the wizard before it locked up. Here are the values that I entered: Name of Database Pool: plc Database Type: MySQL I also tried deploying from the command line using a deployment XML file that I saved a while ago and got the following error (The file might not be in the correct format anymore so this might not be a real issue): Error: Unable to connect to server at deployer:geronimo:jmx -- javax.naming.NoInitialContextException: Can't
[jira] Commented: (GERONIMO-2368) Unable to create a (MySQL) database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2368?page=comments#action_12431899 ] Bill Dudney commented on GERONIMO-2368: --- similar problem trying to deploy 'Derby Embeded' datasource; Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) Unable to create a (MySQL) database pool Key: GERONIMO-2368 URL: http://issues.apache.org/jira/browse/GERONIMO-2368 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 1.1.1 Environment: Fedora Core 5 MySQL 5.0.22 Reporter: Jay D. McHugh I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must
Re: JPA Plugin patch
OK, but which JPA spec JAR are you using? I want to make sure I'm building against the latest. Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Andrus
Re: JPA Plugin patch
This one (which to the best of my knowledge corresponds to the final release of the spec) http://people.apache.org/repo/m2-snapshot-repository/org/apache/ geronimo/specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/ BTW, are you able to build a functioning plugin? I am getting stuck here: # cd plugins/common # mvn install [ERROR] BUILD ERROR [INFO] [INFO] load of geronimo/geronimo-gbean-deployer/1.1/car failed Andrus On Aug 31, 2006, at 7:22 PM, Aaron Mulder wrote: OK, but which JPA spec JAR are you using? I want to make sure I'm building against the latest. Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Andrus
Re: [VOTE] 1.1.1-rc1 for Release
Hi Matt, Sorry to say but I'm experiencing similar problems with trying to deploy a derby embedded datasource; I attached this stack trace to the JIRA that Jay filed (thanks Jay!) http://issues.apache.org/jira/browse/GERONIMO-2368 Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermissi on(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool $ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) On Aug 31, 2006, at 8:22 AM, Jay D. McHugh wrote: Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee- jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb- builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen- builder-2.1.1.jar . Hello, I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector- java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (WebResourcePermission.java:47) at
Re: JPA Plugin patch
You need to manually install the Geronimo 1.1 CARs into your local M2 repo. Unfortunately, the only way to do this is to build the Geronimo 1.1 tag from source or to create them by JARring up the right directories in a Geronimo 1.1 installation. Matt Hogstrom has a todo to put all the Geronimo 1.1 CARs and WARs into a Maven repository, but it doesn't seem to be real high on his list Matt, any ETA? Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: This one (which to the best of my knowledge corresponds to the final release of the spec) http://people.apache.org/repo/m2-snapshot-repository/org/apache/ geronimo/specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/ BTW, are you able to build a functioning plugin? I am getting stuck here: # cd plugins/common # mvn install [ERROR] BUILD ERROR [INFO] [INFO] load of geronimo/geronimo-gbean-deployer/1.1/car failed Andrus On Aug 31, 2006, at 7:22 PM, Aaron Mulder wrote: OK, but which JPA spec JAR are you using? I want to make sure I'm building against the latest. Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Andrus
Re: Standard for serialVersionUID
Hello Vasily, in several projects we had made serialVersionUID mandatory for all serializables. And because it's just an id a lot of opinions are coming up in discussions how to specify it. Just as clarification, in the approach with the version number it was not changed with each modification. Only if a change was causing an impact to the serialized version. Rationale was that in case of a mismatch the message would be easier to interpret then the traditional values. But I guess the traditional approach would be the preferred. Regards, Heinz On 8/31/06, Zakharov, Vasily M [EMAIL PROTECTED] wrote: Heinz, Adding serialVersionUIDs to Serializable classes is sure a great idea! It's strongly recommended by Sun, and all the way helps when dealing with serialization in large projects. It's not in fact important what particular value you specify for serialVersionUID field, the only thing important is you change the serialVersionUID for a class when its serialized form changes, and ONLY if its serialized form changes. From this perspective, using class version number is not a good idea, as a class may be modified (and thus version number changed), but a serialized form may stay the same, and changing serialVersionUID would introduce an unnecessary serialization incompatibility. The traditional way is to use 'serialver' program from Sun's JDK. If this way is for some reason uncomfortable for you, you may use some other way to calculate serialVersionUIDs, like Eclipse built-in feature or the like. The particular value is not important, only changes to it are. Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. Thank you! Vasily Zakharov Intel Middleware Products Division -Original Message- From: Heinz Drews [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:46 AM To: geronimo-dev Subject: Standard for serialVersionUID As I have mentioned in another message I have accidently used class files in modules created by Eclipse embeded compiler. This calculates serialVersionUID different way then javac. I think that adding serialVersionUID to all serializable class would address the situation best. There are quite a number of class without the uid. I would volunteer to add them but which standard should be used? Eclipse provides the option set it to 1 or to calculate the uid. But the calculation is different to the one doen by javac. In other projects I have found the convention to use version number to support detection of incompatible modifications. The version number a much nicer to read in the message reporting mismatches than the generated ones. Least impact would be to calculate the value with the serialver tool. This avoids the need for redeploying. Which standard should be chosen? --Heinz
Re: [VOTE] 1.1.1-rc1 for Release
Alan, I thought you fixed this in 1.1.1? Thanks, Aaron On 8/31/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Matt, Sorry to say but I'm experiencing similar problems with trying to deploy a derby embedded datasource; I attached this stack trace to the JIRA that Jay filed (thanks Jay!) http://issues.apache.org/jira/browse/GERONIMO-2368 Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermissi on(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool $ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) On Aug 31, 2006, at 8:22 AM, Jay D. McHugh wrote: Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee- jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb- builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen- builder-2.1.1.jar . Hello, I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector- java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at
Re: windows build hell
Jason,
I'm not sure just adding getName() will fix the openejb test problem.
See my earlier post:
http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2
Joe
Jason Dillon wrote:
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get past that
other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5- SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff Genender is
planning to make 1.4.5 an official release for this. We're not sure
why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because in 1.4.5
I actually hunt down the tools.jar file...in a similar fashion as done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be able to
release it today as the 72 hours is up. I'll let this list know when I
have released it.
Jeff
Re: Declarative Exception Handling in ServiceMix
So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level. -Jeff jpuro wrote: 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
Re: JPA Plugin patch
Just installed the following pieces from G 1.1 download: geronimo/geronimo-gbean-deployer/1.1/geronimo-gbean-deployer-1.1.car geronimo/geronimo-system/1.1/geronimo-system-1.1.jar geronimo/geronimo-deployment/1.1/geronimo-deployment-1.1.jar geronimo/geronimo-management/1.1/geronimo-management-1.1.jar geronimo/geronimo-service-builder/1.1/geronimo-service-builder-1.1.jar The new build attempt fails with this error: [[INFO] [car:prepare-plan] [INFO] Generated: /Users/andrus/work/jpa-misc/gplugins-jpa/plugins/ common/target/plan/plan.xml [INFO] [car:package] [INFO] Packaging module configuration: /Users/andrus/work/jpa-misc/ gplugins-jpa/plugins/common/target/plan/plan.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] start of geronimo/geronimo-gbean-deployer/1.1/car failed Target does not have specified method (declared in a GBeanInfo operation): name=addGBeans methodName=addGBeans targetClass=org.apache.geronimo.deployment.service.ServiceConfigBuilder Any ideas? Andrus On Aug 31, 2006, at 7:34 PM, Aaron Mulder wrote: You need to manually install the Geronimo 1.1 CARs into your local M2 repo. Unfortunately, the only way to do this is to build the Geronimo 1.1 tag from source or to create them by JARring up the right directories in a Geronimo 1.1 installation. Matt Hogstrom has a todo to put all the Geronimo 1.1 CARs and WARs into a Maven repository, but it doesn't seem to be real high on his list Matt, any ETA? Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: This one (which to the best of my knowledge corresponds to the final release of the spec) http://people.apache.org/repo/m2-snapshot-repository/org/apache/ geronimo/specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/ BTW, are you able to build a functioning plugin? I am getting stuck here: # cd plugins/common # mvn install [ERROR] BUILD ERROR [INFO] - --- [INFO] load of geronimo/geronimo-gbean-deployer/1.1/car failed Andrus On Aug 31, 2006, at 7:22 PM, Aaron Mulder wrote: OK, but which JPA spec JAR are you using? I want to make sure I'm building against the latest. Thanks, Aaron On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Andrus
Re: Declarative Exception Handling in ServiceMix
You could try to take the EIP WireTap pattern as a basis, or the StaticRoutingSlip. I think of the following pattern: * the pattern receive an exchange A * it copy it and send it to the main target B * if B answers with a DONE, send back DONE to A * if B answers with ACTIVE (out or fault), send back to A * if B answers with ERROR, resend the same exchange to C * send back the answer from C to A I' m not quite sure if we should support some routing here on the Exception reported by B. I guess it should be easy to define sereral classes/target combinations, and the first one that match (the exception inherit the configured one) wins. It would give something like eip:error-handler service=... endpoint=... eip:target eip:exchange-target service=test:xpathSplitter / /eip:target eip:error class=java.io.IOException eip:exchange-target service=test:flow1 / /eip:error eip:error eip:exchange-target service=test:default / /eip:error /eip:error-handler This example would route all IOException to flow1, and other exceptions to default. I also think that the exception should be put in a property on the new exchange, so that the target could use if if necessary. Makes sense ? On 8/31/06, jpuro [EMAIL PROTECTED] wrote: So, how would I go about adding this new EIP pattern for handling exceptions? Anybody have any suggestions on what and how it gets configured and how it actually catches the exceptions? I'm guessing it has to be some sort of endpoint that allows you to specify the type of exception to catch and where to route the exception where it is caught, but I'm not sure how this will actually work on the code level. -Jeff jpuro wrote: 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
Re: [VOTE] 1.1.1-rc1 for Release
I did. Let me take a look. Regards, Alan Aaron Mulder wrote: Alan, I thought you fixed this in 1.1.1? Thanks, Aaron On 8/31/06, Bill Dudney [EMAIL PROTECTED] wrote: Hi Matt, Sorry to say but I'm experiencing similar problems with trying to deploy a derby embedded datasource; I attached this stack trace to the JIRA that Jay filed (thanks Jay!) http://issues.apache.org/jira/browse/GERONIMO-2368 Geronimo Application Server started 09:19:47,792 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init (URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init (WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermissi on(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke (AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext $SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke (GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke (StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke (AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service (CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process (Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol $Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt (LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool $ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:552) On Aug 31, 2006, at 8:22 AM, Jay D. McHugh wrote: Matt Hogstrom wrote: CTS is complete and here is the RC1 for your reviewing pleasure. Please send your comments to the dev@geronimo.apache.org list. If there are no negative comments after Monday, September 5th at 0900 ET. We'll move this to be the final and release it. If there are issues, they will be addressed and another e-mail will be issued resetting for an rc2 vote. Thanks. *Source* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-1.1.1-rc1- src.zip *Specifications* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-j2ee- jacc_1.0_spec-1.1.1.jar *Schemas* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0-src.jar http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-schema- j2ee_1.4-1.0.jar *Distributions* http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-jetty- minimal-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- j2ee-1.1.1-rc1.zip http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.tar.gz http://people.apache.org/~hogstrom/1.1.1-rc1/geronimo-tomcat- minimal-1.1.1-rc1.zip If you want to build you will need these jars also (will be released simultaneously with Geronimo) and these need to be placed in your local Maven repository. *OpenEJB Jars* http://people.apache.org/~hogstrom/1.1.1-rc1/openejb- builder-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-core-2.1.1.jar http://people.apache.org/~hogstrom/1.1.1-rc1/openejb-pkgen- builder-2.1.1.jar . Hello, I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector- java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init
[jira] Assigned: (GERONIMO-2368) Unable to create a (MySQL) database pool
[ http://issues.apache.org/jira/browse/GERONIMO-2368?page=all ] Alan Cabrera reassigned GERONIMO-2368: -- Assignee: Alan Cabrera Unable to create a (MySQL) database pool Key: GERONIMO-2368 URL: http://issues.apache.org/jira/browse/GERONIMO-2368 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: databases Affects Versions: 1.1.1 Environment: Fedora Core 5 MySQL 5.0.22 Reporter: Jay D. McHugh Assigned To: Alan Cabrera I tried to install the MySQL JDBC driver (installation worked) and define my datasource. Trying to create the datasource using the wizard locked up the browser and resulted in the following log file (I tried twice - that is why the error appears two times): Copying into repository mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished. 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the container during the request processing java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47) at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:534) I was only able to get through the first page of the wizard before it locked up. Here are the values that I entered: Name of Database Pool: plc Database Type: MySQL I also tried deploying from the command
Re: Where to put new Callback and CallbackHandler classes
I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. 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/ -- Regards, Hiram Blog: http://hiramchirino.com
[jira] Created: (AMQ-907) Make the ActiveIO dependency and optional dependency.
Make the ActiveIO dependency and optional dependency. --- Key: AMQ-907 URL: https://issues.apache.org/activemq/browse/AMQ-907 Project: ActiveMQ Issue Type: Improvement Components: Broker Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1 Need to move some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use from activeio are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. -- 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
I've created http://issues.apache.org/activemq/browse/AMQ-907 to track this. On 8/31/06, Hiram Chirino [EMAIL PROTECTED] wrote: I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. 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/ -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: Where to put new Callback and CallbackHandler classes
+1 to that! On 31 Aug 2006, at 18:25, Hiram Chirino wrote: I'm 100% behind making activeio an optional module. I'll start working on moving some core classes that are in activeio to activemq so that it is not needed to run. Right now the only real functionality that it provides that is optional is the journal implementation. Everything else that is use are just abstract interfaces, and I think those need to be moved/copied to ActiveMQ. 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/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
Need more +1s please :) -David On Aug 28, 2006, at 5:34 PM, David Blevins wrote: http://issues.apache.org/jira/browse/GERONIMO-2358 Back in I think March, I created a branch for implementing the Java EE 5 specs while the specs were still being defined. The specs went final in May and several projects need these specs. We need to get them out of the experimental branch and into trunk. The attached patch moves the required specs from branches/jee5_exp to trunk/ and fixes their poms to be consistent with the rest of the poms. Please note: patch files created with svn cannot express 'svn move' commands, in order to apply this patch you must first do the following moves: svn mv branches/jee5_exp/geronimo-jta_1.1_spec trunk/geronimo- jta_1.1_spec svn mv branches/jee5_exp/geronimo-spec-annotation trunk/geronimo- annotation_1.0_spec svn mv branches/jee5_exp/geronimo-spec-ejb trunk/geronimo-ejb_3.0_spec svn mv branches/jee5_exp/geronimo-spec-interceptor trunk/geronimo- interceptor_3.0_spec svn mv branches/jee5_exp/geronimo-spec-jpa trunk/geronimo-jpa_3.0_spec -David
Re: [VOTE] Release car-maven-plugin 1.1
+1 -David On Aug 29, 2006, at 2:22 AM, Guillaume Nodet wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. As stated in a previous proposal, I have forked the car-maven- plugin from trunk to branches/1.1 and updated it to use 1.1 binaries and to generate 1.1 plugins. Hence, I start this vote to publish the 1.1 version of this plugin. The binaries are available at http://people.apache.org/~gnodet/car-maven-plugin-1.1/org/apache/ geronimo/plugins/car-maven-plugin/1.1/ and the site has been deployed at http://geronimo.apache.org/maven/car-maven-plugin-1.1/ I will upload and sign these binaries on the m2-ibiblio-rsync- repository, once this vote is over. Btw, I have uploaded the site at people.apache.org:/www/ geronimo.apache.org/maven/car-maven-plugin-1.1/ but I have been unable to browse it and I did make sure the permissions were ok. If someone has any hints on how to make it accessible ... -- Cheers, Guillaume Nodet
[jira] Resolved: (SM-562) Unable to start due to missing lib/optional directory
[ https://issues.apache.org/activemq/browse/SM-562?page=all ] Guillaume Nodet resolved SM-562. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Unable to start due to missing lib/optional directory - Key: SM-562 URL: https://issues.apache.org/activemq/browse/SM-562 Project: ServiceMix Issue Type: Bug Affects Versions: 3.0-M2 Environment: Window 2000 Reporter: Bruce Appleton Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.0-M3 Attachments: servicemixbug.txt Installing as per directions in http://incubator.apache.org/servicemix/getting-started.html#GettingStarted-StartingServiceMix When starting the servicemix batch file from cd [servicemix_install_dir]\bin I get a FileNotFoundException for the \lib\optional directory (see attachment). When I add the optional directory from servicemix-1.0-M1 servicemix does start up. -- 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: servicemix-http and normalization
Guillaume Nodet wrote: The binding model should only be built on top of the wsdl for the current HttpEndpoint (either consumer or provider). This WSDL can be explicitely set, or may be auto-generated using the target endpoint WSDL. If the WSDL is provided, there is nothing to do, but if the WSDL is generated, we have to: * check if there is any existing binding infos (for example, if the target endpoint is a soap provider). In this case, we should use the binding informations * else, we need a flag on the http endpoint to set the binding style (rpc / doc). If the user need to provide a more detailed binding, then he has to provide it in the wsdl. Ok, that clarifies it. I'm trying to abstract the SoapBindingModel a bit more to be able to easily handle a plain HTTP binding. WSDL 2.0 bindings will require another reformat later i guess. Cool! I might be able to help with WSDL 2.0 as well. thanks, alex
[jira] Resolved: (SM-563) service unite declaration orderi in jbi.xml does not correspond to the service assembly pom
[ https://issues.apache.org/activemq/browse/SM-563?page=all ] Philip Dodds resolved SM-563. - Fix Version/s: 3.0-M3 Resolution: Fixed Fix for SM-563 - its not pretty but it does work - basically the maven-project is not maintaining the order of the dependencies on the model - therefore we re-parse the model to get it back to its original state and thus back in the correct order. This issue with Maven has been fixed and should be available in 2.0.5 (commented the code to note this). service unite declaration orderi in jbi.xml does not correspond to the service assembly pom --- Key: SM-563 URL: https://issues.apache.org/activemq/browse/SM-563 Project: ServiceMix Issue Type: Bug Components: tooling Affects Versions: incubation Reporter: Raffaele Spazzoli Fix For: 3.0-M3 Attachments: sample-sa.zip I declare the following ordering in service assembly pom: 1,2,3,4 and the generated jbi.xml has the following order 1,4,3,2 This is a problem when there are dependencies between service unit. I think the jbi maven plugin can be fixed to preserve the order, nevertheless I suggest to use maven dependency mechanism to deduct the right order. So if su2 depends on su1 in its pom there should be dependency to su1 just there is a dependcy to its component. I attach the example that gives the error to me. Note that: 1. you'll find a referred component that I'm developing so the project is non deployable. Should not be necessary to debug. 2. I don't use the dependecy form su to component, but the property declaration. The dependency give me problems that I still don't understand. -- 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: Is jetty broken in latest snapshots?
jsolderitsch wrote: I have tried both the August 29 and August 30 binary snapshots. With 3.0M2, I see a log message reporting jetty starting up. I can reach a port 8192 url as expected. With the snapshots, I see no such messages, and any attempt to reach a url on my servicemix machine with port 8192 results in a can't conect to server message. If this is a known issue, which snapshot has a working jetty integration? Jim I really need some advice here. I saw in another post that jetty is supposed to start automatically if you use an http su. My service assembly DOES include such an su. With 3.0M2, deploying my sa causes jetty to start as expected. With the last 3 days snapshots, this is NOT the case. A deployment that works just fine with 3.0M2 now fails to work. I learned that you can force jetty to start with the proper servicemix configuration entry. But I need an example of the syntax I need to add to servicemix.xml or servicemix.conf to make this happen. Any reason why the startup behavior with the snapshots is different than the last milestone? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Is jetty broken in latest snapshots?
I do not see any reasons. I have tested the samples and they work. Could you paste the content of your SU and the console log ? On 8/31/06, jsolderitsch [EMAIL PROTECTED] wrote: jsolderitsch wrote: I have tried both the August 29 and August 30 binary snapshots. With 3.0M2, I see a log message reporting jetty starting up. I can reach a port 8192 url as expected. With the snapshots, I see no such messages, and any attempt to reach a url on my servicemix machine with port 8192 results in a can't conect to server message. If this is a known issue, which snapshot has a working jetty integration? Jim I really need some advice here. I saw in another post that jetty is supposed to start automatically if you use an http su. My service assembly DOES include such an su. With 3.0M2, deploying my sa causes jetty to start as expected. With the last 3 days snapshots, this is NOT the case. A deployment that works just fine with 3.0M2 now fails to work. I learned that you can force jetty to start with the proper servicemix configuration entry. But I need an example of the syntax I need to add to servicemix.xml or servicemix.conf to make this happen. Any reason why the startup behavior with the snapshots is different than the last milestone? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: Anyone know how to make the kernel tests be quiet?
Ya, I'm not sure that surefire has support for that :-( --jason On Aug 31, 2006, at 6:35 AM, anita kulshreshtha wrote: In M1 there was a way to say swallow ouput. I can not find a reference to it. But trying.. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: I'm not sure how they were quiet before m2 with code like above in setUp(). --jason On Aug 28, 2006, at 4:29 PM, Jason Dillon wrote: Thats odd, because the default logging config is set to only allow WARN and ERROR to go to console, not DEBUG. Do these tests need to: GeronimoLogging.initialize(GeronimoLogging.INFO); Or something? --jason On Aug 28, 2006, at 10:14 AM, Dain Sundstrom wrote: Not me. They were quiet before the m2 change but it looks like logging got turned up. -dain On Aug 28, 2006, at 2:26 AM, Jason Dillon wrote: These tests make way... way to much noise. Anyone know how to make them shut up? --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
Yes I know that, and I changed it to ${basedir}/target on purpose.
--jason
On Aug 31, 2006, at 6:49 AM, anita kulshreshtha wrote:
One more thing..
In m1 the jvm was forked from basedir, hence we have all the file
references as target/
http://maven.apache.org/maven-1.x/plugins/test/properties.html
So we should modify all the tests to not used target!
Thanks
Anita
--- anita kulshreshtha [EMAIL PROTECTED] wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, target/login-audit.log);
instead of
File auditlog = new File(target/login-audit.log);
The relative file references in java are resolved using the
current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The workingDirectory specifies the dir the jvm is forked from.
If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File(login-audit.log);
This is the most natural way. WDYT?
Thanks
Anita
--- Jason Dillon (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all
]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security ::
**/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2
build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting
to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the
patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped
to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from
stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from
starting
to running
DEBUG [main]
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
No, the BASEDIR rooting is important, as we can not always control
the basedir that the tests are executed from. Tests are not just run
from maven, but also from IDE's.
It is a good practice to always root your files in tests... and this
is why I changed them to use BASEDIR.
--jason
On Aug 31, 2006, at 6:00 AM, anita kulshreshtha wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, target/login-audit.log);
instead of
File auditlog = new File(target/login-audit.log);
The relative file references in java are resolved using the current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The workingDirectory specifies the dir the jvm is forked from. If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File(login-audit.log);
This is the most natural way. WDYT?
Thanks
Anita
--- Jason Dillon (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from stopped to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped
to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from starting
to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModuleUse State changed from
stopped to
Re: Is jetty broken in latest snapshots?
gnodet wrote: I do not see any reasons. I have tested the samples and they work. Could you paste the content of your SU and the console log ? On 8/31/06, jsolderitsch [EMAIL PROTECTED] wrote: jsolderitsch wrote: I really need some advice here. I saw in another post that jetty is supposed to start automatically if you use an http su. My service assembly DOES include such an su. With 3.0M2, deploying my sa causes jetty to start as expected. With the last 3 days snapshots, this is NOT the case. A deployment that works just fine with 3.0M2 now fails to work. I learned that you can force jetty to start with the proper servicemix configuration entry. But I need an example of the syntax I need to add to servicemix.xml or servicemix.conf to make this happen. Any reason why the startup behavior with the snapshots is different than the last milestone? Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086662 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet I am sending the xbean and jbi xml files via private email. I hope they can suggest what my problem could be? There is a change from 3.0M2 that is rather severe. Could this be a platform issue -- are you using Windows XP to test this? I am not using Windows here. Jim -- View this message in context: http://www.nabble.com/Is-jetty-broken-in-latest-snapshots--tf2191258.html#a6086959 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Created: (GERONIMO-2369) Need to set db2 port to 50000 in the ra.xml for tranql db2 xa wrapper
Need to set db2 port to 5 in the ra.xml for tranql db2 xa wrapper - Key: GERONIMO-2369 URL: http://issues.apache.org/jira/browse/GERONIMO-2369 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 1.1 Environment: winxp Reporter: Lin Sun Priority: Minor In the ra.xml for the tranql db2 xa wrapper. it has: config-property description Specifies the port number the remote database server is listening on for incoming connections. The default for a DB2 server is 5. /description config-property-namePortNumber/config-property-name config-property-typejava.lang.Integer/config-property-type /config-property Since the default port for db2 server is 5, we should add the following line above the /config-property line. config-property-value5/config-property-value If this isn't added, and someone forgot to put a port when creating a db2 xa database pool, the pool will be unusable as it is defaulted to port 446. -- 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: Restructuring trunk, then next steps
On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. rant I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. /rant Do I understand correctly that with this proposal what is currently modules/geronimo-j2ee-builder would become system/geronimo-j2ee/geronimo-j2ee-builder and what is currently modules/geronimo-j2ee would become system/geronimo-j2ee/geronimo-j2ee? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a crude stab meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of modules or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the server, modules here should have minimal deps * system - the major components which make up the server's system (should be the bits to start up a server shell) * tools - bits that support the system * plugins - components which plugin to the system * testsuite - placeholder for modules which will be aded soon that use the itest plugin to perform integration tests I'm not sure if this is the best split, but it kinda comes closer to what I hope we can get to. Below is how the modules that exists fit into these sections. framework/
[jira] Updated: (GERONIMO-2369) Need to set db2 port to 50000 in the ra.xml for tranql db2 xa wrapper
[ http://issues.apache.org/jira/browse/GERONIMO-2369?page=all ] Lin Sun updated GERONIMO-2369: -- Attachment: G2369.patch Need to set db2 port to 5 in the ra.xml for tranql db2 xa wrapper - Key: GERONIMO-2369 URL: http://issues.apache.org/jira/browse/GERONIMO-2369 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1 Environment: winxp Reporter: Lin Sun Priority: Minor Attachments: G2369.patch In the ra.xml for the tranql db2 xa wrapper. it has: config-property description Specifies the port number the remote database server is listening on for incoming connections. The default for a DB2 server is 5. /description config-property-namePortNumber/config-property-name config-property-typejava.lang.Integer/config-property-type /config-property Since the default port for db2 server is 5, we should add the following line above the /config-property line. config-property-value5/config-property-value If this isn't added, and someone forgot to put a port when creating a db2 xa database pool, the pool will be unusable as it is defaulted to port 446. -- 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] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431957
]
Jason Dillon commented on GERONIMO-2352:
These war's don't need jspc... the problem you saw was because the root pom
configures war's to assume that they are to be used with jspc by default... and
I even have some comments to remove that.
The fix is simiple though...
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webXml${pom.basedir}/src/main/webapp/WEB-INF/web.xml/webXml
/configuration
/plugin
{code}
I will eventually reconfigure the default war plugin to not assume its being
used with jspc.
j2ee-builder test deployment modules won't actually deploy
--
Key: GERONIMO-2352
URL: http://issues.apache.org/jira/browse/GERONIMO-2352
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Bill Dudney
Assigned To: Jason Dillon
Attachments: GERONIMO-2352.bdudney.patch
The ear/war/ejb-jar/rar files wont actually deploy to the server.
I have a partial patch avalible but I'd like to get some discussion going on
how to fix some of the problems, that is happening in the dev list.
I will post the complete patch here when that discussion is wrapped up.
--
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: Standard for serialVersionUID
On Aug 31, 2006, at 8:34 AM, Heinz Drews wrote: Just as clarification, in the approach with the version number it was not changed with each modification. Only if a change was causing an impact to the serialized version. I think that is the general point... only change the version when the serialized form changes... else it does not change. --jason
Re: windows build hell
Dain has already tried adding getName() and he reports it works...
though I am not sure what value he returned. Try changing it to
return foo; and see if it works.
Or ping Dain... this issue has been broke for far too long, why
doesn't someone from openejb just add this method... Dain?!?!
--jason
On Aug 31, 2006, at 8:51 AM, Joe Bohn wrote:
Jason,
I'm not sure just adding getName() will fix the openejb test
problem. See my earlier post:
http://marc.theaimsgroup.com/?l=geronimo-devm=115680051431478w=2
Joe
Jason Dillon wrote:
If using 1.4.5-SNAPSHOT fixes things... then lets just use it.
Can someone with openejb2 commit privs add a getName() to get
past that other error too?
--jason
On Aug 30, 2006, at 8:46 AM, Jeff Genender wrote:
Joe Bohn wrote:
2) JSP compilation errors
Problem:
Embedded error: Unable to compile class for JSP
Strange error message about JAVA_HOME, etc...
Possible Solution/Work-around:
Update the pom.xml in the root directory to use version 1.4.5-
SNAPSHOT
(from 1.4.4) for the jspc-maven-plugin. Not sure if Jeff
Genender is
planning to make 1.4.5 an official release for this. We're not
sure why
it gets us around the problem so it may be a red herring.
Its not a red herring. It gets you around the problem because
in 1.4.5
I actually hunt down the tools.jar file...in a similar fashion as
done
in Ant when running the jspc complier from there. i.e.:
taskdef classname=org.apache.jasper.JspC name=jasper2
classpath
pathelement location=${java.home}/../lib/tools.jar/
...
I have to duplicate that in code. That's why 1.4.5 works.
The release is under vote. So far no -1s. I think I will be
able to
release it today as the 72 hours is up. I'll let this list know
when I
have released it.
Jeff
Re: [jira] Closed: (GERONIMO-2211) Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
FYI, I'd rather add a resolveFile() and resolvePath() to TestSupport
so that tests don't need to muck with File().getPath() and such.
--jason
On Aug 31, 2006, at 12:48 PM, Jason Dillon wrote:
No, the BASEDIR rooting is important, as we can not always control
the basedir that the tests are executed from. Tests are not just
run from maven, but also from IDE's.
It is a good practice to always root your files in tests... and
this is why I changed them to use BASEDIR.
--jason
On Aug 31, 2006, at 6:00 AM, anita kulshreshtha wrote:
I have always wondered why we need to do this:
File auditlog = new File(BASEDIR, target/login-audit.log);
instead of
File auditlog = new File(target/login-audit.log);
The relative file references in java are resolved using the
current
user dir, given by the system property user.dir, and is typically the
directory in which the Java virtual machine was invoked.
The workingDirectory specifies the dir the jvm is forked
from. If
it is set to {basedir}/target by default, then all the tests should
just use:
File auditlog = new File(login-audit.log);
This is the most natural way. WDYT?
Thanks
Anita
--- Jason Dillon (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2211?page=all ]
Jason Dillon closed GERONIMO-2211.
--
Resolution: Fixed
Thanks Anita for pointing out that it works with basedir, the
reference to the login-audit.log was not being rooted with BASEDIR.
Looks okay now, so I'm enabling this test again.
Enable tests (geronimo-security :: **/ConfigurationEntryTest.java)
--
Key: GERONIMO-2211
URL:
http://issues.apache.org/jira/browse/GERONIMO-2211
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
A few tests failed in non-obvious ways when run under the m2 build.
Need someone who knows these tests better to inspect, resolve and
enable the test (remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
DEBUG [main] Starting boot
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
geronimo/boot/none/car?role=kernel State changed from starting to
running
DEBUG [main] Booted
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from stopped to starting
DEBUG [main] GBeanInstanceState for: test/foo/1/car?name=ServerInfo
State changed from starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from stopped to
starting
DEBUG [main] Installed Geronimo login configuration
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?new=LoginConfiguration State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=TestLoginService State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
stopped to starting
DEBUG [main] Remote login service started on: tcp://0.0.0.0:4242
clients can connect to: tcp://0.0.0.0:4242
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=JaasLoginServiceRemotingServer State changed
from
starting to running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
stopped to starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=client-ConfigurationEntry State changed from
starting to running
DEBUG [main] Added Application Configuration Entry
properties-client
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesSecurityRealm State changed from
stopped to starting
DEBUG [main] Waiting to start
test/foo/1/car?name=PropertiesSecurityRealm because no targets are
running for reference LoginModuleConfiguration matching the patterns
test/foo/1/car?name=PropertiesLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from stopped to
starting
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModule State changed from starting to
running
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=AuditLoginModuleUse State changed from
stopped to
starting
DEBUG [main] Waiting to start
test/foo/1/car?name=AuditLoginModuleUse because no targets are
running for reference Next matching the patterns
test/foo/1/car?name=UPCredLoginModuleUse
DEBUG [main] GBeanInstanceState for:
test/foo/1/car?name=PropertiesLoginModule State changed from stopped
to starting
DEBUG [main]
Re: Restructuring trunk, then next steps
wow, nice rant ;) To be correct it is an API problem in windows that path names are restricted to 254 or 260 chars (Win2k), it's not an NTFS problem. You can create pathes with more characters when using UNC names. The limitation should be 32767 chars. If you have already a base path for the sources, you can share this path e.g. d:\home\tweety\wrk\java\geronimo as windows share and map it as drive p: for example. Now change to the mapped drive and do what you want with the path until he is 254 chars long. With that path example you save about 30 characters. Thanks, Mario Jason Dillon wrote: On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. rant I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. /rant Do I understand correctly that with this proposal what is currently modules/geronimo-j2ee-builder would become system/geronimo-j2ee/geronimo-j2ee-builder and what is currently modules/geronimo-j2ee would become system/geronimo-j2ee/geronimo-j2ee? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a crude stab meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of modules or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I took a few minutes and took a crude stab at what that might look like. This is just an example of how it might work... I did not do any extensive research into dependencies... Basically, I split things up into 5 main trees: * framework - common stuff, not really the server, but supports the
Re: Restructuring trunk, then next steps
Ok ... take a deep breath. This proposal was *not* just to work around windows. It was to offer what I thought were constructive ideas and avoid exasperating a known problem unnecessarily. I understand your hesitation to bundle the builders and deployers together (which is why I had a note there). What do you think about the rest of the proposal? - Type based groupings in addition to functional groupings. - One level deep. While I love hierarchy, I think it's overkill here. - Elimination of redundancy in names as much as possible. (BTW, I know your post was a crude stab so I thought this was the type of input you were requesting to refine it). - server in place of system - features in place of plugins - Consistent naming of artifacts when the type is included in the name (such as with builder and deployer). Joe Jason Dillon wrote: On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote: I'd like to propose that we keep things simple and eliminate redundancy where possible. I'd also like to keep things as brief as possible to prevent current or future issues with the windows pathlength issue. I don't think the proposed changes will cause immediate problems but I'd like to prevent/reduce the possibility of problems. rant I really, really, really don't like to be restricted by the limitations of a certain lame operating system... in fact it fills me with rage. If windows still had 8.3 file name limitations... would we have to make ever class conform to that naming system?! Windows is also case insensitive, so should we use all UPPER CASE FILES TO AVOID conflicting files? Windows stuff crashed all of the time... do we add some hooks to cause the server to crash just to fit in?!? I am sorry your OS is retarded... but I see no reason to design the build structure based on its limitations... especially if a different layout make more sense to group logical modules together. /rant Do I understand correctly that with this proposal what is currently modules/geronimo-j2ee-builder would become system/geronimo-j2ee/geronimo-j2ee-builder and what is currently modules/geronimo-j2ee would become system/geronimo-j2ee/geronimo-j2ee? If so, then I think we are introducing some unnecessary redundancy once again. No, we would not end up with system/geronimo-j2ee/geronimo-j2ee. As I mentioned this was a crude stab meaning that I did not take much time to clean up, just put out the basic high level organization groups and filled in the current modules. BTW, do I understand correctly that you're proposing the removal of modules or is this presumed to be prior to each of the new names? Yes, modules is to be removed. I wondering if it might be better to have more types and less subtypes (perhaps deciding to have only a single collection of types with no subtypes at all). Perhaps something like: builders/ (not sure yet if I like this myself :-) ) geronimo-j2ee-builder geronimo-service-builder geronimo-axis-builder geronimo-tomcat-builder geronimo-jetty-builder geronimo-security-builder geronimo-service-builder geronimo-connector-builder geronimo-naming-builder geronimo-client-builder geronimo-j2ee-builder geronimo-web-builder I had thought about grouping the builders together... though I'm still drawn about if these should be closer to their code modules or not. Generally I'd like to have all of the tomcat integration code together, all the jetty code together and so on... --jason ** Note, the way we name builders and the way we name deployers is inconsistent. I think we need to decide if we want the descriptive type first or last in these names and use the pattern consistently. deployers/ geronimo-deploy-core (was geronimo-deployment) ? geronimo-deploy-config geronimo-deploy-jsr88 geronimo-deploy-tool geronimo-deploy-hot (was geronimo-hot-deploy ... just to be consistent with other deployers but see note above) ? framework/ geronimo-testsupport geronimo-test-ddbean (not sure what this is either) geronimo-common geronimo-util geronimo-interceptor geronimo-activation geronimo-kernel server/ geronimo-management geronimo-security geronimo-core geronimo-system geronimo-transaction geronimo-connector geronimo-jmx-remoting geronimo-naming geronimo-client geronimo-j2ee geronimo-j2ee-schema features/ geronimo-activemq-rar (rename) geronimo-activemq-gbean geronimo-activemq-gbean-management geronimo-axis geronimo-derby geronimo-directory geronimo-tomcat geronimo-jetty geronimo-mail geronimo-timer geronimo-webservices tools/ geronimo-upgrade geronimo-converter Joe Jason Dillon wrote: So, I've mentioned a few times before that we should start thinking about how to split up modules in trunk into a few smaller chunks. I
[jira] Commented: (GERONIMO-2349) jta 1.1 support with container manager jpa support in transaction module
[ http://issues.apache.org/jira/browse/GERONIMO-2349?page=comments#action_12431976 ] Jacek Laskowski commented on GERONIMO-2349: --- Hey Dave, I'm lost. I was about to +1 it, but then thought to give it a try and make it to the trunk. But I don't know what to apply. Would you care to comment on it a bit? jta 1.1 support with container manager jpa support in transaction module Key: GERONIMO-2349 URL: http://issues.apache.org/jira/browse/GERONIMO-2349 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: transaction manager Affects Versions: 1.2 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2 Attachments: GERONIMO-2349-1.patch, GERONIMO-2349-2.patch, GERONIMO-2349-3.patch, GERONIMO-2349-v4-plus-2163-openejb.patch, GERONIMO-2349-v4-plus-2163.patch, persistencecontextref.zip We need a strategy for supporting jta 1.1 and parts of jpa in the transaction module while still passing the j2ee 1.4 signature tests. Here's a proposal: - put the basis for support into the current transaction module, but don't use any jee5 interfaces - add an additional transaction-jta11 module that uses the new interfaces and extends the appropriate classes in transaction. I've started along this path. I'll put the new module in sandbox and supply a patch for the changes to the existing transaction module. -- 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: Classes in trunk
I agree... though they may be used by those tests... I am not sure, have not checked. And don't have time to do so at the moment. My guess is that if they are needed that we could either reuse one of the test-deployables (soon to be commited) or maybe we need to and a new one to fit the needs of that test.--jasonOn Aug 31, 2006, at 1:54 AM, Sergey Elin wrote:I think it should be removed from trunk...2006/8/30, Jason Dillon [EMAIL PROTECTED]: I dunno... but seems like a bad idea.--jasonOn Aug 29, 2006, at 12:13 AM, Sergey Elin wrote: Hi, there is a number of class files in trunk. Any reasons for it? ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet1.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter1.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Servlet2.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war4/WEB-INF/classes/org/apache/geronimo/tomcat/app/Filter2.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/mx4j/MBeanDescription.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/javax/foo/Foo.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ cltest/javax/servlet/Servlet.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorld.class ./modules/geronimo-tomcat-builder/src/test/resources/deployables/ war5/WEB-INF/classes/org/apache/geronimo/ws/HelloWorldWS.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/mx4j/MBeanDescription.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/javax/foo/Foo.class ./modules/geronimo-jetty-builder/src/test/resources/deployables/ cltest/javax/servlet/Servlet.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/mx4j/ MBeanDescription.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/ javax/foo/Foo.class ./modules/geronimo-jetty/src/test/resources/deployables/cltest/ javax/servlet/Servlet.class
Re: Standard for serialVersionUID
On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: Are the new activemq gbean modules complete?
Has anyone else looked at this patch? I'd really like to get this committed... and we need some other peeps to review. --jason On Aug 29, 2006, at 1:02 PM, Hiram Chirino wrote: Hey Folks.. Here's a patch that update geronimo to run against amq 4: http://issues.apache.org/jira/browse/GERONIMO-2364 Some small little issues are left like the DLQ admin portlet is not updated to use the new amq APIS. Also a small exception is barfed at shutdown. But I want to move on to bigger issues like CTS testing. Anybody have a link to doco on how to get the cts tests going with the trunk version of Geronimo? It's been too long since I last did that. On 7/2/06, Hiram Chirino [EMAIL PROTECTED] wrote: Hi David.. That's still work that I've got on my plate to do. The # of gbeans have changed for activemq 4. So before we switch to amq 4 and the new gbean modules, I'll have to update lots of plans. Including the ones in the CTS I imagine. Regards, Hiram On 6/30/06, David Jencks [EMAIL PROTECTED] wrote: I got the new amq gbean modules to compile under m2 and tried to use them in the activemq-broker plan but there seem to be a lot more gbean classes in the plan than in the modules. What's going on? Is there a new way to configure all this stuff? thanks david jencks -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: [VOTE] Release XBean 2.6 (retry)
On 8/30/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. Hey Guillaume, I assume it's still tagged as xbean-2.6? Just updating and am about to build and find a couple of examples to give it a try. Asking in case it has changed. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[
http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431988
]
Jason Dillon commented on GERONIMO-2352:
What is up with the comments in {{geronimo-j2e-builder/pom.xml}}:
{quote}
need to remove the geronimo-application.xml file from this ear
{quote}
j2ee-builder test deployment modules won't actually deploy
--
Key: GERONIMO-2352
URL: http://issues.apache.org/jira/browse/GERONIMO-2352
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Reporter: Bill Dudney
Assigned To: Jason Dillon
Attachments: GERONIMO-2352.bdudney.patch
The ear/war/ejb-jar/rar files wont actually deploy to the server.
I have a partial patch avalible but I'd like to get some discussion going on
how to fix some of the problems, that is happening in the dev list.
I will post the complete patch here when that discussion is wrapped up.
--
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] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12431991 ] Bill Dudney commented on GERONIMO-2352: --- Hi Jason, That is the question I was asking about in question 2 here; http://www.nabble.com/j2ee-builder-tests--tf2155494.html#a6032026 Basically the tests expect an ear without a geronimo-application.xml I did not know of an easy way to get maven to strip a file from a jar. The ant build file took the content, jar'd it once with geronimo-application.xml and once with out. j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Reporter: Bill Dudney Assigned To: Jason Dillon Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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: Classes in trunk
On 8/29/06, Sergey Elin [EMAIL PROTECTED] wrote: there is a number of class files in trunk. Any reasons for it? Other than there're there for the tests? No. Seriously, there're in trunk as they're simply resources for tests (am I repeating myself?). [EMAIL PROTECTED] /cygdrive/c/oss/geronimo/modules/geronimo-tomcat-builder/src/test/resources/deployables/war4/WEB-INF/classes/org/apache/geronimo/tomcat/app $ svn log Servlet1.class ... r164651 | jgenender | 2005-04-25 23:09:26 +0200 (Mon, 25 Apr 2005) | 1 line New tomcat-builder Jeff added them likely to not have bothered to script their compilation and proper inclusion in the resources directories of these tests (Jeff? Are you reading this? ;-) ). I think you can go and improve it a little. Create a JIRA task and get rid of them. Let's fix it by creating their java sources and let Maven know about the change. Ready to give it a spin? Ask when in trouble. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I was going to create an issue and the commit the change if there were no objections. Don't give us a chance to RTC it? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. --jason On Aug 31, 2006, at 2:59 PM, Jacek Laskowski wrote: On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: I was going to create an issue and the commit the change if there were no objections. Don't give us a chance to RTC it? ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Build failure on branches/1.1.1 due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar
On 8/31/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Build is failing due to geronimo-j2ee-jacc_1.0_spec-1.1.1.jar unavailable in the repository. Has anyone else hit this error? Console output given below. Haven't checked it out, but seems that you need to co https://svn.apache.org/repos/asf/geronimo/specs/tags/1_1 and built it. It should've worked with no additional steps, though, I guess. I'd wait for Matt to comment on it. Perhaps we may need to publish them if they're not available anywhere. Don't know what Geronimo version the JIRA task to put in, though, when it's fixed (you will report the JIRA item, will you? ;-) ) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Standard for serialVersionUID
I will create a jira. Should there be a vote about the format of the uid? --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: Um... then what does Perm stand for? Permanent - it's not for GC to take care of. Once it's occupied, it will stay as such forever, once jvm stops. @see https://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html (I think I've read something nicer lately at java.sun.com, but can't find it now) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Standard for serialVersionUID
Eh... probably. --jason On Aug 31, 2006, at 3:17 PM, Heinz Drews wrote: I will create a jira. Should there be a vote about the format of the uid? --heinz On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: On Aug 31, 2006, at 7:01 AM, Zakharov, Vasily M wrote: Note however, that small values like 1 or 2 are traditionally used as serialVersionUIDs for synthetic and other system classes, like Enums and RMI Stubs, that are serialized in a special way. So using such values in normal classes may confuse the future readers of the code and make them wonder if that particular class is serialized in a special way. So I'm suggesting using traditional (20-digit or so) values for serialVersionUIDs. I think that using the short versions... 1, 2, 3, 4... is fine for any serializable. Its much easier to manage too and much easier to debug when mismatch problems arise, since you can see which version is older and how old... using the generated longass versions just shows you they are different, not which is older. --jason
Re: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: You most certainly do not need to use it to build Geronimo. It is only an attempt to automate several steps together. As I have said before, and I will undoubtedly say again, bootstrap is temporary and will be removed as soon as we have all of the dependency artifacts published and have a few maven bugs resolved. It may already have been answered, but can't find it and thus the question goes. Is there a JIRA issue that would let us track where we're at in the process of removing bootstrap? I mean, you seem to imply a bunch of steps before bootstrap itself gets whacked. They are subtasks for the main task - bootstrap removed as a build helper tool (no, I won't repeat the mantra about these tasks being helpful for others to track the status *and* help you out where/if possible ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote: A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. Well, we're still in the RTC hug and until it changes we need to obey the rules. On the other hand, if it's a trivial change, RTC is going to happen very quickly. Come on Jason, you did a great job of pushing the m2 changes out of the door (i.e. having applied them to trunk) and was profoundly patient and now you say you can't manage such a small change?! Can't be! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
You really want a diff of the root pom that changes the version to 10.1.3.1 to review? I can do that, but it seems like a waste of time... and abuse of the RTC concept. If no one objects to it, then why don't we just do it? Its a whopping 1 line change... which affects only 2 chars :-P --jason On Aug 31, 2006, at 3:31 PM, Jacek Laskowski wrote: On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote: A formal RTC... don't think that is needed... my plan was to post the topic to the list, and if no one objected, to create a tracker JIRA and the commit. I think that follows lazy-consensus... and IMO is all that is needed for a minor change like this. Well, we're still in the RTC hug and until it changes we need to obey the rules. On the other hand, if it's a trivial change, RTC is going to happen very quickly. Come on Jason, you did a great job of pushing the m2 changes out of the door (i.e. having applied them to trunk) and was profoundly patient and now you say you can't manage such a small change?! Can't be! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2370) Add serialVersionUID to all classes implementing Serializable
Add serialVersionUID to all classes implementing Serializable - Key: GERONIMO-2370 URL: http://issues.apache.org/jira/browse/GERONIMO-2370 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Environment: All Reporter: Heinz Drews Priority: Minor A number of serializable classes don't have a serialVersionUID specified. This introduces the risk that the generated uid might be diferent between different versions or vendors of JVMs -- 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: svn commit: r437291 - in /geronimo/server/trunk: bootstrap bootstrap.bat bootstrap.xml
No issue... * OpenEJB2 snaps need to be published by CI (needs G below) * G snaps to be published by CI (needs OpenEJB2 above) * specs/trunk need to be published * Maven needs to get MNG-1911 fixed And then at that point bootstrap will not be needed for normal use... may still want to keep it in to allow the clean repo bits to ensure that G still builds correctly and downloads artifacts though. --jason On Aug 31, 2006, at 3:24 PM, Jacek Laskowski wrote: On 8/31/06, Jason Dillon [EMAIL PROTECTED] wrote: You most certainly do not need to use it to build Geronimo. It is only an attempt to automate several steps together. As I have said before, and I will undoubtedly say again, bootstrap is temporary and will be removed as soon as we have all of the dependency artifacts published and have a few maven bugs resolved. It may already have been answered, but can't find it and thus the question goes. Is there a JIRA issue that would let us track where we're at in the process of removing bootstrap? I mean, you seem to imply a bunch of steps before bootstrap itself gets whacked. They are subtasks for the main task - bootstrap removed as a build helper tool (no, I won't repeat the mantra about these tasks being helpful for others to track the status *and* help you out where/if possible ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=all ] Jason Dillon updated GERONIMO-2352: --- Component/s: buildsystem Fix Version/s: 1.2 Affects Version/s: 1.2 j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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: [VOTE] Release XBean 2.6 (retry)
On 8/30/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I have uploaded new binaries of xbean. They are available at http://people.apache.org/~gnodet/xbean-2.6/ The changes from the last cut includes a fix for spring 2.0-rc3, and the Genesis dependency which has been removed. +1 Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
On 8/29/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. +0 (fortunatelly, Dave's in favor of it and there won't be a discussion about double +0's and no +1's) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
+1 Jacek On 8/29/06, David Blevins [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/GERONIMO-2358 Back in I think March, I created a branch for implementing the Java EE 5 specs while the specs were still being defined. The specs went final in May and several projects need these specs. We need to get them out of the experimental branch and into trunk. The attached patch moves the required specs from branches/jee5_exp to trunk/ and fixes their poms to be consistent with the rest of the poms. Please note: patch files created with svn cannot express 'svn move' commands, in order to apply this patch you must first do the following moves: svn mv branches/jee5_exp/geronimo-jta_1.1_spec trunk/geronimo- jta_1.1_spec svn mv branches/jee5_exp/geronimo-spec-annotation trunk/geronimo- annotation_1.0_spec svn mv branches/jee5_exp/geronimo-spec-ejb trunk/geronimo-ejb_3.0_spec svn mv branches/jee5_exp/geronimo-spec-interceptor trunk/geronimo- interceptor_3.0_spec svn mv branches/jee5_exp/geronimo-spec-jpa trunk/geronimo-jpa_3.0_spec -David -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (GERONIMO-2352) j2ee-builder test deployment modules won't actually deploy
[ http://issues.apache.org/jira/browse/GERONIMO-2352?page=comments#action_12432001 ] Jason Dillon commented on GERONIMO-2352: Okay, the test deployments are now hooked up to the main build. I'm going to apply the remaining changes from your patch to geronimo-j2ee-builder with some modifications to apply the m2 std layout, and to use the updated artifactIds for the deployment modules. j2ee-builder test deployment modules won't actually deploy -- Key: GERONIMO-2352 URL: http://issues.apache.org/jira/browse/GERONIMO-2352 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Reporter: Bill Dudney Assigned To: Jason Dillon Fix For: 1.2 Attachments: GERONIMO-2352.bdudney.patch The ear/war/ejb-jar/rar files wont actually deploy to the server. I have a partial patch avalible but I'd like to get some discussion going on how to fix some of the problems, that is happening in the dev list. I will post the complete patch here when that discussion is wrapped up. -- 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: JPA Plugin patch
On 8/31/06, Andrus Adamchik [EMAIL PROTECTED] wrote: Hi Aaron, finally got time to start poking around JPA plugin. I can compile it now, but it requires a patch below to build against the latest JPA spec. Not a big fan of SF issue tracker, so I simply put it on the web: http://people.apache.org/~aadamchik/jpa-plugin-patch.txt Hi Aaron and Andrus, The patch caught my attention and got me thinking about the plugin and where it's being developed. The first time I read it I thought why Andrus was asking that question here (yet complaining about SF issue tracker) since the plugin itself has been developed outside the project? (well, it's for the project, but it's not part of it, right?). I meant to have asked the question to Andrus, but then thought it's not him I should ask about it, but Aaron who *seem* to have made it hard(er) to understand where people should collaborate about stuff being developed outside, but still relevant to Geronimo. For me, it should've been asked in the used mailing list at most if not in the space it's being developed (in this case, it's SF). I think the question's already been asked, but will ask again since the plugin has drawn more attention. Aaron, why can't the plugin development be conducted here, in sandbox? Does it use a code not allowed to be in the Geronimo repo? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: RTC: Move java ee 5 specs into specs trunk (GERONIMO-2358)
On 8/31/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Btw, is there any plan to write jsr181 and jaxws api ? Quoted from http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html: JAX-WS 2.0 - An Axis 2.0 subproject has an implementation of JAX-WS. CeltiXfire has an implementation of JAX-WS. WS Metadata 2.0 (Annotations) (jsr181) - Axis 2 is using WS Metadata 2.0 originally from the Beehive project. CeltiXFire contains an implementation of WS Metadata 2.0. or to borrow them from another project ? Axis2 and CeltiXFire spring to my mind ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [VOTE] Release car-maven-plugin 1.1
I'll upgrade my vote to a +1... I'd rather not see this code move outside of the G tree. --jason On Aug 31, 2006, at 4:17 PM, Jacek Laskowski wrote: On 8/29/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This release goal is to provide a m2 plugin to create Geronimo 1.1 plugins. +0 (fortunatelly, Dave's in favor of it and there won't be a discussion about double +0's and no +1's) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Upgrade Derby to 10.1.3.1?
On 9/1/06, Jason Dillon [EMAIL PROTECTED] wrote: You really want a diff of the root pom that changes the version to 10.1.3.1 to review? Yes. I can do that, but it seems like a waste of time... and abuse of the RTC concept. As far as RTC rules' are concerned, each and every change needs to be reviewed before being committed and such a small change is no exception. Of course, a change != a fix. If no one objects to it, then why don't we just do it? Unless we decide how many lines are good to be committed without voting I'm THE one who objects. Its a whopping 1 line change... which affects only 2 chars :-P Do it and we're done. (I'm kicking myself for having myself involved in the thread ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
