date:20061218


All,

I have prepared 2.0-M1 for release.  Of course all the hard work was  
done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied  
with the results.  All modes of operation functioned well (SLSB,  
Direct, EJB and JPA).  I toned all the logs down to error to not  
overwhelm the users with lots of diagnostic output (they can always  
turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts trickle  
in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
for your review and testing.  I've included both Tomcat and Jetty as  
well as the minimal and j5ee assemblies.  The source code is also there.


Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  
do this is to modify the root pom and add a repository for David's  
home directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
and will be putting them into our SVN for folks who may want to build  
in the future.  I'm not too concerned about repeatability as this  
Milestone will be superseded at the end of January with the next  
version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine this  
build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new one  
will start.


Matt Hogstrom
[EMAIL PROTECTED]

High, Rob is out of the office.

2006-12-18 Thread Rob High





I will be out of the office starting  12/18/2006 and will not return until
01/02/2007.

I'm on vacation.

Re: svn commit: r488131 - /geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt

   Are we not including J2EE Management 1.1 in this list because of 
JSR77.3.5.0.1 - deploymentDescriptor?

Thanks
Anita

--- [EMAIL PROTECTED] wrote:

 Author: hogstrom
 Date: Sun Dec 17 21:53:00 2006
 New Revision: 488131
 
 URL: http://svn.apache.org/viewvc?view=revrev=488131
 Log:
 Added RELEASE notes to assembly
 
 Added:


geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt
   (with props)
 
 Added:

geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt
 URL:

http://svn.apache.org/viewvc/geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt?view=autorev=488131

==
 ---

geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt
 (added)
 +++

geronimo/server/branches/2.0-M1/assemblies/geronimo-boilerplate-minimal/src/main/resources/RELEASE-NOTES-2.0-M1.txt
 Sun Dec 17 21:53:00 2006
 @@ -0,0 +1,265 @@
 +Release Notes -- Apache Geronimo -- Version 2.0 - Milestone 1
 +
 +Geronimo URLs
 +-
 +Home Page: http://geronimo.apache.org/
 +Downloads: http://geronimo.apache.org/downloads.html
 +Documentation: http://geronimo.apache.org/documentation.html
 +Mailing Lists: http://geronimo.apache.org/mailing.html
 +Source Code:   http://geronimo.apache.org/svn.html
 +Bug Tracking:  http://issues.apache.org/jira/browse/GERONIMO
 +Wiki:  http://cwiki.apache.org/geronimo
 +
 +
 +IMPORTANT
 +-
 +This is a Milestone release, that means that is not the final
 version of
 +Apache Geronimo v2.0 Take a look at Known Issues and Limitations
 section for
 +further details.
 +
 +System Requirements
 +---
 +You need a platform that supports the Sun JDK 5.0+ (J2SE 1.5.0+).
 +
 +Most testing has been done on Linux, Mac OS X, and Windows.
 +
 +
 +Significant Changes in the 2.0 Release
 +--
 +Apache Geronimo v2.0 includes the following features:
 +
 +- Full Sun JDK 5.0+ (J2SE 1.5.0+)
 +- Servlet 2.5 (Tomcat)
 +- JSP 2.1 (Tomcat)
 +- JSP Debug 1.0 (Tomcat)
 +- Servlet 2.5 (Jetty)
 +- JSP 2.1 (Jetty - via Jasper)
 +- JSP Debug 1.0 (Jetty)
 +- JSF 1.2
 +- JSTL 1.2
 +- Common Annotations 1.0
 +- JAF 1.1
 +- JavaMail 1.4
 +- EJB 3.0 (JPA only)
 +- JTA 1.1
 +- JMS 1.1
 +- JACC 1.1
 +
 +Installing  Starting Geronimo
 +--
 +To install, simply unpack the .zip (Windows) or tar.gz (Unix) file
 containing 
 +Geronimo.
 +
 +If you wish to modify the default ports that Geronimo will use, edit
 the file 
 +geronimo_home/var/config/config.xml
 +
 +Geronimo comes with batch and script files to control server start
 and stop 
 +functions.  To see usage examples simply type geronimo.bat or
 geronimo.sh 
 +command as appropriate for your platform.  It is necessary to set
 JAVA_HOME to 
 +the copy of your Sun 5 JDK/JRE prior to executing the command.  
 +
 +Here is an example to set JAVA_HOME:
 +
 +export JAVA_HOME=JDK/JRE_home
 +
 +To see the available command options type:
 +
 +geronimo_home/bin/geronimo.sh
 +or
 +geronimo_home/bin/geronimo.bat
 +
 +The command will display help text instructing you as to how to
 start and stop 
 +the Geronimo server.
 +
 +If you prefer to start the server without a script file you can
 simply type: 
 +
 +java -jar geronimo_home/bin/server.jar
 +
 +Once the server has started, you can access the Geronimo
 Administration Console
 +at http://localhost:8080/console/ . The default user name is
 system and the 
 +default password is manager.
 +
 +
 +Administration Console Security Configuration
 +-
 +The default administration user/password for the Geronimo
 Administration Console 
 +and deployment tool is system/manager.  You can change these
 defaults directly 
 +from the Geronimo Administration Console by accessing Security -
 Console Realm
 +and change the user name and password from the Console Realm Users
 portlet.
 +
 +As an alternative, you can make the same changes by editing the 
 +geronimo_home/var/security/users.properties and 
 +geronimo_home/var/security/groups.properties files.
 +
 +
 +Deploying Applications
 +--
 +Geronimo comes with deploy scripts and batch files to deploy J2EE
 modules or 
 +applications. You can use the scripts or simply invoke the
 executable jar by 
 +running the following command (note that you need to start Geronimo
 first):
 +
 +geronimo_home/bin/java -jar deployer.jar deploy my-web-app.war
 [deploy plan]
 +
 +You will need to use the username system and password manager
 unless you 
 +customized those during the install process.  The deployment plan
 argument is 
 +optional -- you can pack a deployment plan into the application
 module, provide
 +it on the command line, or in some

[jira] Created: (SM-781) Re: Bug in ScritpComponent when using script attribute

2006-12-18 Thread Andrea Zoppello (JIRA)

Re: Bug in ScritpComponent when using script attribute


 Key: SM-781
 URL: https://issues.apache.org/activemq/browse/SM-781
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-components
Affects Versions: 3.0
Reporter: Andrea Zoppello


When the script component is configured using the script attribute instead of 
scriptText attribute the components doesn't work.

For example:
   sm:activationSpec componentName=myGenericGroovymioGroovy 
service=foo:myGenericGroovymioGroovy
destinationService=*foo:myScreenOutputmioGroovy*
  sm:component
   bean
class=org.apache.servicemix.components.groovy.GroovyComponent
  property name=script
value=c:/tmp/sm/groovy/testsmx.groovy /
/bean
  /sm:component
/sm:activationSpec

fails with message: If no 'compiledScript' is specified you must specify the 
'scriptText'

The problems seems to be in the start() method of  
org.apache.servicemix.components.script.ScriptComponent class.
in the following lines:

 if (compiledScript == null) {
checkScriptTextAvailable();
}
if (compiledScript == null) {
if (engine instanceof Compilable) {
Compilable compilable = (Compilable) engine;
compileScript(compilable);
}
}


I've replaced this code with the code below  and it works correctly:

.
if ((compiledScript == null)  (script != null)) {
if (engine instanceof Compilable) {
Compilable compilable = (Compilable) engine;
compileScript(compilable);
}
}
if (compiledScript == null) {
checkScriptTextAvailable();
}
. 
  


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

[jira] Updated: (SM-781) Re: Bug in ScritpComponent when using script attribute

2006-12-18 Thread Andrea Zoppello (JIRA)

 [ https://issues.apache.org/activemq/browse/SM-781?page=all ]

Andrea Zoppello updated SM-781:
---

Attachment: ScriptComponent.java.diff

The file attached is the patch proposed to resolve the problem described

 Re: Bug in ScritpComponent when using script attribute
 

 Key: SM-781
 URL: https://issues.apache.org/activemq/browse/SM-781
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-components
Affects Versions: 3.0
Reporter: Andrea Zoppello
 Attachments: ScriptComponent.java.diff


 When the script component is configured using the script attribute instead 
 of scriptText attribute the components doesn't work.
 For example:
sm:activationSpec componentName=myGenericGroovymioGroovy 
 service=foo:myGenericGroovymioGroovy
 destinationService=*foo:myScreenOutputmioGroovy*
   sm:component
bean
 class=org.apache.servicemix.components.groovy.GroovyComponent
   property name=script
 value=c:/tmp/sm/groovy/testsmx.groovy /
 /bean
   /sm:component
 /sm:activationSpec
 fails with message: If no 'compiledScript' is specified you must specify the 
 'scriptText'
 The problems seems to be in the start() method of  
 org.apache.servicemix.components.script.ScriptComponent class.
 in the following lines:
 
  if (compiledScript == null) {
 checkScriptTextAvailable();
 }
 if (compiledScript == null) {
 if (engine instanceof Compilable) {
 Compilable compilable = (Compilable) engine;
 compileScript(compilable);
 }
 }
 
 I've replaced this code with the code below  and it works correctly:
 .
 if ((compiledScript == null)  (script != null)) {
 if (engine instanceof Compilable) {
 Compilable compilable = (Compilable) engine;
 compileScript(compilable);
 }
 }
 if (compiledScript == null) {
 checkScriptTextAvailable();
 }
 . 
   

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

[jira] Closed: (GERONIMO-2669) fix o.a.g.j.ClusteredSessionManager to match changes in Jetty AbstractSessionManager

2006-12-18 Thread Gianny Damour (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2669?page=all ]

Gianny Damour closed GERONIMO-2669.
---

Fix Version/s: 2.0-M2
   (was: 2.0)
   Resolution: Fixed

Thanks for having fixed the build and opened this JIRA David.

I have reviewed and done some integration testings. Load-balancing and session 
replications are working with Jetty6.

 fix o.a.g.j.ClusteredSessionManager to match changes in Jetty 
 AbstractSessionManager
 

 Key: GERONIMO-2669
 URL: http://issues.apache.org/jira/browse/GERONIMO-2669
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Jetty
Affects Versions: 2.0
Reporter: David Jencks
 Assigned To: Gianny Damour
 Fix For: 2.0-M2


 Recent changes in jetty's AbstractSessionManager break the geronimo-jetty6 
 module build.  I'm committing something that compiles and lets the console 
 run (unclustered) but this needs some attention from someone who knows what 
 is going on.

-- 
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] 2.0-M1 Release

2006-12-18 Thread Sachin Patel


Looks good. +1.

On Dec 18, 2006, at 3:57 AM, Matt Hogstrom wrote:


All,

I have prepared 2.0-M1 for release.  Of course all the hard work  
was done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm  
satisfied with the results.  All modes of operation functioned well  
(SLSB, Direct, EJB and JPA).  I toned all the logs down to error to  
not overwhelm the users with lots of diagnostic output (they can  
always turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts  
trickle in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
for your review and testing.  I've included both Tomcat and Jetty  
as well as the minimal and j5ee assemblies.  The source code is  
also there.


Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  
do this is to modify the root pom and add a repository for David's  
home directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
and will be putting them into our SVN for folks who may want to  
build in the future.  I'm not too concerned about repeatability as  
this Milestone will be superseded at the end of January with the  
next version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine  
this build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new  
one will start.


Matt Hogstrom
[EMAIL PROTECTED]





-sachin

Re: [VOTE] 2.0-M1 Release



On Dec 18, 2006, at 3:57 AM, Matt Hogstrom wrote:

Please review and cast your vote early.  The faster we determine  
this build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new  
one will start.


There's a source file missing a license header. Not sure if it was  
added after my last scan of the code or if I just missed it. Anyway,  
it needs to be fixed.


All servers start. I'm getting some [info] log messages sent to  
STDOUT, but I don't think that should hold up an M1 release.


I've scanned the jetty java ee5 binary -- looks good. Working on  
tomcat and some more sanity checks. Other that the license header,  
things look good...


--kevan

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Jeff Genender

+1

Matt Hogstrom wrote:
 All,
 
 I have prepared 2.0-M1 for release.  Of course all the hard work was
 done by the lot of y'all :)
 
 I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied
 with the results.  All modes of operation functioned well (SLSB, Direct,
 EJB and JPA).  I toned all the logs down to error to not overwhelm the
 users with lots of diagnostic output (they can always turn it up later
 if they want.)
 
 The uploads are taking forever so you'll see some piece parts trickle
 in.  For the review I expect you'll want to focus on
 http://people.apache.org/~hogstrom/2.0-M1 as this contains the
 assemblies for your review and testing.  I've included both Tomcat and
 Jetty as well as the minimal and j5ee assemblies.  The source code is
 also there.
 
 Note that if you are planning on building you'll need to obtain the
 openejb-2.2-incubating jars to your local repo.  The easiest way to do
 this is to modify the root pom and add a repository for David's home
 directory at http://people.apache.org/~dblevins/stage/.
 
 For SNAPSHOTs of certain plugins I have resolved these files to the most
 recent SNAPSHOT date / timestamp.  I'm pulling a copy of these and will
 be putting them into our SVN for folks who may want to build in the
 future.  I'm not too concerned about repeatability as this Milestone
 will be superseded at the end of January with the next version.
 
 The other MAven artifacts will be trickling onto people across my
 horribly slow home pipe and dropped into
 http://people.apache.org/~hogstrom/stage over the next few hours.
 
 Please review and cast your vote early.  The faster we determine this
 build is good or if there is an issue the better.
 
 Thanks in advance for all your help in this effort.
 
 This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members
 vote quicker :)
 
 If a respin is is necessary this vote will be suspended and a new one
 will start.
 
 Matt Hogstrom
 [EMAIL PROTECTED]

Re: [VOTE] 2.0-M1 Release

I tried tomcat6-jee5:
-- The log file is empty. 
-- Is it necessary to change all the log levels from WARN to ERROR (rev
488143)? 

Thanks
Anita

--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 All,
 
 I have prepared 2.0-M1 for release.  Of course all the hard work was 
 
 done by the lot of y'all :)
 
 I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied 
 
 with the results.  All modes of operation functioned well (SLSB,  
 Direct, EJB and JPA).  I toned all the logs down to error to not  
 overwhelm the users with lots of diagnostic output (they can always  
 turn it up later if they want.)
 
 The uploads are taking forever so you'll see some piece parts trickle
  
 in.  For the review I expect you'll want to focus on http:// 
 people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
 for your review and testing.  I've included both Tomcat and Jetty as 
 
 well as the minimal and j5ee assemblies.  The source code is also
 there.
 
 Note that if you are planning on building you'll need to obtain the  
 openejb-2.2-incubating jars to your local repo.  The easiest way to  
 do this is to modify the root pom and add a repository for David's  
 home directory at http://people.apache.org/~dblevins/stage/.
 
 For SNAPSHOTs of certain plugins I have resolved these files to the  
 most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
 and will be putting them into our SVN for folks who may want to build
  
 in the future.  I'm not too concerned about repeatability as this  
 Milestone will be superseded at the end of January with the next  
 version.
 
 The other MAven artifacts will be trickling onto people across my  
 horribly slow home pipe and dropped into http://people.apache.org/ 
 ~hogstrom/stage over the next few hours.
 
 Please review and cast your vote early.  The faster we determine this
  
 build is good or if there is an issue the better.
 
 Thanks in advance for all your help in this effort.
 
 This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
 members vote quicker :)
 
 If a respin is is necessary this vote will be suspended and a new one
  
 will start.
 
 Matt Hogstrom
 [EMAIL PROTECTED]
 
 
 


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

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Jeff Genender

Which log is empty?

anita kulshreshtha wrote:
 I tried tomcat6-jee5:
 -- The log file is empty. 
 -- Is it necessary to change all the log levels from WARN to ERROR (rev
 488143)? 
 
 Thanks
 Anita
 
 --- Matt Hogstrom [EMAIL PROTECTED] wrote:
 
 All,

 I have prepared 2.0-M1 for release.  Of course all the hard work was 

 done by the lot of y'all :)

 I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied 

 with the results.  All modes of operation functioned well (SLSB,  
 Direct, EJB and JPA).  I toned all the logs down to error to not  
 overwhelm the users with lots of diagnostic output (they can always  
 turn it up later if they want.)

 The uploads are taking forever so you'll see some piece parts trickle
  
 in.  For the review I expect you'll want to focus on http:// 
 people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
 for your review and testing.  I've included both Tomcat and Jetty as 

 well as the minimal and j5ee assemblies.  The source code is also
 there.

 Note that if you are planning on building you'll need to obtain the  
 openejb-2.2-incubating jars to your local repo.  The easiest way to  
 do this is to modify the root pom and add a repository for David's  
 home directory at http://people.apache.org/~dblevins/stage/.

 For SNAPSHOTs of certain plugins I have resolved these files to the  
 most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
 and will be putting them into our SVN for folks who may want to build
  
 in the future.  I'm not too concerned about repeatability as this  
 Milestone will be superseded at the end of January with the next  
 version.

 The other MAven artifacts will be trickling onto people across my  
 horribly slow home pipe and dropped into http://people.apache.org/ 
 ~hogstrom/stage over the next few hours.

 Please review and cast your vote early.  The faster we determine this
  
 build is good or if there is an issue the better.

 Thanks in advance for all your help in this effort.

 This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
 members vote quicker :)

 If a respin is is necessary this vote will be suspended and a new one
  
 will start.

 Matt Hogstrom
 [EMAIL PROTECTED]



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

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Hernan Cunico


Hi All,
I have two basic comments/questions.

1- I see a bunch of INFO messages in both Tomcat and Jetty at startup, not a 
show stopper for this release.

2- Deployment on Jetty is not behaving exactly as I expected. Not sure if I 
messed up the dep plans given the new specs, however this same WAR works just 
fine with Tomcat.
In Jetty I deploy a WAR and when I access the app it will list the content of the 
WAR, if I click on the JSP it will work fine. Something like not following the 
web.xml welcome-file maybe? The context-root is correct.

Am I missing anything obvious?

Cheers!
Hernan

Matt Hogstrom wrote:

All,

I have prepared 2.0-M1 for release.  Of course all the hard work was 
done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied 
with the results.  All modes of operation functioned well (SLSB, Direct, 
EJB and JPA).  I toned all the logs down to error to not overwhelm the 
users with lots of diagnostic output (they can always turn it up later 
if they want.)


The uploads are taking forever so you'll see some piece parts trickle 
in.  For the review I expect you'll want to focus on 
http://people.apache.org/~hogstrom/2.0-M1 as this contains the 
assemblies for your review and testing.  I've included both Tomcat and 
Jetty as well as the minimal and j5ee assemblies.  The source code is 
also there.


Note that if you are planning on building you'll need to obtain the 
openejb-2.2-incubating jars to your local repo.  The easiest way to do 
this is to modify the root pom and add a repository for David's home 
directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the most 
recent SNAPSHOT date / timestamp.  I'm pulling a copy of these and will 
be putting them into our SVN for folks who may want to build in the 
future.  I'm not too concerned about repeatability as this Milestone 
will be superseded at the end of January with the next version.


The other MAven artifacts will be trickling onto people across my 
horribly slow home pipe and dropped into 
http://people.apache.org/~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine this 
build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC members 
vote quicker :)


If a respin is is necessary this vote will be suspended and a new one 
will start.


Matt Hogstrom
[EMAIL PROTECTED]

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Joe Bohn


+1

I tried all 4 assemblies and deployed a simple web application to each. 
 All went as expected.  As already mentioned, there are some info 
messages (more with tomcat than jetty).


Joe


Matt Hogstrom wrote:

All,

I have prepared 2.0-M1 for release.  Of course all the hard work was  
done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied  
with the results.  All modes of operation functioned well (SLSB,  
Direct, EJB and JPA).  I toned all the logs down to error to not  
overwhelm the users with lots of diagnostic output (they can always  
turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts trickle  
in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  for 
your review and testing.  I've included both Tomcat and Jetty as  well 
as the minimal and j5ee assemblies.  The source code is also there.


Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  do 
this is to modify the root pom and add a repository for David's  home 
directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  and 
will be putting them into our SVN for folks who may want to build  in 
the future.  I'm not too concerned about repeatability as this  
Milestone will be superseded at the end of January with the next  version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine this  
build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new one  
will start.


Matt Hogstrom
[EMAIL PROTECTED]

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Hernan Cunico


geronimo.log is empty on both Jetty and Tomcat

Cheers!
Hernan

Jeff Genender wrote:

Which log is empty?

anita kulshreshtha wrote:

I tried tomcat6-jee5:
-- The log file is empty. 
-- Is it necessary to change all the log levels from WARN to ERROR (rev
488143)? 


Thanks
Anita

--- Matt Hogstrom [EMAIL PROTECTED] wrote:


All,

I have prepared 2.0-M1 for release.  Of course all the hard work was 


done by the lot of y'all :)

I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied 

with the results.  All modes of operation functioned well (SLSB,  
Direct, EJB and JPA).  I toned all the logs down to error to not  
overwhelm the users with lots of diagnostic output (they can always  
turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts trickle
 
in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
for your review and testing.  I've included both Tomcat and Jetty as 


well as the minimal and j5ee assemblies.  The source code is also
there.

Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  
do this is to modify the root pom and add a repository for David's  
home directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
and will be putting them into our SVN for folks who may want to build
 
in the future.  I'm not too concerned about repeatability as this  
Milestone will be superseded at the end of January with the next  
version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine this
 
build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new one
 
will start.


Matt Hogstrom
[EMAIL PROTECTED]





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

Re: [VOTE] 2.0-M1 Release


If you want more extensive debugging you can crank the log level up.

for M2 I want to look at the log in a bit more detail as a user I  
would expect some server started messages and the like and I think we  
need to tweak the server to get that level of usability.


The log does work which is one reason I lowered the log levels :)

On Dec 18, 2006, at 10:21 AM, anita kulshreshtha wrote:


I tried tomcat6-jee5:
-- The log file is empty. 
-- Is it necessary to change all the log levels from WARN to ERROR  
(rev

488143)?

Thanks
Anita

--- Matt Hogstrom [EMAIL PROTECTED] wrote:


All,

I have prepared 2.0-M1 for release.  Of course all the hard work was

done by the lot of y'all :)

I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied

with the results.  All modes of operation functioned well (SLSB,
Direct, EJB and JPA).  I toned all the logs down to error to not
overwhelm the users with lots of diagnostic output (they can always
turn it up later if they want.)

The uploads are taking forever so you'll see some piece parts trickle

in.  For the review I expect you'll want to focus on http://
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies
for your review and testing.  I've included both Tomcat and Jetty as

well as the minimal and j5ee assemblies.  The source code is also
there.

Note that if you are planning on building you'll need to obtain the
openejb-2.2-incubating jars to your local repo.  The easiest way to
do this is to modify the root pom and add a repository for David's
home directory at http://people.apache.org/~dblevins/stage/.

For SNAPSHOTs of certain plugins I have resolved these files to the
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these
and will be putting them into our SVN for folks who may want to build

in the future.  I'm not too concerned about repeatability as this
Milestone will be superseded at the end of January with the next
version.

The other MAven artifacts will be trickling onto people across my
horribly slow home pipe and dropped into http://people.apache.org/
~hogstrom/stage over the next few hours.

Please review and cast your vote early.  The faster we determine this

build is good or if there is an issue the better.

Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC
members vote quicker :)

If a respin is is necessary this vote will be suspended and a new one

will start.

Matt Hogstrom
[EMAIL PROTECTED]






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



Matt Hogstrom
[EMAIL PROTECTED]

[DISCUSS] 2.0-M1 Release


All,

I opened this thread for general comments and questions about the  
release.  Let's have the discussions here and leave the vote thread  
for +/- voting only so it will be easier to process


Thanks.

Matt Hogstrom
[EMAIL PROTECTED]

Re: svn commit: r488106 - /geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java

   It would be nice if this was included in 2.0-M1. It will allow clean
shutdown of the server without changing all the log levels from WARN to
ERROR.

Thanks
Anita

--- [EMAIL PROTECTED] wrote:

 Author: dims
 Date: Sun Dec 17 19:18:42 2006
 New Revision: 488106
 
 URL: http://svn.apache.org/viewvc?view=revrev=488106
 Log:
 prevent NPE if the hashmap is empty
 
 Modified:


geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
 
 Modified:

geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
 URL:

http://svn.apache.org/viewvc/geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java?view=diffrev=488106r1=488105r2=488106

==
 ---

geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
 (original)
 +++

geronimo/server/trunk/modules/geronimo-naming/src/main/java/org/apache/geronimo/gjndi/binding/GBeanBinding.java
 Sun Dec 17 19:18:42 2006
 @@ -156,12 +156,13 @@
   * @param abstractName the abstract name of the gbean to unbind
   */
  protected synchronized void removeBinding(AbstractName
 abstractName) {
 -if (first(bindings).getKey().equals(abstractName)) {
 +Map.Entry entry = first(bindings);
 +if (entry != null  entry.getKey().equals(abstractName)) {
  Object oldValue = bindings.remove(abstractName);
 -Map.Entry newEntry = first(bindings);
 -if (newEntry != null) {
 -Object newAbstractName = newEntry.getValue();
 -Object newValue = newEntry.getValue();
 +entry = first(bindings);
 +if (entry != null) {
 +Object newAbstractName = entry.getValue();
 +Object newValue = entry.getValue();
  try {
  context.rebind(name, newValue);
  } catch (NamingException e) {
 
 
 


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

Re: [DISCUSS] 2.0-M1 Release


On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote:


There's a source file missing a license header. Not sure if it was  
added after my last scan of the code or if I just missed it.  
Anyway, it needs to be fixed.


All servers start. I'm getting some [info] log messages sent to  
STDOUT, but I don't think that should hold up an M1 release.


I've scanned the jetty java ee5 binary -- looks good. Working on  
tomcat and some more sanity checks. Other that the license header,  
things look good...


--kevan


Kevan,

If you'll add it to tags I'll re-spin that module.  This doesn't  
affect the server binaries so updating and spinning that module  
should be fine.


I'd say thanks for finding this but I now officially hate your keen  
eye :)


On the positive note...we are doing way better than we ever have  
previously in terms of legal clearance so thanks to you and all the  
others making this easier.  I think Jason's legal plugin plus the RAT  
tool, plus all the paranoid eyes are helping :)

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Paul McMahan


+1

Best wishes,
Paul

On 12/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

All,

I have prepared 2.0-M1 for release.  Of course all the hard work was
done by the lot of y'all :)

I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied
with the results.  All modes of operation functioned well (SLSB,
Direct, EJB and JPA).  I toned all the logs down to error to not
overwhelm the users with lots of diagnostic output (they can always
turn it up later if they want.)

The uploads are taking forever so you'll see some piece parts trickle
in.  For the review I expect you'll want to focus on http://
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies
for your review and testing.  I've included both Tomcat and Jetty as
well as the minimal and j5ee assemblies.  The source code is also there.

Note that if you are planning on building you'll need to obtain the
openejb-2.2-incubating jars to your local repo.  The easiest way to
do this is to modify the root pom and add a repository for David's
home directory at http://people.apache.org/~dblevins/stage/.

For SNAPSHOTs of certain plugins I have resolved these files to the
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these
and will be putting them into our SVN for folks who may want to build
in the future.  I'm not too concerned about repeatability as this
Milestone will be superseded at the end of January with the next
version.

The other MAven artifacts will be trickling onto people across my
horribly slow home pipe and dropped into http://people.apache.org/
~hogstrom/stage over the next few hours.

Please review and cast your vote early.  The faster we determine this
build is good or if there is an issue the better.

Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC
members vote quicker :)

If a respin is is necessary this vote will be suspended and a new one
will start.

Matt Hogstrom
[EMAIL PROTECTED]

[jira] Created: (XBEAN-66) Schemas generated by xbean are sometimes invalid (xs:any conflict)

Schemas generated by xbean are sometimes invalid (xs:any conflict)
--

 Key: XBEAN-66
 URL: http://issues.apache.org/jira/browse/XBEAN-66
 Project: XBean
  Issue Type: Bug
  Components: maven-plugin, spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




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

[jira] Closed: (XBEAN-66) Schemas generated by xbean are sometimes invalid (xs:any conflict)

 [ http://issues.apache.org/jira/browse/XBEAN-66?page=all ]

Guillaume Nodet closed XBEAN-66.


Resolution: Fixed

Fixed as part of XBEAN-65

 Schemas generated by xbean are sometimes invalid (xs:any conflict)
 --

 Key: XBEAN-66
 URL: http://issues.apache.org/jira/browse/XBEAN-66
 Project: XBean
  Issue Type: Bug
  Components: maven-plugin, spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




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

[jira] Created: (XBEAN-67) When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception

When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit 
exception
-

 Key: XBEAN-67
 URL: http://issues.apache.org/jira/browse/XBEAN-67
 Project: XBean
  Issue Type: Bug
  Components: spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




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

[jira] Closed: (XBEAN-67) When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit exception

 [ http://issues.apache.org/jira/browse/XBEAN-67?page=all ]

Guillaume Nodet closed XBEAN-67.


Resolution: Fixed

Author: gnodet
Date: Mon Dec 18 07:57:04 2006
New Revision: 488309

URL: http://svn.apache.org/viewvc?view=revrev=488309
Log:
XBEAN-67: When an xbean tag is mispelled, a CNFE is thrown instead of a more 
explicit exception

Modified:
   
geronimo/xbean/trunk/xbean-spring-common/src/main/java/org/apache/xbean/spring/context/impl/MappingMetaData.java


 When an xbean tag is mispelled, a CNFE is thrown instead of a more explicit 
 exception
 -

 Key: XBEAN-67
 URL: http://issues.apache.org/jira/browse/XBEAN-67
 Project: XBean
  Issue Type: Bug
  Components: spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




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

Patches in RTC (Geronimo - 2006-12-18)

2006-12-18 Thread dblevins

Geronimo - Monday, December 18, 2006

  5 Patches in RTC

[GERONIMO-2638] Improve ModuleBuilder and ConfigurationBuilder interfaces 
to replace use of JarFile
  - Assignee: Sachin Patel
  - Reporter: Sachin Patel
  - Created:  Thu Dec 07 23:41:31 GMT 2006
  - Updated:  Mon Dec 11 16:21:45 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2638

[GERONIMO-2485] PersistenceUnitGBean needs a NamespaceDrivenDeployer
  - Assignee: David Jencks
  - Reporter: David Jencks
  - Created:  Wed Oct 11 21:23:29 GMT 2006
  - Updated:  Thu Dec 07 20:28:27 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2485

[GERONIMO-1277] Change group-id to org.apache.geronimo
  - Assignee: Jason Dillon
  - Reporter: Dain Sundstrom
  - Created:  Sat Dec 03 10:55:12 GMT 2005
  - Updated:  Tue Nov 07 23:57:44 GMT 2006
  - Votes: 3
  1  David Jencks
  2  Donald Woods
  3  Vamsavardhana Reddy
  - http://issues.apache.org/jira/browse/GERONIMO-1277

[GERONIMO-2015] Let's replace JKS to PKCS12 key store type
  - Assignee: Unassigned
  - Reporter: Nikolay Chugunov
  - Created:  Fri May 12 21:54:17 GMT 2006
  - Updated:  Wed Dec 06 06:57:11 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMO-2015

[GERONIMODEVTOOLS-112] Loading deployment plan editor on empty file should 
auto-create plan
  - Assignee: Sachin Patel
  - Reporter: Sachin Patel
  - Created:  Wed Oct 11 21:45:57 GMT 2006
  - Updated:  Wed Dec 06 14:11:15 GMT 2006
  - Votes: 0
  - http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-112


NOTE: This email is generated and does not constitute and offical
vote or vote result.  All official voting is done on the dev list.

If you do not see your issue here, click the Begin RTC Review
link under the Available Workflow Actions of the JIRA page.

If you do not see your vote here, click the Vote link under the
Operations section of the JIRA page.


 *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE ***

Template: 
http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm

[jira] Created: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support

Upgrade to QDox 1.6.1 for better java 5 support 


 Key: XBEAN-68
 URL: http://issues.apache.org/jira/browse/XBEAN-68
 Project: XBean
  Issue Type: Improvement
  Components: maven-plugin, spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




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

[jira] Closed: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support

 [ http://issues.apache.org/jira/browse/XBEAN-68?page=all ]

Guillaume Nodet closed XBEAN-68.


Resolution: Fixed

Author: gnodet
Date: Mon Dec 18 08:01:55 2006
New Revision: 488310

URL: http://svn.apache.org/viewvc?view=revrev=488310
Log:
Remove exclusions which cause spring to not be included in the build :(

Modified:
   geronimo/xbean/trunk/xbean-spring-v2/pom.xml


 Upgrade to QDox 1.6.1 for better java 5 support
 ---

 Key: XBEAN-68
 URL: http://issues.apache.org/jira/browse/XBEAN-68
 Project: XBean
  Issue Type: Improvement
  Components: maven-plugin, spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




-- 
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: (XBEAN-68) Upgrade to QDox 1.6.1 for better java 5 support

[ 
http://issues.apache.org/jira/browse/XBEAN-68?page=comments#action_12459397 ] 

Guillaume Nodet commented on XBEAN-68:
--

Oops, wrong revision.  The following is the correct one:

Author: gnodet
Date: Mon Dec 18 08:13:55 2006
New Revision: 488321

URL: http://svn.apache.org/viewvc?view=revrev=488321
Log:
XBEAN-68: Upgrade to QDox 1.6.1

Modified:
   geronimo/xbean/trunk/pom.xml


 Upgrade to QDox 1.6.1 for better java 5 support
 ---

 Key: XBEAN-68
 URL: http://issues.apache.org/jira/browse/XBEAN-68
 Project: XBean
  Issue Type: Improvement
  Components: maven-plugin, spring
Affects Versions: 2.7
Reporter: Guillaume Nodet
 Assigned To: Guillaume Nodet
 Fix For: 2.8




-- 
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] 2.0-M1 Release

  The geronimo.log is empty. It does not contain system information.

Thanks
Anita

--- Jeff Genender [EMAIL PROTECTED] wrote:

 Which log is empty?
 
 anita kulshreshtha wrote:
  I tried tomcat6-jee5:
  -- The log file is empty. 
  -- Is it necessary to change all the log levels from WARN to ERROR
 (rev
  488143)? 
  
  Thanks
  Anita
  
  --- Matt Hogstrom [EMAIL PROTECTED] wrote:
  
  All,
 
  I have prepared 2.0-M1 for release.  Of course all the hard work
 was 
 
  done by the lot of y'all :)
 
  I have tested DayTrader 2.0-SNAPSHOT on this build and I'm
 satisfied 
 
  with the results.  All modes of operation functioned well (SLSB,  
  Direct, EJB and JPA).  I toned all the logs down to error to not  
  overwhelm the users with lots of diagnostic output (they can
 always  
  turn it up later if they want.)
 
  The uploads are taking forever so you'll see some piece parts
 trickle
   
  in.  For the review I expect you'll want to focus on http:// 
  people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies
  
  for your review and testing.  I've included both Tomcat and Jetty
 as 
 
  well as the minimal and j5ee assemblies.  The source code is also
  there.
 
  Note that if you are planning on building you'll need to obtain
 the  
  openejb-2.2-incubating jars to your local repo.  The easiest way
 to  
  do this is to modify the root pom and add a repository for David's
  
  home directory at http://people.apache.org/~dblevins/stage/.
 
  For SNAPSHOTs of certain plugins I have resolved these files to
 the  
  most recent SNAPSHOT date / timestamp.  I'm pulling a copy of
 these  
  and will be putting them into our SVN for folks who may want to
 build
   
  in the future.  I'm not too concerned about repeatability as this 
 
  Milestone will be superseded at the end of January with the next  
  version.
 
  The other MAven artifacts will be trickling onto people across my 
 
  horribly slow home pipe and dropped into http://people.apache.org/
 
  ~hogstrom/stage over the next few hours.
 
  Please review and cast your vote early.  The faster we determine
 this
   
  build is good or if there is an issue the better.
 
  Thanks in advance for all your help in this effort.
 
  This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
  members vote quicker :)
 
  If a respin is is necessary this vote will be suspended and a new
 one
   
  will start.
 
  Matt Hogstrom
  [EMAIL PROTECTED]
 
 
 
  
  
  __
  Do You Yahoo!?
  Tired of spam?  Yahoo! Mail has the best spam protection around 
  http://mail.yahoo.com 
 


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

[jira] Created: (AMQ-1101) Problem when compiling vs2005-activemq project with unsafe method call

2006-12-18 Thread Pascal ST-LAURENT (JIRA)

Problem when compiling vs2005-activemq project with unsafe method call
--

 Key: AMQ-1101
 URL: https://issues.apache.org/activemq/browse/AMQ-1101
 Project: ActiveMQ
  Issue Type: Bug
  Components: NMS (C# client)
Affects Versions: 4.0
 Environment: Windows XP, SP2
Reporter: Pascal ST-LAURENT


In vs2005-activemq project, 
src/main/csharp/ActiveMQ/Commands/ActiveMQTextMessage.cs file, Text property.

Must use Marchal.SizeOf() method instead of sizeof(). In this case, we don't 
need to specified to build the project with unsafe directive and uses only 
managed code.

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

[VOTE] Release XBean 2.8


I'm starting a vote to release XBean 2.8.
There has not been much changes since 2.7, but a few
bugs fixed, and the addition of the xbean-finder module.
Anyway, the bugs are important enough to deserver a new
release (the generated schemas can not be validated).

[ ] +1 Start xbean 2.8 release process
[ ] +/- 0
[ ] -1 Don't release xbean 2.8 now

Here's my +1.

--
Cheers,
Guillaume Nodet

Re: [VOTE] Release XBean 2.8

2006-12-18 Thread James Strachan


+1

On 12/18/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'm starting a vote to release XBean 2.8.
There has not been much changes since 2.7, but a few
bugs fixed, and the addition of the xbean-finder module.
Anyway, the bugs are important enough to deserver a new
release (the generated schemas can not be validated).

[ ] +1 Start xbean 2.8 release process
[ ] +/- 0
[ ] -1 Don't release xbean 2.8 now

Here's my +1.

--
Cheers,
Guillaume Nodet




--

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

Re: [DISCUSS] 2.0-M1 Release


anita,

If I turn logging up to INFO in var/log/server-log4j.properties I get  
information in the log.


On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote:


All,

I opened this thread for general comments and questions about the  
release.  Let's have the discussions here and leave the vote thread  
for +/- voting only so it will be easier to process


Thanks.

Matt Hogstrom
[EMAIL PROTECTED]





Matt Hogstrom
[EMAIL PROTECTED]

[jira] Created: (GERONIMO-2671) Streaming API for XML and JAXB integration

2006-12-18 Thread Jarek Gawor (JIRA)

Streaming API for XML and JAXB integration
--

 Key: GERONIMO-2671
 URL: http://issues.apache.org/jira/browse/GERONIMO-2671
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
Affects Versions: 2.0
Reporter: Jarek Gawor
 Attachments: stax-jaxb.patch

The attached patch integrates the Streaming API for XML and JAXB with Geronimo. 
Any web application (JSP, servlet) or EJB will be able to use the StAX or JAXB  
API. The patch also includes basic tests to verify that the streaming and JAXB 
API can be used within the web or ejb container. The woodstox xml processor is 
used as the implementation behind the streaming API. The Sun's JAXB RI is used 
for JAXB support.

Since this is my first attempt at such integration, please let me know if there 
is a better way of doing things, if i missed something, etc.

This patch supersedes the patch in 
https://issues.apache.org/jira/browse/GERONIMO-2667.


-- 
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-2671) Streaming API for XML and JAXB integration

2006-12-18 Thread Jarek Gawor (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2671?page=all ]

Jarek Gawor updated GERONIMO-2671:
--

Attachment: stax-jaxb.patch

 Streaming API for XML and JAXB integration
 --

 Key: GERONIMO-2671
 URL: http://issues.apache.org/jira/browse/GERONIMO-2671
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
Affects Versions: 2.0
Reporter: Jarek Gawor
 Attachments: stax-jaxb.patch


 The attached patch integrates the Streaming API for XML and JAXB with 
 Geronimo. Any web application (JSP, servlet) or EJB will be able to use the 
 StAX or JAXB  API. The patch also includes basic tests to verify that the 
 streaming and JAXB API can be used within the web or ejb container. The 
 woodstox xml processor is used as the implementation behind the streaming 
 API. The Sun's JAXB RI is used for JAXB support.
 Since this is my first attempt at such integration, please let me know if 
 there is a better way of doing things, if i missed something, etc.
 This patch supersedes the patch in 
 https://issues.apache.org/jira/browse/GERONIMO-2667.

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

[jira] Closed: (GERONIMO-2667) Streaming API for XML integration

2006-12-18 Thread Jarek Gawor (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2667?page=all ]

Jarek Gawor closed GERONIMO-2667.
-

Resolution: Duplicate

https://issues.apache.org/jira/browse/GERONIMO-2671 contains updated patch with 
JAXB support.


 Streaming API for XML integration
 -

 Key: GERONIMO-2667
 URL: http://issues.apache.org/jira/browse/GERONIMO-2667
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: general
Affects Versions: 2.0
Reporter: Jarek Gawor
 Attachments: stax.patch


 The attached patch integrates the Streaming API for XML with Geronimo. Any 
 web application (JSP, servlet) or EJB will be able to use the streaming API. 
 The patch also includes basic tests to verify that the streaming API can be 
 used within the web or ejb container. The woodstox xml processor is used as 
 the implementation behind the API.
 Since this is my first attempt at such integration, please let me know if 
 there is a better way of doing things, if i missed something, etc.

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

2006-12-18 Thread Hiram Chirino


+1

On 12/18/06, Guillaume Nodet [EMAIL PROTECTED] wrote:

I'm starting a vote to release XBean 2.8.
There has not been much changes since 2.7, but a few
bugs fixed, and the addition of the xbean-finder module.
Anyway, the bugs are important enough to deserver a new
release (the generated schemas can not be validated).

[ ] +1 Start xbean 2.8 release process
[ ] +/- 0
[ ] -1 Don't release xbean 2.8 now

Here's my +1.

--
Cheers,
Guillaume Nodet




--
Regards,
Hiram

Blog: http://hiramchirino.com

Re: [VOTE] 2.0-M1 Release

2006-12-18 Thread Prasad Kashyap


Found no show-stopping issues for a milestone.

+1

Cheers
Prasad

On 12/18/06, Matt Hogstrom [EMAIL PROTECTED] wrote:

All,

I have prepared 2.0-M1 for release.  Of course all the hard work was
done by the lot of y'all :)

I have tested DayTrader 2.0-SNAPSHOT on this build and I'm satisfied
with the results.  All modes of operation functioned well (SLSB,
Direct, EJB and JPA).  I toned all the logs down to error to not
overwhelm the users with lots of diagnostic output (they can always
turn it up later if they want.)

The uploads are taking forever so you'll see some piece parts trickle
in.  For the review I expect you'll want to focus on http://
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies
for your review and testing.  I've included both Tomcat and Jetty as
well as the minimal and j5ee assemblies.  The source code is also there.

Note that if you are planning on building you'll need to obtain the
openejb-2.2-incubating jars to your local repo.  The easiest way to
do this is to modify the root pom and add a repository for David's
home directory at http://people.apache.org/~dblevins/stage/.

For SNAPSHOTs of certain plugins I have resolved these files to the
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these
and will be putting them into our SVN for folks who may want to build
in the future.  I'm not too concerned about repeatability as this
Milestone will be superseded at the end of January with the next
version.

The other MAven artifacts will be trickling onto people across my
horribly slow home pipe and dropped into http://people.apache.org/
~hogstrom/stage over the next few hours.

Please review and cast your vote early.  The faster we determine this
build is good or if there is an issue the better.

Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC
members vote quicker :)

If a respin is is necessary this vote will be suspended and a new one
will start.

Matt Hogstrom
[EMAIL PROTECTED]

Re: [DISCUSS] 2.0-M1 Release



On Dec 18, 2006, at 10:46 AM, Matt Hogstrom wrote:


On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote:


There's a source file missing a license header. Not sure if it was  
added after my last scan of the code or if I just missed it.  
Anyway, it needs to be fixed.


All servers start. I'm getting some [info] log messages sent to  
STDOUT, but I don't think that should hold up an M1 release.


I've scanned the jetty java ee5 binary -- looks good. Working on  
tomcat and some more sanity checks. Other that the license header,  
things look good...


--kevan


Kevan,

If you'll add it to tags I'll re-spin that module.  This doesn't  
affect the server binaries so updating and spinning that module  
should be fine.


I'd say thanks for finding this but I now officially hate your keen  
eye :)


On the positive note...we are doing way better than we ever have  
previously in terms of legal clearance so thanks to you and all the  
others making this easier.  I think Jason's legal plugin plus the  
RAT tool, plus all the paranoid eyes are helping :)


Ok. Fixed with 488326.

--kevan

Re: [DISCUSS] 2.0-M1 Release

Matt,
   I had to change the following lines in server-log4j.properties to
get system information logged:
log4j.rootLogger=INFO, CONSOLE, FILE
log4j.appender.FILE.Threshold=INFO
   In addition I see the following stack trace during shutdown. A fix
for this is already available in rev 488106:
http://www.nabble.com/Re%3A-svn-commit%3A-r488106geronimo-server-trunk-modules-geronimo-naming-src-main-java-org-apache-geronimo-gjndi-binding-GBeanBinding.java-p7930963.html
   Is it a good idea to supress all warning messages like this even for
a M1 release ?

Thanks
Anita

12:39:24,552 WARN  [BasicLifecycleMonitor] Exception occured while
notifying listener
java.lang.NullPointerException
at
org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding(GBeanBinding.java:159)
at
org.apache.geronimo.gjndi.binding.GBeanBinding$GBeanLifecycleListener.stopped(GBeanBinding.java:108)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEvent(BasicLifecycleMonitor.java:197)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500(BasicLifecycleMonitor.java:41)
at 
...

--- Matt Hogstrom [EMAIL PROTECTED] wrote:

 anita,
 
 If I turn logging up to INFO in var/log/server-log4j.properties I get
  
 information in the log.
 
 On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote:
 
  All,
 
  I opened this thread for general comments and questions about the  
  release.  Let's have the discussions here and leave the vote thread
  
  for +/- voting only so it will be easier to process
 
  Thanks.
 
  Matt Hogstrom
  [EMAIL PROTECTED]
 
 
 
 
 Matt Hogstrom
 [EMAIL PROTECTED]
 
 
 


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

Re: [DISCUSS] 2.0-M1 Release

I think its a preference.  At this point I think M1 is what it is and  
we'll update the Wiki with known issues.


On Dec 18, 2006, at 12:49 PM, anita kulshreshtha wrote:


Matt,
   I had to change the following lines in server-log4j.properties to
get system information logged:
log4j.rootLogger=INFO, CONSOLE, FILE
log4j.appender.FILE.Threshold=INFO
   In addition I see the following stack trace during shutdown. A fix
for this is already available in rev 488106:
http://www.nabble.com/Re%3A-svn-commit%3A-r488106geronimo- 
server-trunk-modules-geronimo-naming-src-main-java-org-apache- 
geronimo-gjndi-binding-GBeanBinding.java-p7930963.html
   Is it a good idea to supress all warning messages like this even  
for

a M1 release ?

Thanks
Anita

12:39:24,552 WARN  [BasicLifecycleMonitor] Exception occured while
notifying listener
java.lang.NullPointerException
at
org.apache.geronimo.gjndi.binding.GBeanBinding.removeBinding 
(GBeanBinding.java:159)

at
org.apache.geronimo.gjndi.binding.GBeanBinding 
$GBeanLifecycleListener.stopped(GBeanBinding.java:108)

at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireStoppedEven 
t(BasicLifecycleMonitor.java:197)

at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$500 
(BasicLifecycleMonitor.java:41)

at
...

--- Matt Hogstrom [EMAIL PROTECTED] wrote:


anita,

If I turn logging up to INFO in var/log/server-log4j.properties I get

information in the log.

On Dec 18, 2006, at 10:37 AM, Matt Hogstrom wrote:


All,

I opened this thread for general comments and questions about the
release.  Let's have the discussions here and leave the vote thread



for +/- voting only so it will be easier to process

Thanks.

Matt Hogstrom
[EMAIL PROTECTED]





Matt Hogstrom
[EMAIL PROTECTED]






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



Matt Hogstrom
[EMAIL PROTECTED]

Re: [DISCUSS] 2.0-M1 Release


Thanks for finding this Kevan.

I reposted the source, there are no modules.

Updated source is in:

http://people.apache.org/~hogstrom/2.0-M1/

Thanks for finding this.

On Dec 18, 2006, at 12:36 PM, Kevan Miller wrote:



On Dec 18, 2006, at 10:46 AM, Matt Hogstrom wrote:


On Dec 18, 2006, at 9:49 AM, Kevan Miller wrote:


There's a source file missing a license header. Not sure if it  
was added after my last scan of the code or if I just missed it.  
Anyway, it needs to be fixed.


All servers start. I'm getting some [info] log messages sent to  
STDOUT, but I don't think that should hold up an M1 release.


I've scanned the jetty java ee5 binary -- looks good. Working on  
tomcat and some more sanity checks. Other that the license  
header, things look good...


--kevan


Kevan,

If you'll add it to tags I'll re-spin that module.  This doesn't  
affect the server binaries so updating and spinning that module  
should be fine.


I'd say thanks for finding this but I now officially hate your  
keen eye :)


On the positive note...we are doing way better than we ever have  
previously in terms of legal clearance so thanks to you and all  
the others making this easier.  I think Jason's legal plugin plus  
the RAT tool, plus all the paranoid eyes are helping :)


Ok. Fixed with 488326.

--kevan



Matt Hogstrom
[EMAIL PROTECTED]

Re: [VOTE] Release XBean 2.8



On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote:


I'm starting a vote to release XBean 2.8.
There has not been much changes since 2.7, but a few
bugs fixed, and the addition of the xbean-finder module.
Anyway, the bugs are important enough to deserver a new
release (the generated schemas can not be validated).

[ ] +1 Start xbean 2.8 release process
[ ] +/- 0
[ ] -1 Don't release xbean 2.8 now

Here's my +1.


Not sure what you mean by release process. But here are the issues  
which look like they would block a release:


1. NOTICE files do not conform to current ASF standards
2. The following files either do not contain a valid license header  
(not all files will require one, but many of these need one) or have  
an out-of-date license header (all need to be updated).


==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar1/ 
resource)
==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar2/ 
resource)
==package-info.java (./xbean-finder/src/test/java/org/acme/foo/ 
package-info.java)
==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/ 
java.io.InputStream)
==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/ 
java.io.OutputStream)
==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/ 
java.io.Serializable)

==one (./xbean-finder/src/test/resources/META-INF/externalizables/one)
==three (./xbean-finder/src/test/resources/META-INF/externalizables/ 
three)

==two (./xbean-finder/src/test/resources/META-INF/externalizables/two)
==bar (./xbean-finder/src/test/resources/META-INF/ 
java.net.URLStreamHandler/bar)
==baz (./xbean-finder/src/test/resources/META-INF/ 
java.net.URLStreamHandler/baz)
==foo (./xbean-finder/src/test/resources/META-INF/ 
java.net.URLStreamHandler/foo)
==kernel (./xbean-finder/src/test/resources/META-INF/ 
javax.naming.spi.ObjectFactory/kernel)
==ldap (./xbean-finder/src/test/resources/META-INF/ 
javax.naming.spi.ObjectFactory/ldap)
==ishtar.properties (./xbean-finder/src/test/resources/META-INF/ 
movies/ishtar.properties)
==kingkong.properties (./xbean-finder/src/test/resources/META-INF/ 
movies/kingkong.properties)
==serentity.properties (./xbean-finder/src/test/resources/META-INF/ 
movies/serentity.properties)

==one (./xbean-finder/src/test/resources/META-INF/serializables/one)
==three (./xbean-finder/src/test/resources/META-INF/serializables/three)
==two (./xbean-finder/src/test/resources/META-INF/serializables/two)
==familyguy.properties (./xbean-finder/src/test/resources/META-INF/ 
tvshows/familyguy.properties)
==simpsons.properties (./xbean-finder/src/test/resources/META-INF/ 
tvshows/simpsons.properties)
==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ 
package.html)
==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/ 
standard/package.html)

==pom.xml (./xbean-naming/pom.xml)
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
AbstractContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
AbstractFederatedContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ContextAccess.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ContextAccessControlList.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ContextFederation.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ContextFlyweight.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ContextUtil.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
ImmutableContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
NestedContextFactory.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
VirtualSubcontext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/ 
WritableContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/global/ 
GlobalContextManager.java
==xbean-naming/src/main/java/org/apache/xbean/naming/java/ 
javaURLContextFactory.java
==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ 
CachingReference.java
==xbean-naming/src/main/java/org/apache/xbean/naming/reference/ 
SimpleReference.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
AbstractContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
ContextAccessControlListTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
FederationTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
ImmutableContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
UnmodifiableContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/ 
WritableContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/global/ 
GlobalContextManagerTest.java
==spring-beans.xsd (./xbean-spring-common/src/main/resources/org/ 
apache/xbean/spring/spring-beans.xsd)

==pom.xml (./xbean-spring-itests/2.0/pom.xml)
==pom.xml (./xbean-spring-itests/2.0-rc3/pom.xml)

Re: [VOTE] 2.0-M1 Release

With the addition of a license header to geronimo/server/tags/2.0-M1/ 
testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/ 
resources/META-INF/ejb-jar.xml, I'm +1.


--kevan

Re: [VOTE] Release XBean 2.8


On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote:


On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote:

 I'm starting a vote to release XBean 2.8.
 There has not been much changes since 2.7, but a few
 bugs fixed, and the addition of the xbean-finder module.
 Anyway, the bugs are important enough to deserver a new
 release (the generated schemas can not be validated).

 [ ] +1 Start xbean 2.8 release process
 [ ] +/- 0
 [ ] -1 Don't release xbean 2.8 now

 Here's my +1.

Not sure what you mean by release process.


Running mvn release:prepare release:perform ;)


But here are the issues
which look like they would block a release:

1. NOTICE files do not conform to current ASF standards


What do you mean exactly ?
They have the same content that the ones I've always seen.
Could you point me to a better template for these ?


2. The following files either do not contain a valid license header
(not all files will require one, but many of these need one) or have
an out-of-date license header (all need to be updated).


Thanks. I'll fix these asap.
You run rat for that, right ?



==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar1/
resource)
==resource (./xbean-classloader/src/test-data/resourceFinderTest/jar2/
resource)
==package-info.java (./xbean-finder/src/test/java/org/acme/foo/
package-info.java)
==java.io.InputStream (./xbean-finder/src/test/resources/META-INF/
java.io.InputStream)
==java.io.OutputStream (./xbean-finder/src/test/resources/META-INF/
java.io.OutputStream)
==java.io.Serializable (./xbean-finder/src/test/resources/META-INF/
java.io.Serializable)
==one (./xbean-finder/src/test/resources/META-INF/externalizables/one)
==three (./xbean-finder/src/test/resources/META-INF/externalizables/
three)
==two (./xbean-finder/src/test/resources/META-INF/externalizables/two)
==bar (./xbean-finder/src/test/resources/META-INF/
java.net.URLStreamHandler/bar)
==baz (./xbean-finder/src/test/resources/META-INF/
java.net.URLStreamHandler/baz)
==foo (./xbean-finder/src/test/resources/META-INF/
java.net.URLStreamHandler/foo)
==kernel (./xbean-finder/src/test/resources/META-INF/
javax.naming.spi.ObjectFactory/kernel)
==ldap (./xbean-finder/src/test/resources/META-INF/
javax.naming.spi.ObjectFactory/ldap)
==ishtar.properties (./xbean-finder/src/test/resources/META-INF/
movies/ishtar.properties)
==kingkong.properties (./xbean-finder/src/test/resources/META-INF/
movies/kingkong.properties)
==serentity.properties (./xbean-finder/src/test/resources/META-INF/
movies/serentity.properties)
==one (./xbean-finder/src/test/resources/META-INF/serializables/one)
==three (./xbean-finder/src/test/resources/META-INF/serializables/three)
==two (./xbean-finder/src/test/resources/META-INF/serializables/two)
==familyguy.properties (./xbean-finder/src/test/resources/META-INF/
tvshows/familyguy.properties)
==simpsons.properties (./xbean-finder/src/test/resources/META-INF/
tvshows/simpsons.properties)
==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/
package.html)
==package.html (./xbean-kernel/src/main/java/org/apache/xbean/kernel/
standard/package.html)
==pom.xml (./xbean-naming/pom.xml)
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
AbstractContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
AbstractFederatedContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ContextAccess.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ContextAccessControlList.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ContextFederation.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ContextFlyweight.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ContextUtil.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
ImmutableContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
NestedContextFactory.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
VirtualSubcontext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/context/
WritableContext.java
==xbean-naming/src/main/java/org/apache/xbean/naming/global/
GlobalContextManager.java
==xbean-naming/src/main/java/org/apache/xbean/naming/java/
javaURLContextFactory.java
==xbean-naming/src/main/java/org/apache/xbean/naming/reference/
CachingReference.java
==xbean-naming/src/main/java/org/apache/xbean/naming/reference/
SimpleReference.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
AbstractContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
ContextAccessControlListTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
FederationTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
ImmutableContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
UnmodifiableContextTest.java
==xbean-naming/src/test/java/org/apache/xbean/naming/context/
WritableContextTest.java

Performance Issue

2006-12-18 Thread garima015


I am facing a really bad performance of ActiveMq on linux box. 
When running on windows 1000 transactions are taking 2 seconds and when
running on Linux same are taking 40 sec. 
Please if anybody can tell me solution to performance issue. 

Here is the code i am using to send and receive the message. 

Thanks in advance 

public class Requestor{ 
private Session session; 
private Destination replyQueue; 
private MessageProducer requestProducer; 
private MessageConsumer replyConsumer; 
Logger logger = null; 

/** 
 * Constructor 
 */ 
protected Requestor() { 
super(); 
logger = LoggerWrapper.getLogger(this.getClass().getName()); 
} 

/** 
 * This method will return the object of Requestor 
 * @param connection, Connection 
 * @param requestQueueName , String 
 * @return  Requestor object 
 * @throws JMSException 
 * @throws NamingException 
 */ 
public static Requestor newRequestor(Connection connection, String
requestQueueName)throws JMSException, NamingException { 
Requestor requestor = new Requestor(); 
requestor.initialize(connection, requestQueueName); 
return requestor; 
} 

/** 
 * This method will initialize the Producer and Consumer on request
and reply queue 
 * @param connection, Connection 
 * @param requestQueueName , String 
 * @throws NamingException 
 * @throws JMSException 
 */ 
protected void initialize(Connection connection, String
requestQueueName)throws NamingException, JMSException { 
session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE); 
Destination requestQueue =
session.createQueue(requestQueueName); 

replyQueue = session.createTemporaryQueue(); 
requestProducer = session.createProducer(requestQueue); 
   
requestProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT); 
replyConsumer = session.createConsumer(replyQueue); 
replyConsumer.receive(10); 
} 

/** 
 * This method is used to send the message to queue 
 * @param message 
 * @throws JMSException 
 */ 
public String send(String message) throws JMSException { 
TextMessage requestMessage = (TextMessage)
session.createTextMessage(); 
requestMessage.setText(message); 
requestMessage.setJMSReplyTo(replyQueue); 
requestProducer.send(requestMessage); 
return receiveSync(); 
} 

/** 
 * This method is used to receive the message from the queue 
 * @return String 
 * @throws JMSException 
 */ 
private String receiveSync() throws JMSException { 
TextMessage replyMessage = null; 
Message msg =  replyConsumer.receive(); 

if (msg instanceof TextMessage){ 
replyMessage = (TextMessage) msg; 
} 
logger.debug(receive Sync:+ new Date().getTime()); 
return replyMessage.getText(); 
} 
} 

public class Replier implements MessageListener { 

private Session session; 
Logger logger = null; 
Engine engineRef = null; 
Transformer transformerRef = null; 
MessageConsumer requestConsumer = null; 
Destination replyDestination = null; 
private static Map destinationMap = new HashMap(); 
/** 
 * Constructor 
 * 
 */ 
protected Replier(){ 
super(); 
logger = LoggerWrapper.getLogger(this.getClass().getName()); 
} 

/** 
 * This will return the instance of replier 
 * @param connection, Connection 
 * @param requestQueueName 
 * @return 
 * @throws Exception 
 */ 
public static Replier newReplier(Connection connection,String
requestQueueName ,Engine engine,Transformer transformer)throws Exception { 
Replier replier = new Replier(); 
replier.initialize(connection,
requestQueueName,engine,transformer); 
return replier; 
} 

/** 
 * This method will initilize the consumer on request queue 
 * @param connection 
 * @param requestQueueName 
 * @throws Exception 
 */ 
protected void initialize(Connection connection, String
requestQueueName, Engine engine,Transformer transformer)throws Exception { 
session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE); 

// Create the destination (Topic or Queue) 
//Destination requestQueue =

Re: [VOTE] Release XBean 2.8



On Dec 18, 2006, at 1:31 PM, Guillaume Nodet wrote:


On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote:


On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote:

 I'm starting a vote to release XBean 2.8.
 There has not been much changes since 2.7, but a few
 bugs fixed, and the addition of the xbean-finder module.
 Anyway, the bugs are important enough to deserver a new
 release (the generated schemas can not be validated).

 [ ] +1 Start xbean 2.8 release process
 [ ] +/- 0
 [ ] -1 Don't release xbean 2.8 now

 Here's my +1.

Not sure what you mean by release process.


Running mvn release:prepare release:perform ;)


But here are the issues
which look like they would block a release:

1. NOTICE files do not conform to current ASF standards


What do you mean exactly ?
They have the same content that the ones I've always seen.
Could you point me to a better template for these ?


Hi Guillaume,

Yes, they've changed slightly... Source files no longer contain a  
copyright statement. Copyright is now in the notice file. Here's a  
pointer to the current standards -- http://www.apache.org/legal/src- 
headers.html


Notice files take the following form:

Apache [PRODUCT_NAME]
Copyright [] The Apache Software Foundation

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).

I don't see any external projects being included in xbean binaries.  
So, it would seem that's the only content that the NOTICE files would  
require.


I took a peak at the generated jar files. Looks like license/notice  
files are missing from at least the following jar file:


xbean-naming

Genesis will automatically check for these during a build. Dain (I  
think) had a one line command to scan for missing notice/license  
files, but I can't remember how it went...





2. The following files either do not contain a valid license header
(not all files will require one, but many of these need one) or have
an out-of-date license header (all need to be updated).


Thanks. I'll fix these asap.
You run rat for that, right ?


Yes, but rat doesn't identify old-style license headers. For these,  
I've found the following grep command to be useful:


grep -RL --include=*.java Licensed to the Apache Software Foundation  
(ASF) *


--kevan

Re: Release schedule

2006-12-18 Thread sileshi

Is 4.1 released? If not, what is rlelease plans?

-Sileshi

Hiram Chirino wrote:

On 10/4/06, yaussy [EMAIL PROTECTED] wrote:

Sorry about that. I'd forgotten about the wireformat stuff. Looks like
you
can set AMQ 4.1 minimum wire format to 1 and then it will connect to AMQ
4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work together).
This gives me the rollout path we need.

Since 4.0.2 has not been officially released, which 4.0.2 versin are
you using? RC4 ?

I think 4.0.2 RC 4 should be able to connecto the 4.1 without any
config changes. A small bug in 4.0 was fixed in 4.0.2 that fixes auto
wirefomat versin negociation.

Two things though:

1) I could not get multiple connection properties on the TCP connectors,
such as
tcp://perfgc1a::5112?minmumWireFormatVersion=1connectionTimeout=5000.
The
XML parser complained. How should this look??

in XML you need replace all the '' with 'amp;'

2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers connect
using their newer v2 format?

Hum they should. Sees odd that the default is not 1... it should be
1. I'll double check.

Thanks for testing this stuff out!

yaussy wrote:

I put a post in the user forum for this, but thought I'd add something
to
this thread. I'm concerned about backward compatibility. I've got a
test
environment with all brokers at 4.0.1, except one I'm upgrading to 4.1.
This would be how our production environment would be upgraded - a
machine
or so at a time.

However, the 4.0.1 brokers will not connect to the 4.1 broker, giving
the
following exception:

Exception in thread ActiveMQ Transport: tcp:///170.137.15.160:34695
java.lang.IllegalArgumentException: Invalid version: 2, could not l
oad org.apache.activemq.openwire.v2.MarshallerFactory
at

org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:329)
at

org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat(OpenWireFormat.java:569)
at

org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:100)
at

org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122)
at

org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87)
at

org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:143)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException:
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.util.ClassLoading.loadClass(ClassLoading.java:104)
at

org.apache.activemq.openwire.OpenWireFormat.setVersion(OpenWireFormat.java:327)
... 6 more

There must be an upgrade path for 4.1. If that means I have to go to
4.0.2 (which I did not try yet), that is OK. But, I can't possibly
tell
my management that I have to upgrade the AMQ version on all 50 or so
machines we have in production.

Hiram Chirino wrote:

I'm starting to work on the first release candidate for 4.1..

please let me know if I should hold off!

On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED]
wrote:

Hi James,

It looks like this is changed now with 4.0.3. Any idea when 4.1 is
going
to
be out? Thanks.
--
View this message in context:
http://www.nabble.com/Release-schedule-tf2124265.html#a6630219
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

--
Regards,
Hiram

Blog: http://hiramchirino.com

--
View this message in context:
http://www.nabble.com/Release-schedule-tf2124265.html#a6647640
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

--
Regards,
Hiram

Blog: http://hiramchirino.com

--
View this message in context:
http://www.nabble.com/Release-schedule-tf2124265.html#a7935126
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Re: Release schedule

2006-12-18 Thread Brian McCallister


4.1 has been released.

-Brian

On Dec 18, 2006, at 11:40 AM, sileshi wrote:



Is 4.1 released? If not, what is rlelease plans?

-Sileshi


Hiram Chirino wrote:


On 10/4/06, yaussy [EMAIL PROTECTED] wrote:


Sorry about that.  I'd forgotten about the wireformat stuff.   
Looks like

you
can set AMQ 4.1 minimum wire format to 1 and then it will connect  
to AMQ
4.0.2 (still breaks with AMQ 4.0.1, but 4.0.1 and 4.0.2 work  
together).

This gives me the rollout path we need.



Since 4.0.2 has not been officially released, which 4.0.2 versin are
you using? RC4 ?

I think 4.0.2 RC 4 should be able to connecto the 4.1 without any
config changes.  A small bug in 4.0 was fixed in 4.0.2 that fixes  
auto

wirefomat versin negociation.


Two things though:

1) I could not get multiple connection properties on the TCP  
connectors,

such as
tcp://perfgc1a::5112? 
minmumWireFormatVersion=1connectionTimeout=5000.

The
XML parser complained.  How should this look??


in XML you need replace all the '' with 'amp;'



2) Even with minmumWireFormatVersion=1, will two AMQ 4.1 brokers  
connect

using their newer v2 format?



Hum they should.  Sees odd that the default is not 1... it should be
1.  I'll double check.

Thanks for testing this stuff out!





yaussy wrote:


I put a post in the user forum for this, but thought I'd add  
something

to
this thread.  I'm concerned about backward compatibility.  I've  
got a

test
environment with all brokers at 4.0.1, except one I'm upgrading  
to 4.1.

This would be how our production environment would be upgraded - a

machine

or so at a time.

However, the 4.0.1 brokers will not connect to the 4.1 broker,  
giving

the

following exception:

Exception in thread ActiveMQ Transport: tcp:/// 
170.137.15.160:34695

java.lang.IllegalArgumentException: Invalid version: 2, could not l
oad org.apache.activemq.openwire.v2.MarshallerFactory
at

org.apache.activemq.openwire.OpenWireFormat.setVersion 
(OpenWireFormat.java:329)

at

org.apache.activemq.openwire.OpenWireFormat.renegociatWireFormat 
(OpenWireFormat.java:569)

at

org.apache.activemq.transport.WireFormatNegotiator.onCommand 
(WireFormatNegotiator.java:100)

at

org.apache.activemq.transport.InactivityMonitor.onCommand 
(InactivityMonitor.java:122)

at

org.apache.activemq.transport.TransportSupport.doConsume 
(TransportSupport.java:87)

at

org.apache.activemq.transport.tcp.TcpTransport.run 
(TcpTransport.java:143)

at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.ClassNotFoundException:
org.apache.activemq.openwire.v2.MarshallerFactory
at
org.apache.activemq.util.ClassLoading.loadClass 
(ClassLoading.java:104)

at

org.apache.activemq.openwire.OpenWireFormat.setVersion 
(OpenWireFormat.java:327)

... 6 more


There must be an upgrade path for 4.1.  If that means I have to  
go to

4.0.2 (which I did not try yet), that is OK.  But, I can't possibly

tell
my management that I have to upgrade the AMQ version on all 50  
or so

machines we have in production.


Hiram Chirino wrote:


I'm starting to work on the first release candidate for 4.1..

please let me know if I should hold off!

On 10/3/06, Vadim Pesochinsky [EMAIL PROTECTED]

wrote:


Hi James,

It looks like this is changed now with 4.0.3. Any idea when  
4.1 is

going

to
be out? Thanks.
--
View this message in context:
http://www.nabble.com/Release-schedule-tf2124265.html#a6630219
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





--
Regards,
Hiram

Blog: http://hiramchirino.com







--
View this message in context:
http://www.nabble.com/Release-schedule-tf2124265.html#a6647640
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.





--
Regards,
Hiram

Blog: http://hiramchirino.com




--
View this message in context: http://www.nabble.com/Release- 
schedule-tf2124265.html#a7935126

Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] Created: (SM-782) Re-deploy with In-Only Mep

2006-12-18 Thread JIRA

Re-deploy with In-Only Mep
--

 Key: SM-782
 URL: https://issues.apache.org/activemq/browse/SM-782
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-jms
Affects Versions: 3.1
 Environment: Linux x86/ Java (1.5.0_09)
Reporter: Grégoire A.



First deploy JMS-endpoint with target InOnly Service like Mail.
Run several call.
redeploy the same JMS-endpoint without modification.
And recall the service, u should have this exception. 
It could be a safe thread pb, this error is launched in 75% of the cases.

I think the context of the message cannot be refind.

ERROR - JmsComponent   - Error
processing exchange InOnly[
  id: ID:jjp-34393-1166462101789-6:229
  status: Done
  role: consumer
  service: {urn:fr.gouv.hello}mailSender
  endpoint: mailSender
  in: ?xml version=1.0
encoding=UTF-8?ns1:HashString
xmlns:ns1=http://tempuri.org/HashService/HashClass;
xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
xmlns:ZSI=http://www.zolera.com/schemas/ZSI/;
xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ns1:StrMessage
Change dans BPEL 4 JMS Service
/ns1:Strns1:HashTypeMD5/ns1:HashType/ns1:HashString
]
java.lang.NullPointerException
at
org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
at
org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
ERROR - JmsComponent   - Error setting
exchange status to ERROR
javax.jbi.messaging.MessagingException: illegal call
to send / sendSync
at
org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
at
org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
at
org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
at
org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
at
org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)

and this is my configuration
jms:endpoint service=hello:jmsReceiver
endpoint=HELLOJmsReceiver
targetService=hello:mailSender
role=consumer 
destinationStyle=queue
jmsProviderDestinationName=jms/queue/hello
connectionFactory=#jmsFactory
defaultMep=http://www.w3.org/2004/08/wsdl/in-only; /

FYI: when you block SMX with in a debugger, it seems to
work fine.

-- 
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: [VOTE] Release XBean 2.8


I've fixed the missing / bad ASF headers and use the new maven
plugin to generate LICENSE/NOTICE file.

On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote:


On Dec 18, 2006, at 1:31 PM, Guillaume Nodet wrote:

 On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote:

 On Dec 18, 2006, at 11:25 AM, Guillaume Nodet wrote:

  I'm starting a vote to release XBean 2.8.
  There has not been much changes since 2.7, but a few
  bugs fixed, and the addition of the xbean-finder module.
  Anyway, the bugs are important enough to deserver a new
  release (the generated schemas can not be validated).
 
  [ ] +1 Start xbean 2.8 release process
  [ ] +/- 0
  [ ] -1 Don't release xbean 2.8 now
 
  Here's my +1.

 Not sure what you mean by release process.

 Running mvn release:prepare release:perform ;)

 But here are the issues
 which look like they would block a release:

 1. NOTICE files do not conform to current ASF standards

 What do you mean exactly ?
 They have the same content that the ones I've always seen.
 Could you point me to a better template for these ?

Hi Guillaume,

Yes, they've changed slightly... Source files no longer contain a
copyright statement. Copyright is now in the notice file. Here's a
pointer to the current standards -- http://www.apache.org/legal/src-
headers.html

Notice files take the following form:

 Apache [PRODUCT_NAME]
 Copyright [] The Apache Software Foundation

 This product includes software developed at
 The Apache Software Foundation (http://www.apache.org/).

I don't see any external projects being included in xbean binaries.
So, it would seem that's the only content that the NOTICE files would
require.

I took a peak at the generated jar files. Looks like license/notice
files are missing from at least the following jar file:

xbean-naming

Genesis will automatically check for these during a build. Dain (I
think) had a one line command to scan for missing notice/license
files, but I can't remember how it went...


 2. The following files either do not contain a valid license header
 (not all files will require one, but many of these need one) or have
 an out-of-date license header (all need to be updated).

 Thanks. I'll fix these asap.
 You run rat for that, right ?

Yes, but rat doesn't identify old-style license headers. For these,
I've found the following grep command to be useful:

grep -RL --include=*.java Licensed to the Apache Software Foundation
(ASF) *

--kevan







--
Cheers,
Guillaume Nodet

Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml


Ugh... this is why I don't like all that moving of branches to tags...

A tag or label should never be modified... its a point in time,  
not indented (or expected) to be changed.


I believe that we would be doing ourselves a major favor by following  
some SCM best practices... moving branches to tags is not one of  
them... neither is changing code in a tag.


--jason


On Dec 18, 2006, at 8:35 AM, [EMAIL PROTECTED] wrote:


Author: kevan
Date: Mon Dec 18 08:35:24 2006
New Revision: 488326

URL: http://svn.apache.org/viewvc?view=revrev=488326
Log:
add missing license header

Modified:
geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ 
manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml


Modified: geronimo/server/tags/2.0-M1/testsuite/deployment- 
testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb- 
jar.xml
URL: http://svn.apache.org/viewvc/geronimo/server/tags/2.0-M1/ 
testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/ 
resources/META-INF/ejb-jar.xml? 
view=diffrev=488326r1=488325r2=488326
== 

--- geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ 
manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml  
(original)
+++ geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/ 
manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml  
Mon Dec 18 08:35:24 2006

@@ -1,4 +1,20 @@
 ?xml version=1.0 encoding=UTF-8?
+!--
+  Licensed to the Apache Software Foundation (ASF) under one or more
+  contributor license agreements.  See the NOTICE file distributed  
with

+  this work for additional information regarding copyright ownership.
+  The ASF licenses this file to You under the Apache License,  
Version 2.0
+  (the License); you may not use this file except in compliance  
with

+  the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+  Unless required by applicable law or agreed to in writing, software
+  distributed under the License is distributed on an AS IS BASIS,
+  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or  
implied.

+  See the License for the specific language governing permissions and
+  limitations under the License.
+--
 ejb-jar version=2.1
  xmlns=http://java.sun.com/xml/ns/j2ee;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

Re: [VOTE] 2.0-M1 Release


+1

I don't think we should spend too much time on this release.  Lets  
just note the issues we run into and try to fix them for M2, possibly  
implementing more build support to help us avoid more legal-related  
issues, which seem to be the bulk of problems we run into.


--jason


On Dec 18, 2006, at 12:57 AM, Matt Hogstrom wrote:


All,

I have prepared 2.0-M1 for release.  Of course all the hard work  
was done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm  
satisfied with the results.  All modes of operation functioned well  
(SLSB, Direct, EJB and JPA).  I toned all the logs down to error to  
not overwhelm the users with lots of diagnostic output (they can  
always turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts  
trickle in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
for your review and testing.  I've included both Tomcat and Jetty  
as well as the minimal and j5ee assemblies.  The source code is  
also there.


Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  
do this is to modify the root pom and add a repository for David's  
home directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
and will be putting them into our SVN for folks who may want to  
build in the future.  I'm not too concerned about repeatability as  
this Milestone will be superseded at the end of January with the  
next version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine  
this build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new  
one will start.


Matt Hogstrom
[EMAIL PROTECTED]

Re: [DISCUSS] 2.0-M1 Release

2006-12-18 Thread Hernan Cunico


Rerouting to this thread from [VOTE] 2.0-M1 Release

Hi All,
I have two basic comments/questions.

1- I see a bunch of INFO messages in both Tomcat and Jetty at startup, not a 
show stopper for this release.

2- Deployment on Jetty is not behaving exactly as I expected. Not sure if I 
messed up the deployment plans given the new specs, however this same WAR works 
just fine with Tomcat.
In Jetty I deploy a WAR and when I access the application it will list the content of 
the WAR, if I click on the JSP it will work fine. Something like not following the 
web.xml welcome-file maybe? The context-root however is correct.

Just in case you may ask, here are the deployment plans:

geronimo-web.xml
==
?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.2;
   environment
   moduleId
   groupIdsample.applications/groupId
   artifactIdHelloWorldApp/artifactId
   version2.0/version
   typewar/type
   /moduleId 
   /environment

   context-root/hello/context-root
/web-app
==


web.xml
==
?xml version=1.0 encoding=UTF-8?

web-app version=2.4

  xmlns=http://java.sun.com/xml/ns/j2ee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
  http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;

   welcome-file-list
welcome-fileHelloWorld.jsp/welcome-file
   /welcome-file-list

/web-app
==

Am I missing anything obvious?

Cheers!
Hernan 


Matt Hogstrom wrote:

All,

I opened this thread for general comments and questions about the 
release.  Let's have the discussions here and leave the vote thread for 
+/- voting only so it will be easier to process


Thanks.

Matt Hogstrom
[EMAIL PROTECTED]

[jira] Closed: (GERONIMO-2648) Integrate JSF 1.2 into 2.0-M1

2006-12-18 Thread Tim McConnell (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2648?page=all ]

Tim McConnell closed GERONIMO-2648.
---

Resolution: Fixed

Integrated into 2.0-M1 build

 Integrate JSF 1.2 into 2.0-M1
 -

 Key: GERONIMO-2648
 URL: http://issues.apache.org/jira/browse/GERONIMO-2648
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 2.0-M1
Reporter: Tim McConnell
 Assigned To: Tim McConnell
 Fix For: 2.0-M1

 Attachments: GERONIMO-2648.patch, modules.zip




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



On Dec 18, 2006, at 3:44 PM, Guillaume Nodet wrote:


I've fixed the missing / bad ASF headers and use the new maven
plugin to generate LICENSE/NOTICE file.


Looks like the following still needs some attention:

xbean-spring-v1/pom.xml

These all have old style license headers. Sorry, I didn't spot them  
last scan.


xbean-spring-v2/src/site/site.xml
xbean-spring-v2a/src/site/site.xml
xbean-spring-v2b/src/site/site.xml
xbean-spring-v2c/src/site/site.xml

I'm done, after that... ;-)

--kevan

Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml



On Dec 18, 2006, at 3:45 PM, Jason Dillon wrote:


Ugh... this is why I don't like all that moving of branches to tags...

A tag or label should never be modified... its a point in time,  
not indented (or expected) to be changed.


I believe that we would be doing ourselves a major favor by  
following some SCM best practices... moving branches to tags is not  
one of them... neither is changing code in a tag.


I'm sympathetic to your concern. However, we don't (to my knowledge)  
have a documented release process for our projects. So, we're  
currently leaving these practices in the hands of our release  
managers. In this case, I did what the release manager asked me to do...


So, what do you feel would be the appropriate techniques for building  
a release?


--kevan

openejb-2.2 tag is not buildable

I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2 release  
tag is not buildable in a clean environment:


snip
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   OpenEJB
[INFO]   OpenEJB :: Modules
[INFO]   OpenEJB :: Core
[INFO]   OpenEJB :: Axis
[INFO]   OpenEJB :: PK Generation :: Builder
[INFO]   OpenEJB :: CORBA
[INFO]   OpenEJB :: Builder
[INFO]   OpenEJB :: CORBA Builder
[INFO]   OpenEJB :: CORBA :: Yoko
[INFO]   OpenEJB :: iTests
[INFO]   OpenEJB :: iTests :: Core
[INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- 
plugin:1.1-SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis.plugins:tools-maven- 
plugin:1.1-SNAPSHOT: checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools- 
maven-plugin-1.1-20061214.032036-20.pom

1K downloaded
[INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- 
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis.plugins:plugins:1.1- 
SNAPSHOT: checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/plugins/plugins/1.1-SNAPSHOT/ 
plugins-1.1-20061214.032036-13.pom

9K downloaded
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT:  
checking for updates from codehaus-snapshots
[INFO] snapshot org.apache.geronimo.genesis:genesis:1.1-SNAPSHOT:  
checking for updates from apache-snapshots
Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/ 
apache/geronimo/genesis/genesis/1.1-SNAPSHOT/ 
genesis-1.1-20061214.032036-13.pom

10K downloaded
Downloading: http://repository.codehaus.org/org/apache/apache/3/ 
apache-3.pom
[WARNING] Unable to get resource from repository codehaus (http:// 
repository.codehaus.org)
Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/ 
apache-3.pom

3K downloaded
Downloading: http://snapshots.repository.codehaus.org/org/apache/ 
geronimo/genesis/plugins/tools-maven-plugin/1.1-SNAPSHOT/tools-maven- 
plugin-1.1-SNAPSHOT.jar
[WARNING] Unable to get resource from repository codehaus-snapshots  
(http://snapshots.repository.codehaus.org)
[INFO]  


[ERROR] BUILD ERROR
[INFO]  

[INFO] Plugin could not be found - check that the goal name is  
correct: Unable to download the artifact from any repository

Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file - 
DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- 
plugin \
-Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ 
to/file
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
[INFO]  


[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Plugin could  
not be found - check that the goal name is correct: Unable to  
download the artifact from any repository

Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file - 
DgroupId=org.apache.geronimo.genesis.plugins -DartifactId=tools-maven- 
plugin \
-Dversion=1.1-SNAPSHOT -Dpackaging=maven-plugin -Dfile=/path/ 
to/file
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
  org.apache.geronimo.genesis.plugins:tools-maven-plugin:maven- 
plugin:1.1-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus (http://repository.codehaus.org),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.findExtensions 
(DefaultLifecycleExecutor.java:179)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute 
(DefaultLifecycleExecutor.java:138)

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

[jira] Created: (AMQ-1102) Infinite loop from broker's network connector when using multiple durable subscribers (topics) with msg selector.

2006-12-18 Thread Samson (JIRA)

Infinite loop from broker's network connector when using multiple durable 
subscribers (topics) with msg selector.
-

 Key: AMQ-1102
 URL: https://issues.apache.org/activemq/browse/AMQ-1102
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 4.1.0
 Environment: Linux
Reporter: Samson


The following is the series of messages resulting from the broker (infinite 
loop):

INFO  DemandForwardingBridge - Network connection between 
vm://localhost#0 and tcp://localhost/127.0.0.1:61601 shutdown due to a local 
error: javax.jms.JMSException: Durable consumer is in use for client: 
NC_SWITCH1BROKER_inboundlocalhost and subscriptionName: localhost_TEST.FOO
INFO  TransportConnector - Connector vm://localhost Stopped
INFO  NetworkConnector   - Establishing network connection between 
from vm://localhost?network=true to tcp://switch:61601
INFO  TransportConnector - Connector vm://localhost Started
INFO  DemandForwardingBridge - Network connection between 
vm://localhost#2 and tcp://localhost/127.0.0.1:61601(SWITCH1BROKER) has been 
established.
INFO  DemandForwardingBridge - Network connection between 
vm://localhost#2 and tcp://localhost/127.0.0.1:61601 shutdown due to a local 
error: javax.jms.JMSException: Durable consumer is in use for client: 
NC_SWITCH1BROKER_inboundlocalhost and subscriptionName: localhost_TEST.FOO
INFO  TransportConnector - Connector vm://localhost Stopped
...


EXACT STEPS TO REPRODUCE:

1  -Start standalone broker
-using default conf/activemq.xml file

2  -Start EmbeddedBroker (with network connector specified):
BrokerService broker = new BrokerService();
broker.setUseJmx(true);
broker.setBrokerName(SWITCH1BROKER);

TransportConnector connector =
broker.addConnector(new URI(tcp://localhost:+61601));
connector.setDiscoveryUri(new URI(multicast://default));
broker.addNetworkConnector(new URI(multicast://default));

broker.start();

At this point, I'll get the following output (which looks normal):

INFO  NetworkConnector   - Establishing network connection between 
from vm://localhost?network=true to tcp://switch:61601
INFO  TransportConnector - Connector vm://localhost Started
INFO  DemandForwardingBridge - Network connection between 
vm://localhost#0 and tcp://localhost/127.0.0.1:61601(SWITCH1BROKER) has been 
established.


3.  -Edit line 105 of ConsumerTool to specify any message selector
consumer = session.createDurableSubscriber((Topic) destination,
consumerName, BLAH = '1', false);

4.  -Start ConsumerTool with clientID consumer1
-connect to tcp://localhost:61601
-using topics, durable subscription, w/ message selector

5.  -Start ConsumerTool with clientID consumer2
-connect to tcp://localhost:61601
-using topics, durable subscription, w/ message selector



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

sm 3.0 build fails under java 6

2006-12-18 Thread timbo


however, binary seems to execute fine.

--

(x86 linux - FC5, sun jdk 1.6.0,
apache-servicemix-3.0-incubating-src.tar.gz)

mvn -Dmaven.test.skip=true -Dprofile=step2 install
...
[INFO] [compiler:compile]
Compiling 114 source files to
/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36]
cannot find symbol
symbol  : method createNamespace()
location: interface javax.script.ScriptEngine

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26]
cannot find symbol
symbol  : method eval(javax.script.Namespace)
location: class javax.script.CompiledScript

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14]
cannot find symbol
symbol  : method eval(java.lang.String,javax.script.Namespace)
location: interface javax.script.ScriptEngine

-- 
View this message in context: 
http://www.nabble.com/sm-3.0-build-fails-under-java-6-tf2842650s12049.html#a7937393
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.

[jira] Closed: (SM-521) Tuning parameters configuration

 [ https://issues.apache.org/activemq/browse/SM-521?page=all ]

Guillaume Nodet closed SM-521.
--

Resolution: Duplicate

Thread pools can be configured with the ExecutorFactory on the jbi container.
Throttling should be configurable on a per endpoint basis.

 Tuning parameters configuration
 ---

 Key: SM-521
 URL: https://issues.apache.org/activemq/browse/SM-521
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-core
Reporter: Guillaume Nodet
 Fix For: 3.1


 We need to provide a way to configure tuning parameters for servicemix:
   * thread pools (core + flows + seda queues + components )
   * queues (delivery channels + seda queues)
   * component throttling
 This may need a way to configure dummy activationSpecs (with no components, 
 only the component name)
 so that we can configure these parameters when using JBI std installation

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

[jira] Updated: (SM-745) Allow usage of other JMS providers than ActiveMQ

 [ https://issues.apache.org/activemq/browse/SM-745?page=all ]

Guillaume Nodet updated SM-745:
---

Fix Version/s: (was: 3.1)

 Allow usage of other JMS providers than ActiveMQ
 

 Key: SM-745
 URL: https://issues.apache.org/activemq/browse/SM-745
 Project: ServiceMix
  Issue Type: Improvement
Affects Versions: 3.0.1
Reporter: Christian Schneider
 Attachments: jmsflow.patch, jmsflow.patch, jmsflow2.patch, 
 jmsflow3.patch


 JMSFlow and JCA flow are too tightly bound to ActiveMQ. Instead of ActiveMQ 
 specific classes jms Interfaces should be used where possible.
 I have attached a patch that replaces ActiveMQConnection and 
 ActiveMQConnectionFactory by the jms equivalents.
 There is one possible issue with my patch.  The getConnectionFactory now 
 returns a ConnectionFactory instead of a ActiveMQConnectionFactory. I don´t 
 know if any other part of the sources depends on the specific class.
 My patch is of course only the first step. The next could be having a 
 specific subclass JMSFlowActiveMQ that does all stuff that is ActiveMQ 
 specific.
 I will deliver a second patch for this.

-- 
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: sm 3.0 build fails under java 6


It seems we use an older version of jsr223.
It has just gone final a few days ago, and there are lots
of changes from the version we currently use.
Could you please raise a JIRA for that ?

On 12/18/06, timbo [EMAIL PROTECTED] wrote:


however, binary seems to execute fine.

--

(x86 linux - FC5, sun jdk 1.6.0,
apache-servicemix-3.0-incubating-src.tar.gz)

mvn -Dmaven.test.skip=true -Dprofile=step2 install
...
[INFO] [compiler:compile]
Compiling 114 source files to
/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes
[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] Compilation failure

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36]
cannot find symbol
symbol  : method createNamespace()
location: interface javax.script.ScriptEngine

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26]
cannot find symbol
symbol  : method eval(javax.script.Namespace)
location: class javax.script.CompiledScript

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14]
cannot find symbol
symbol  : method eval(java.lang.String,javax.script.Namespace)
location: interface javax.script.ScriptEngine

--
View this message in context: 
http://www.nabble.com/sm-3.0-build-fails-under-java-6-tf2842650s12049.html#a7937393
Sent from the ServiceMix - Dev mailing list archive at Nabble.com.





--
Cheers,
Guillaume Nodet

Re: [VOTE] Release XBean 2.8


Done :)

On 12/18/06, Kevan Miller [EMAIL PROTECTED] wrote:


On Dec 18, 2006, at 3:44 PM, Guillaume Nodet wrote:

 I've fixed the missing / bad ASF headers and use the new maven
 plugin to generate LICENSE/NOTICE file.

Looks like the following still needs some attention:

xbean-spring-v1/pom.xml

These all have old style license headers. Sorry, I didn't spot them
last scan.

xbean-spring-v2/src/site/site.xml
xbean-spring-v2a/src/site/site.xml
xbean-spring-v2b/src/site/site.xml
xbean-spring-v2c/src/site/site.xml

I'm done, after that... ;-)

--kevan




--
Cheers,
Guillaume Nodet

[jira] Commented: (SM-782) Re-deploy with In-Only Mep

[ 
https://issues.apache.org/activemq/browse/SM-782?page=comments#action_37723 ] 

Guillaume Nodet commented on SM-782:


I think the problem comes from the fact that the endpoint is re-deployed.
In such a case, another instance of the endpoint will be created, so that
the pendingMessages map will be lost.

For InOnly meps, it should be easy, as you said, to bypass this in case of DONE 
status.
For ERROR status, well, not sure yet.

For other meps, a better may be to extract the needed informations and put them 
as
properties (they must be serializable) on the exchange, so that the jms 
component
does not need to keep any state (hence, another component should be able
to handle the answer if needed).

 Re-deploy with In-Only Mep
 --

 Key: SM-782
 URL: https://issues.apache.org/activemq/browse/SM-782
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-jms
Affects Versions: 3.1
 Environment: Linux x86/ Java (1.5.0_09)
Reporter: Grégoire A.

 First deploy JMS-endpoint with target InOnly Service like Mail.
 Run several call.
 redeploy the same JMS-endpoint without modification.
 And recall the service, u should have this exception. 
 It could be a safe thread pb, this error is launched in 75% of the cases.
 I think the context of the message cannot be refind.
 ERROR - JmsComponent   - Error
 processing exchange InOnly[
   id: ID:jjp-34393-1166462101789-6:229
   status: Done
   role: consumer
   service: {urn:fr.gouv.hello}mailSender
   endpoint: mailSender
   in: ?xml version=1.0
 encoding=UTF-8?ns1:HashString
 xmlns:ns1=http://tempuri.org/HashService/HashClass;
 xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/;
 xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/;
 xmlns:ZSI=http://www.zolera.com/schemas/ZSI/;
 xmlns:xsd=http://www.w3.org/2001/XMLSchema;
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;ns1:StrMessage
 Change dans BPEL 4 JMS Service
 /ns1:Strns1:HashTypeMD5/ns1:HashType/ns1:HashString
 ]
 java.lang.NullPointerException
 at
 org.apache.servicemix.jms.multiplexing.MultiplexingConsumerProcessor.process(MultiplexingConsumerProcessor.java:105)
 at
 org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:490)
 at
 org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:464)
 at
 org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46)
 at
 org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
 at
 org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
 at
 org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
 at
 org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
 at
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
 at
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
 at java.lang.Thread.run(Thread.java:595)
 ERROR - JmsComponent   - Error setting
 exchange status to ERROR
 javax.jbi.messaging.MessagingException: illegal call
 to send / sendSync
 at
 org.apache.servicemix.jbi.messaging.MessageExchangeImpl.handleSend(MessageExchangeImpl.java:571)
 at
 org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.doSend(DeliveryChannelImpl.java:350)
 at
 org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.send(DeliveryChannelImpl.java:397)
 at
 org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:58)
 at
 org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:610)
 at
 org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174)
 at
 org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176)
 at
 org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
 at
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
 at
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
 at java.lang.Thread.run(Thread.java:595)
 and this is my configuration
 jms:endpoint service=hello:jmsReceiver
 endpoint=HELLOJmsReceiver
 targetService=hello:mailSender
 role=consumer 
 destinationStyle=queue
 jmsProviderDestinationName=jms/queue/hello
 connectionFactory=#jmsFactory
 defaultMep=http://www.w3.org/2004/08/wsdl/in-only; /
 FYI: when you block SMX with in a debugger, it seems to
 work fine.

-- 
This message is

Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)



On Dec 18, 2006, at 3:45 PM, Jason Dillon wrote:


Ugh... this is why I don't like all that moving of branches to tags...



I agree

A tag or label should never be modified... its a point in time,  
not indented (or expected) to be changed.


I believe that we would be doing ourselves a major favor by  
following some SCM best practices... moving branches to tags is not  
one of them... neither is changing code in a tag.




Dain ran into a similar problem where while releasing he had an issue  
that a utility as part of the release process caused him to make a  
change to source because of a variable name.


For the milestone I'm not concerned but I am concerned that we get  
the release process documented and agreed to.  We're not going to fix  
these two release processes.


I am writing up on the CWiki my thoughts for release that I'd like to  
get ironed out BEFORE we get to the next release.  Not that we've  
done anything wrong but I feel this process is too fluid as we've  
changed it almost every release.  This includes changes to voting,  
releasing, and build tools.  We've worked through them each time and  
no process will be perfect but we should be refining something each  
time and not creating something new.


Here are my list of items to start with:

Define release in terms of Milestone, Beta, Full Version
- includes definition of user expectations
- quality of the release
- logging level consistency
- Release Notes content
- Packing list for delivered content
- Naming conventions for delivered modules (ala manually created source)

Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)

- includes tags and modifications

Including non-released artifacts and how they are handeled and where  
they go


Voting time lines and expectations
- Things like VOTE and DISCUSS threads
- when do they get restarted (or do they)...how to handle issues like  
changes to the tree that were no previously caught

- Is there a limit where the 72 hour timeline is satisfied previously?

Ok, these are a few of my favorite things.  Actually, this is a lot  
of process but to Jason's concern (which I agree with) we need to  
lock this down.


Matt Hogstrom
[EMAIL PROTECTED]

[jira] Updated: (SM-749) JSR181 component does not generate WSDL types for JAXB2-annotated classes

 [ https://issues.apache.org/activemq/browse/SM-749?page=all ]

Guillaume Nodet updated SM-749:
---

Fix Version/s: (was: incubation)

 JSR181 component does not generate WSDL types for JAXB2-annotated classes
 -

 Key: SM-749
 URL: https://issues.apache.org/activemq/browse/SM-749
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-jsr181
Affects Versions: 3.0.1
 Environment: JSE 6 RC, Win XP
Reporter: Los Morales
 Attachments: jira_sm749 reproduce.zip


 JSR181 component fails to unmarshal data from an XML document into 
 JAXB2-annotated objects because the WSDL for types does not get properly 
 generated.  Similar to an already existing issue: 
 (https://brutus.apache.org/activemq/browse/SM-739), the bug(s) seem to occur 
 only when the POJOs have JAXB2 annotations.  Removing these annotations seem 
 to produce the proper WSDL (with all the respective types) when the JSR181 
 component is deployed (using JConsole), although the unmarshaling still does 
 not work due to the missing annotations.  The complete thread regarding this 
 issue can be found here:  
 http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html

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

[jira] Resolved: (SM-704) FTPPoller Improvements

 [ https://issues.apache.org/activemq/browse/SM-704?page=all ]

Guillaume Nodet resolved SM-704.


Resolution: Fixed
  Assignee: Guillaume Nodet

 FTPPoller Improvements
 --

 Key: SM-704
 URL: https://issues.apache.org/activemq/browse/SM-704
 Project: ServiceMix
  Issue Type: Improvement
  Components: servicemix-ftp
Affects Versions: 3.0
 Environment: Windows XP SP2; JSE 6 Beta 2
Reporter: Los Morales
 Assigned To: Guillaume Nodet
Priority: Minor
 Fix For: 3.1


 In the org.apache.servicemix.components.net.FTPPoller class, there are two 
 things that can be improved upon.
 1)  Give the option to NOT delete the files from the FTP server by adding a 
 deleteFile attribute w/ corresponding accessors.  In order to make this work, 
 you will also need to keep track of the files already retrieved by using the 
 java.util.concurrent.CopyOnWriteArraySet to keep track of each FTPFile's raw 
 listing.
 2) In the processFile() method, move the client.completePendingCommand() 
 line AFTER the call to in.close().  Sometimes  my program would hang 
 indefinitely when the call to completePendingCommand() was done prior to 
 closing the input stream.  This situation is discussed here as well:  
 http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200412.mbox/[EMAIL
  PROTECTED]
 -los

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

[jira] Created: (SM-783) build fails under java 6

2006-12-18 Thread tim biernat (JIRA)

build fails under java 6 
-

 Key: SM-783
 URL: https://issues.apache.org/activemq/browse/SM-783
 Project: ServiceMix
  Issue Type: Bug
  Components: servicemix-components
Affects Versions: 3.0
 Environment: x86 linux - FC5, sun jdk 1.6.0, 
apache-servicemix-3.0-incubating-src.tar.gz
Reporter: tim biernat
Priority: Minor


mvn -Dmaven.test.skip=true -Dprofile=step2 install
...
[INFO] [compiler:compile]
Compiling 114 source files to 
/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/target/classes
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[210,36]
 cannot find symbol
symbol  : method createNamespace()
location: interface javax.script.ScriptEngine

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[261,26]
 cannot find symbol
symbol  : method eval(javax.script.Namespace)
location: class javax.script.CompiledScript

/home/tbiernat/work/servicemix/apache-servicemix-3.0-incubating/src/servicemix-components/src/main/java/org/apache/servicemix/components/script/ScriptComponent.java:[269,14]
 cannot find symbol
symbol  : method eval(java.lang.String,javax.script.Namespace)
location: interface javax.script.ScriptEngine 

-- 
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: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml


On Dec 18, 2006, at 1:49 PM, Kevan Miller wrote:
A tag or label should never be modified... its a point in  
time, not indented (or expected) to be changed.


I'm sympathetic to your concern. However, we don't (to my  
knowledge) have a documented release process for our projects. So,  
we're currently leaving these practices in the hands of our release  
managers.


I understand why you did this... and I think that SVN is probably  
more to blame for this by how its implemented tagging.  Most source  
control systems simply don't allow your to make code changes to a  
label/tag, most will allow retag from another branch, but not  
modification of the label directly.  But svn implements tags as  
branches which forces the policy of what is a tag and what is a  
branch on to the users... which has a rather nasty side-effect of  
never really knowing if a tagged code line is a label or a branch.


In this case, it would have been better if there was still a 2.0-M1  
branch, and you made this change to the branch, and then re-tagged  
the changed file.


I really don't think that moving branches to tags, or tags to  
branches is a good idea at all... even though svn will let you do  
that.  Keep the branch around so that you can use it to make changes  
you need to, and then always copy to tag... and never change code on  
a tag, assume its read-only.




In this case, I did what the release manager asked me to do...


Well, I might have asked if they were smoking crack... and to give me  
some.  :-P


I would not recommend doing it again though.  I believe that  
following some best practices for scm (as well as build) will really  
improve on Geronimo's ability to deliver in the long term.  Little  
short-cuts like this will add up over time and slow down the machine  
considerably.



So, what do you feel would be the appropriate techniques for  
building a release?


This doesn't really related directly to the issue of changing code in  
a tag... though it is somewhat related.  And this question is a bit  
of a loaded gun... but here are some of my thoughts, incomplete as  
they maybe at the moment:


I believe that the process of releasing should be automated, and more  
so delegated to a well known environment.  Automation of releases  
helps to ensure that releases are repeatable and reduce the chances  
of user error, which in generally will improve the quality and  
trustworthiness of releases.  Releases should be performed in a well  
known environment so that local environmental changes do not  
adversely affect the contents or quality of a release.


I believe that once a release is made (and I mean voted out and  
official), that no changes should ever be made to that release.  If  
*anything* needs to be *fixed*, then cut a new release, *never,  
never, never* change the release.


Release tags should really be buildable at anytime... be it one day,  
2 weeks, 3 years.  I know that as time passes the chances of this  
holding true begin to diminish, but it is something that we should  
aim for.  With the proper tools and environment it should be possible  
to ensure that each release builds durability is in the years, if not  
decades rather than months.


Related to ASF-style releasing, which I still think is a bit odd, but  
the whole make a release, then vote on the release, maybe re- 
cutting the same release, might be better of using a branch for code  
changes (for the recutting), and then a label per cycle, and once a  
label is finally blessed it can be renamed to the official release  
tag.  It is just confusing to move branches to tags, and then back to  
branches, and then tags again as we move through this process.  I  
think we also should include some sort of release/build iteration for  
times when we bounce back and forth... for example, 1.2-beta-1 (is  
the first), 1.2-beta-2 (is the second).  This is commonly used by RPM  
packagers, where each package has its iteration, and often the  
iteration that is final is not -1, but more like -3 or -4.  This is  
quite natural if you think of tags as permanent and non-changing...  
which I suggest is the best way to consider them for releases...  
though don't get me wrong, when using a promotion model, or for  
things like tagging last successful nightly builds, etc, then mutable  
tags are useful, but definitely not for releases.


 * * *

I'm sure that I can come up with more... but I think the most  
important part is the automation... release made by me, or by you or  
by anyone else on the team, should be for the most part identical.  I  
believe that the other bits, like svn tag policy, build iteration  
inclusion, etc, all fit together as pieces of the automation  
puzzle... and in many cases come naturally once you start to think  
about the problem as a set of repeatable steps to take that which can  
be applied to any project for releases, ci, nightly builds, etc.  To  
make all of those work using more or less the same

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)


On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:
Dain ran into a similar problem where while releasing he had an  
issue that a utility as part of the release process caused him to  
make a change to source because of a variable name.


Was this before or after the release tag was made?  Can you elaborate  
on this?  Or maybe Dain can, so that I can understand better.


I know of several issues with the release plugin, I actually think  
that its only useful as part of an automated release solution, still  
need some additional build help and sanity checks to ensure that when  
its time to make a release, that everything is going to be happy.



For the milestone I'm not concerned but I am concerned that we get  
the release process documented and agreed to.  We're not going to  
fix these two release processes.


I  agree, though I hope we can fix some of these issues before M2  
goes out.


My point about the ci to tags however could have been avoided, by  
keeping the branch (not moving it to tags) and then copying to label,  
as is the recommended method to label things in svn.  It was also  
more general that relating to releases... generally assume that a tag  
is read-only.  Don't mv a branch to a tag, copy it.



I am writing up on the CWiki my thoughts for release that I'd like  
to get ironed out BEFORE we get to the next release.  Not that  
we've done anything wrong but I feel this process is too fluid as  
we've changed it almost every release.  This includes changes to  
voting, releasing, and build tools.  We've worked through them each  
time and no process will be perfect but we should be refining  
something each time and not creating something new.


Well, I think a ci to a tag *was* wrong :-P  But other than that I  
basically agree.




Here are my list of items to start with:

Define release in terms of Milestone, Beta, Full Version
- includes definition of user expectations
- quality of the release


Yikes... not sure what either of these might actually be... can you  
give an example of what these might look like for 2.0-M1?




- logging level consistency


Um... you know that this one will differer based on which user  
consumes it right?  Open-source-savvy user might expect INFO, where  
Joe-consumer-embedder, might expect its ERROR (and both may flag it  
as broke if its not what they expected).


Not sure who the default release configuration should be tailored  
to... and god no... I'm not suggesting we make a release for each of  
them :-P




- Release Notes content


Yes, this is important... and IMO should be driven off of JIRA for  
that version as well as including detail about specific changes.


I think that the AMQ folks do this well... as well as that Atlassian  
folks.  I recommend we copy them.




- Packing list for delivered content


Eh, I don't care too much about this really.  Though if it can be  
automated, then maybe it okay, else I see this as a non-important  
document which will quickly become out of date, and out of date  
documented is more harmful than it is useful.  Though a general  
README.txt which explains the basic top-level directories should be  
good, and easy to maintain.



- Naming conventions for delivered modules (ala manually created  
source)


Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)

- includes tags and modifications


Yes, it should... though the svn book covers most of this, I don't  
recommend we drift to far from it.



Including non-released artifacts and how they are handeled and  
where they go


Its been almost 6 months and I am still staying the same thing... we  
need our own repo, backed our svn, which can contain these bits... as  
the time to wait for other projects to release is crazy (especially  
if they too are ASF projects bound by the same style of release hell).


Having our own svn backed repo allows us to always have the right  
versions of artifacts, labeled with our source, which helps increase  
the changes that codelines are buildable far into the future.  And  
even if our repo is only subset, and the rest are pulled from central  
for starting out, we are in a better position.  Even better to have  
*everything* in our svn repo, but that might be more work to  
implement than any of us have time right now.




Voting time lines and expectations
- Things like VOTE and DISCUSS threads
- when do they get restarted (or do they)...how to handle issues  
like changes to the tree that were no previously caught

- Is there a limit where the 72 hour timeline is satisfied previously?


NOTE, if our release process was automated, then the time/effort to  
build a release would be minimal.  We could easily spin off a  
version-VOTING-n build, and then once it passes, simply rebuild  
the exact same thing as a final.  This is one significant advantage  
to building off of source control (either be it sources, or binaries  
checked in).  But

Re: [VOTE] 2.0-M1 Release


+1

-David

On Dec 18, 2006, at 12:57 AM, Matt Hogstrom wrote:


All,

I have prepared 2.0-M1 for release.  Of course all the hard work  
was done by the lot of y'all :)


I have tested DayTrader 2.0-SNAPSHOT on this build and I'm  
satisfied with the results.  All modes of operation functioned well  
(SLSB, Direct, EJB and JPA).  I toned all the logs down to error to  
not overwhelm the users with lots of diagnostic output (they can  
always turn it up later if they want.)


The uploads are taking forever so you'll see some piece parts  
trickle in.  For the review I expect you'll want to focus on http:// 
people.apache.org/~hogstrom/2.0-M1 as this contains the assemblies  
for your review and testing.  I've included both Tomcat and Jetty  
as well as the minimal and j5ee assemblies.  The source code is  
also there.


Note that if you are planning on building you'll need to obtain the  
openejb-2.2-incubating jars to your local repo.  The easiest way to  
do this is to modify the root pom and add a repository for David's  
home directory at http://people.apache.org/~dblevins/stage/.


For SNAPSHOTs of certain plugins I have resolved these files to the  
most recent SNAPSHOT date / timestamp.  I'm pulling a copy of these  
and will be putting them into our SVN for folks who may want to  
build in the future.  I'm not too concerned about repeatability as  
this Milestone will be superseded at the end of January with the  
next version.


The other MAven artifacts will be trickling onto people across my  
horribly slow home pipe and dropped into http://people.apache.org/ 
~hogstrom/stage over the next few hours.


Please review and cast your vote early.  The faster we determine  
this build is good or if there is an issue the better.


Thanks in advance for all your help in this effort.

This vote will conclude at 0400 ET on Dec 21 (unless all you PMC  
members vote quicker :)


If a respin is is necessary this vote will be suspended and a new  
one will start.


Matt Hogstrom
[EMAIL PROTECTED]

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)



On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:

Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)

- includes tags and modifications


Discussion, proposal, resolution and final vote.

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

Granted that was June, just about time to do it all over again :)

In regards to the commit to the tag, I don't have a problem with it  
as it was completely ineffectual in any technical sense.  We could of  
course thump the rule book and make Matt redo 8+ hours of work and  
have days worth of revoting followed up by a couple weeks worth of  
cumulative man hours on policy discussions... or we could just say  
close enough and focus on 2.0-M2.


-David

Re: openejb-2.2 tag is not buildable



On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote:

I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2  
release tag is not buildable in a clean environment:

[...]
I am not sure that this is a priority for many folks, but I hope  
that someday it will become more important in your eyes.


As you know you don't need to build openejb-2.2 to do your CTS/TCK  
testing.  You can build 1.2-beta or 2.0-m1 as Dain or Matt did when  
they built those releases by adding this repo to your list temporarily:


  http://people.apache.org/~dblevins/stage/

But you're right, tags should be buildable.  As openejb depends on  
geronimo and geronimo depends on openejb -- it's hard.  As you and  
David J. have mentioned, it would be possible to:

 1. release geronimo modules
 2. release openejb
 3. release geromimo applications, configs, and assemblies.

But since we don't do that and I don't think anyone is willing to  
propose it, someone has to release with an imperfect tag and OpenEJB  
is always the one to fall on that sword.  It has nothing to do with  
it not being important, that's just the compromise we make until  
either 1. OpenEJB stops depending on Geronimo snapshots, 2. Geronimo  
stops depending on OpenEJB snapshots, or 3. Geronimo releases modules  
and other in serial with a wait period in the middle for the  
OpenEJB release.


You already know that too and I'm just reiterating what we've all  
gone over before.  My perspective is we need a bit of 1, 2 and 3.


In the meantime comments like I hope that someday it will become  
more important in your eyes don't sit well with me.


So, the here and now:  It's poor form to update tags, but it's also  
poor form to release stuff with snapshots, so I went with (hopefully)  
the lesser of the two evils and updated the tag.


geronimo.*:  1.2-SNAPSHOT - 1.2-beta
tools-maven-plugin:  1.1-SNAPSHOT - 1.1

Fair warning, the tag will still not build due to the missing  
geronimo dependencies.  Geronimo 1.2-beta is waiting on OpenEJB 2.2  
to be released.


As you also know, you can add this repo to your list temporarily to  
build:

  http://people.apache.org/~dain/stage/

Hope this helps,

-David

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)

For the M1 release I would have said close enough and made the final  
release from trunk.


But changing the tag is harmful by itself by setting precedence...  
something which should not be followed, yet unless people understand  
why, they will just continue along those bad practices.


And technically speaking, making a change to a branch or hacking up a  
tag should have the exact same effect on any work that anyone might  
need to redo for a release.  And really we could thump the rule book  
on the ci to tags too... which is pointless for this release.  The  
important thing is that people understand that its not appropriate to  
alter a tag in that manner.  This is a pure policy argument, as  
technically from the release perspective is identical using svn, in  
both cases, the release must be re-cut, re-approved, blah, blah,  
blah.  And in general for release tags, it is best to treat them as  
read only.


--jason


On Dec 18, 2006, at 5:53 PM, David Blevins wrote:



On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:

Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)

- includes tags and modifications


Discussion, proposal, resolution and final vote.

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html

Granted that was June, just about time to do it all over again :)

In regards to the commit to the tag, I don't have a problem with it  
as it was completely ineffectual in any technical sense.  We could  
of course thump the rule book and make Matt redo 8+ hours of work  
and have days worth of revoting followed up by a couple weeks worth  
of cumulative man hours on policy discussions... or we could just  
say close enough and focus on 2.0-M2.


-David

Re: openejb-2.2 tag is not buildable


On Dec 18, 2006, at 5:15 PM, David Blevins wrote:

On Dec 18, 2006, at 1:51 PM, Jason Dillon wrote:

I'm trying to build the OpenEJB 2.2 release so that I can continue  
working on Geronimo CTS/TCK automation... but the openejb-2.2  
release tag is not buildable in a clean environment:

[...]
I am not sure that this is a priority for many folks, but I hope  
that someday it will become more important in your eyes.


As you know you don't need to build openejb-2.2 to do your CTS/TCK  
testing.  You can build 1.2-beta or 2.0-m1 as Dain or Matt did when  
they built those releases by adding this repo to your list  
temporarily:


  http://people.apache.org/~dblevins/stage/


This requires a change to the source code, which I can not  
automate... and kinda defeats the purpose of the automated builds.


IMO relying on users to change the source in order to build a  
codeline is a serious flaw.



But you're right, tags should be buildable.  As openejb depends on  
geronimo and geronimo depends on openejb -- it's hard.  As you and  
David J. have mentioned, it would be possible to:

 1. release geronimo modules
 2. release openejb
 3. release geromimo applications, configs, and assemblies.

But since we don't do that and I don't think anyone is willing to  
propose it, someone has to release with an imperfect tag and  
OpenEJB is always the one to fall on that sword.  It has nothing to  
do with it not being important, that's just the compromise we make  
until either 1. OpenEJB stops depending on Geronimo snapshots, 2.  
Geronimo stops depending on OpenEJB snapshots, or 3. Geronimo  
releases modules and other in serial with a wait period in the  
middle for the OpenEJB release.


Okay, I understand that... though the deps on Genesis and xmlbeans-m- 
p are completely different.



You already know that too and I'm just reiterating what we've all  
gone over before.  My perspective is we need a bit of 1, 2 and 3.


Ya, would be better in this case to have G split up into components  
and assemblies, and release them separately... that is how I had to  
model it for automated builds.



In the meantime comments like I hope that someday it will become  
more important in your eyes don't sit well with me.


Sorry... though I think that we could have all done a better job at  
this if we had more longer term perspective... though I realize that  
given the circumstances that some corners needed to be cut to  
actually move forward.



So, the here and now:  It's poor form to update tags, but it's also  
poor form to release stuff with snapshots, so I went with  
(hopefully) the lesser of the two evils and updated the tag.


geronimo.*:  1.2-SNAPSHOT - 1.2-beta
tools-maven-plugin:  1.1-SNAPSHOT - 1.1

Fair warning, the tag will still not build due to the missing  
geronimo dependencies.  Geronimo 1.2-beta is waiting on OpenEJB 2.2  
to be released.


As you also know, you can add this repo to your list temporarily to  
build:

  http://people.apache.org/~dain/stage/

Hope this helps,


Thanks... though I hope we can avoid this in the future if  
possible... needing modify source to add these repos really does not  
help me when working from automated builds.  It should have been  
possible to change each branch to use the right dependencies, then  
build them in order and produce a functional system... and a  
repeatable build.   Inclusion of snapshots and split of specs to many  
branches has simply made it more difficult to make a reproducible build.


--jason

Padraig O'Dowd is out of the office.

2006-12-18 Thread Padraig O'Dowd


I will be out of the office starting  16/12/2006 and will not return until
02/01/2007.

I will respond to your message when I return.

Re: Trunk runtime error GBeanInstanceState- deserializing GBeanState

--- Davanum Srinivas [EMAIL PROTECTED] wrote:

 Anita,
 
 Anyone who builds geronimo from scratch is likely to into into
 problem. We can't really tell people they can't use the jars they
 build themselves on their boxes and have to use the published
 SNAPSHOT
 jars. 
   
  We do not tell people that they have to use the published jars. It is
clear from this error that maven is still downloading jars from a
remote repo instead of using the ones that were built locally. The only
way to make sure that the local jars/cars are used is to do an offile
build.

Thanks
Anita

So i think we need to fix it. 
Just imagine that you are trying
 to fix a bug in Geronimo kernel for shipping to your customer, but
 the
 code does not have a serial version uid and the compiled jar is hence
 unusable...not a pretty picture. I don't think we have to worry
 about compatibility especially as right now if 2 jars built from same
 svn revision by 2 different people on different JDK's/JDK versions on
 different boxes, you can't mix the jars. So there is no
 compatibility right now :(
 
 Anyway my specific problem was because of lack of the UID in
 GBeanOperation and i checked in a patch for it (487759).
 
 thanks,
 dims
 
 On 12/16/06, anita kulshreshtha [EMAIL PROTECTED] wrote:
  Dims, Joe, and Prasad
  I wish I had seen this coming.. The compatibility of GBeanInfo
 was
  broken for 4 days (Dec 10th - Dec 14), while we discussed whether
 we
  should maintain this compatibility. In a perfect world it would not
  have mattered.. But sometimes Maven does not use locally built
  SNAPSHOTs in online build mode (some of the reasons for this are
  known). Once the SNAPSHOTs published during this time, are
 overwritten,
  this problem should go way. At least that is my thinking... Please
  correct me if I am on wrong track.
 
  Thanks
  Anita
 
  --- Joe Bohn [EMAIL PROTECTED] wrote:
 
   Prasad,
  
   I'm hitting this particular problem in trunk (but I have hit
 similar
   problems in 2.0-M1).  I actually was trying to recreate the
 problem
   today in both trunk and 2.0-M1 ... after 4 builds on 2.0-M1 I
 didn't
   hit
   the problem but I hit it with the first attempt on trunk.   As I
   mentioned, the second build attempt corrected the problem.
  
   Joe
  
  
   Prasad Kashyap wrote:
I was able to build G successfully on a RedHat machine.
   
I started with a completely clean repo (rm -rf .m2/repository).
   
I did an 'svn up' of my 2.0-M1 directory. I had done a fresh
   checkout
of these files last night.
   
The entire tree built successfully with a
 -Dmaven.test.skip=true.
   
I verified that both jetty and tomcat binaries run fine.
   
I used the console to successfully deploy jsp-examples app on
 both
binaries.
   
Cheers
Prasad
   
On 12/15/06, Joe Bohn [EMAIL PROTECTED] wrote:
   
This might be the sporadic problem after all.  I just rebuilt
   again
without any changes (still rev 487523) and the problem doesn't
   exist
with the new images.
   
Here's what I did this time:
- mvn clean
- from my local repo remove o/a/g/modules, configs,
 assemblies,
   and
applications rather than removing the entire local repo.
- mvn -Dstage=bootstrap
   - still failed in the geronimo-jetty6 SecurityTest (yes, I
 know
   I
should have skipped the tests but I wanted to see if the
   failure/restart
was in any way related to the failures)
- mvn -Dstage=bootstrap -Dmaven.test.skip=true
   -Dmaven.itest.skip=true
- mvn -Dstage=assemble -Dmaven.test.skip=true
   -Dmaven.itest.skip=true
   
Joe
   
   
   
Joe Bohn wrote:
 This is happening in trunk rev 487523.   I'm not sure it is
 the
   same
 problem I reported earlier .. in fact I think it may be
   different and
 possibly related to the serialized UID change made earlier
   today.

 I was keeping careful track of what I did in case I hit the
   problem
that
 I'm mentioned in other threads with the GBeanInfo object

 Here's what I did:
 - mvn clean
 - completely remove my local repository.
 - mvn -Dstage=bootstrap
   - this failed in modules/geronimo-jetty6 test case for
   SecurityTest
 ... expecting a 500 returned instead of a 404 that was
 returned.
 - mvn -Dstage=bootstrap -Dmaven.test.skip=true
   -Dmaven.itest.skip=true
 - mvn -Dstage=assemble -Dmaven.test.skip=true
   -Dmaven.itest.skip=true

 I then extracted the zip images created and began hitting
 this
   error
 attempting to start any of the generated assemblies and
 received
   the
 following attempting to start each of the server images.

 I'm building again just in case this is like the earlier
 problem
   that
 seems to disappear on a rebuild for no known reason.


 Booting Geronimo Kernel (in Java 1.5.0_06)...
 13:29:19,163 ERROR [GBeanInstanceState] Error while
 starting;
   GBean is
 now in the FAILED

Re: Release Guidlines (was: Re: svn commit: r488326 - /geronimo/server/tags/2.0-M1/testsuite/deployment-testsuite/manifestcp/manifestcp-ejb/src/main/resources/META-INF/ejb-jar.xml)



On Dec 18, 2006, at 10:37 PM, Jason Dillon wrote:

For the M1 release I would have said close enough and made the  
final release from trunk.


But changing the tag is harmful by itself by setting precedence...  
something which should not be followed, yet unless people  
understand why, they will just continue along those bad practices.


And technically speaking, making a change to a branch or hacking up  
a tag should have the exact same effect on any work that anyone  
might need to redo for a release.  And really we could thump the  
rule book on the ci to tags too... which is pointless for this  
release.  The important thing is that people understand that its  
not appropriate to alter a tag in that manner.  This is a pure  
policy argument, as technically from the release perspective is  
identical using svn, in both cases, the release must be re-cut, re- 
approved, blah, blah, blah.  And in general for release tags, it is  
best to treat them as read only.




We're all on the same page...I weighed the change versus lost sleep  
and my marriage.  The commit won :)



--jason


On Dec 18, 2006, at 5:53 PM, David Blevins wrote:



On Dec 18, 2006, at 2:59 PM, Matt Hogstrom wrote:

Process of branching and tagging (we already have  a plethora of  
discussion...I think this needs to get on a Wiki)

- includes tags and modifications


Discussion, proposal, resolution and final vote.

http://cwiki.apache.org/GMOxPMGT/release-branching-process.html


Thanks David...this is what I was referring to and I don't think we  
need to go through it again.  I forgot it made it to the Wiki.




Granted that was June, just about time to do it all over again :)

In regards to the commit to the tag, I don't have a problem with  
it as it was completely ineffectual in any technical sense.  We  
could of course thump the rule book and make Matt redo 8+ hours of  
work and have days worth of revoting followed up by a couple weeks  
worth of cumulative man hours on policy discussions... or we could  
just say close enough and focus on 2.0-M2.


-David







Matt Hogstrom
[EMAIL PROTECTED]

Re: [VOTE] Release XBean 2.8