date:20070802


 [ 
https://issues.apache.org/jira/browse/DAYTRADER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher James Blythe closed DAYTRADER-48.
-

   Resolution: Fixed
Fix Version/s: 2.0
 Assignee: Christopher James Blythe

Completed removal of TradeJPA

 Remove TradeJPA mode (replaced by full EJB 3 mode)
 --

 Key: DAYTRADER-48
 URL: https://issues.apache.org/jira/browse/DAYTRADER-48
 Project: DayTrader
  Issue Type: Task
  Components: EJB Tier
Affects Versions: 2.0
Reporter: Christopher James Blythe
Assignee: Christopher James Blythe
Priority: Minor
 Fix For: 2.0


 The EJB 3 code that was recently committed provides a full EJB 3 
 implementation of the DayTrader workload using EJB 3 entities, sessions and 
 MDBs. This improves upon the original Trade JPA mode (from which the business 
 logic was originally ported) that used EJB 2.1 based session and MDBs. 
 Furthermore, minor modifications were made to improve data consistency and 
 performance (via eager/lazy loading of the entities).
 I see no real need for the original JPA mode to stick around and feel it 
 should be removed.
 Any objections?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms

2007-08-02 Thread Lin Sun (JIRA)

Axis2ClientConfigurationFactory not always being used in certain platforms
--

 Key: GERONIMO-3368
 URL: https://issues.apache.org/jira/browse/GERONIMO-3368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: webservices
Affects Versions: 2.0
Reporter: Lin Sun
Assignee: Lin Sun
 Fix For: 2.0


On Windows 2003  Linux, GBean TomcatWebAppContext will be started before 
Axis2ConfigGBean. Class 
org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
when the geronimo kernel starts TomcatWebAppContext, look at the following 
codes in DescriptionFactoryImpl:
private static ClientConfigurationFactory clientConfigFactory = 
ClientConfigurationFactory.newInstance();

This will make class DescriptionFactoryImpl can not load 
Axis2ClientConfigurationFactory which is registered into 
MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.

On Windows XP, GBean TomcatWebAppContext will be started after Axis2ConfigGBean 
so the client configurationcontext is working as expected.

GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's not 
mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The patch will 
set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms

2007-08-02 Thread Lin Sun (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lin Sun updated GERONIMO-3368:
--

Attachment: G-3368.patch

Patch contributed by Yun Feng Ma.  Able to get some load testing running with 
this patch.

 Axis2ClientConfigurationFactory not always being used in certain platforms
 --

 Key: GERONIMO-3368
 URL: https://issues.apache.org/jira/browse/GERONIMO-3368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0
Reporter: Lin Sun
Assignee: Lin Sun
 Fix For: 2.0

 Attachments: G-3368.patch


 On Windows 2003  Linux, GBean TomcatWebAppContext will be started before 
 Axis2ConfigGBean. Class 
 org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
 when the geronimo kernel starts TomcatWebAppContext, look at the following 
 codes in DescriptionFactoryImpl:
 private static ClientConfigurationFactory clientConfigFactory = 
 ClientConfigurationFactory.newInstance();
 This will make class DescriptionFactoryImpl can not load 
 Axis2ClientConfigurationFactory which is registered into 
 MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
 use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.
 On Windows XP, GBean TomcatWebAppContext will be started after 
 Axis2ConfigGBean so the client configurationcontext is working as expected.
 GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's 
 not mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The 
 patch will set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor reassigned GERONIMO-3368:
-

Assignee: Jarek Gawor  (was: Lin Sun)

 Axis2ClientConfigurationFactory not always being used in certain platforms
 --

 Key: GERONIMO-3368
 URL: https://issues.apache.org/jira/browse/GERONIMO-3368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0
Reporter: Lin Sun
Assignee: Jarek Gawor
 Fix For: 2.0

 Attachments: G-3368.patch


 On Windows 2003  Linux, GBean TomcatWebAppContext will be started before 
 Axis2ConfigGBean. Class 
 org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
 when the geronimo kernel starts TomcatWebAppContext, look at the following 
 codes in DescriptionFactoryImpl:
 private static ClientConfigurationFactory clientConfigFactory = 
 ClientConfigurationFactory.newInstance();
 This will make class DescriptionFactoryImpl can not load 
 Axis2ClientConfigurationFactory which is registered into 
 MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
 use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.
 On Windows XP, GBean TomcatWebAppContext will be started after 
 Axis2ConfigGBean so the client configurationcontext is working as expected.
 GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's 
 not mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The 
 patch will set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3369) MultiParentClassLoader does not check for hidden resources in recursiveFind()


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller closed GERONIMO-3369.
--

Resolution: Fixed

Fixed in branches/2.0 and trunk.

I removed some old comented out code and also added a 
isNonOverridableResource() check.


 MultiParentClassLoader does not check for hidden resources in recursiveFind() 
 --

 Key: GERONIMO-3369
 URL: https://issues.apache.org/jira/browse/GERONIMO-3369
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0


 recursiveFind isn't checking hidden resources. So, a 
 ClassLoader.getResources() call may return resources from parent ClassLoaders 
 which should not have been searched.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-3369) MultiParentClassLoader does not check for hidden resources in recursiveFind()

MultiParentClassLoader does not check for hidden resources in recursiveFind() 
--

 Key: GERONIMO-3369
 URL: https://issues.apache.org/jira/browse/GERONIMO-3369
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Affects Versions: 2.0
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0


recursiveFind isn't checking hidden resources. So, a ClassLoader.getResources() 
call may return resources from parent ClassLoaders which should not have been 
searched.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-3370) Create local build of OpenJPA in our local repo


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods reassigned GERONIMO-3370:
--

Assignee: Donald Woods

 Create local build of OpenJPA in our local repo
 ---

 Key: GERONIMO-3370
 URL: https://issues.apache.org/jira/browse/GERONIMO-3370
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.0
Reporter: Kevan Miller
Assignee: Donald Woods
 Fix For: 2.0


 For 2.0 release, we'll need to create a build of OpenJPA and put it in the 
 branches/2.0/repository. OpenJPA revision number 561970 contains the final 
 change that we need.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tomcat connectors

2007-08-02 Thread Paul McMahan

This work is complete now and available in trunk and the 2.0 branch.   
As a side effect of introducing these new connectors we needed to  
make some changes to the management apis (mainly WebManager) to allow  
the connectors to specify which attributes they support, what their  
types are (string, boolean, integer, etc), whether or not they are  
required vs. optional, etc.  All this used to be hard coded in the  
portlet but now they are defined per connector type in  
JettyManagerImpl and TomcatManagerImpl and the portlet just renders a  
form with corresponding inputs and validation.


I tried to cover as much testing as possible within our proposed  
timeframe for 2.0 but there may still be some rough edges.   In  
particular I was not able to test the APR connectors without having  
the native libraries.  You can successfully create an APR connector  
but without the libraries it won't start due to an unsatisfied link  
error (as expected).


Thanks to Jeff and David Jencks for all their help on getting this  
important feature into 2.0.


Best wishes,
Paul

On Jul 25, 2007, at 1:43 PM, Jeff Genender wrote:


Ok I added a whole bunch of new connectors in the o.a.g.t.connectors
package.

I am still working on APR - more notes to follow on this as its a  
little
squirly since the Tomcat Connector somewhat chooses this  
automatically

based on the existence of a native libraries.  For the console we may
wish to do a check on whether the native libs exist, and if so,  
present

the APR connector.  More on this in another email.

Here are the connectors we care about at the moment...

AJP13ConnectorGBean - Implements AJP
Http11ConnectorGBean - Implements blocking Http connector
Https11ConnectorGBean  - Implements blocking Https connector
Http11NIOConnectorGBean - Implements non-blocking Http connector
Https11NIOConnectorGBean - Implements non-blocking Https connector

I have not wired them into the container and other GBeans yet...I want
to clena them up and get any feedback before making the switch since
this obviously will impact the console upon wiring them in.

As a side note...I am not using any references to the WebManager or
other interfaces we used that hooked into the console.  We can re-add
those if those are deemed necessary.

Jeff

Paul McMahan wrote:
I agree NIO support would be great to have in 2.0, especially  
since its

required for comet.

Best wishes,
Paul

On Jul 23, 2007, at 2:42 PM, Jeff Genender wrote:


Hi,

I was going through some JIRAs and the Geronimo2.0 source and  
noticed it

will be difficult at best to get the NIO connector and setting
attributes on the APR connector for Tomcat due to its current
implementation.  I really think the ability to use these 2  
connectors is
very important for the 2.0 release and I would like to put these  
in.  If

there are no objections, I would like this to be a part of the 2.0
release.

Jeff

[jira] Commented: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms


[ 
https://issues.apache.org/jira/browse/GERONIMO-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517313
 ] 

Jarek Gawor commented on GERONIMO-3368:
---

I was able to replicate this problem if the web service and the service-ref 
client was deployed as two separate modules (but not if both were in one 
module). 
Fixes committed to trunk: revision 562146 and 2.0 branch: revision 562167


 Axis2ClientConfigurationFactory not always being used in certain platforms
 --

 Key: GERONIMO-3368
 URL: https://issues.apache.org/jira/browse/GERONIMO-3368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0
Reporter: Lin Sun
Assignee: Jarek Gawor
 Fix For: 2.0

 Attachments: G-3368.patch


 On Windows 2003  Linux, GBean TomcatWebAppContext will be started before 
 Axis2ConfigGBean. Class 
 org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
 when the geronimo kernel starts TomcatWebAppContext, look at the following 
 codes in DescriptionFactoryImpl:
 private static ClientConfigurationFactory clientConfigFactory = 
 ClientConfigurationFactory.newInstance();
 This will make class DescriptionFactoryImpl can not load 
 Axis2ClientConfigurationFactory which is registered into 
 MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
 use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.
 On Windows XP, GBean TomcatWebAppContext will be started after 
 Axis2ConfigGBean so the client configurationcontext is working as expected.
 GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's 
 not mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The 
 patch will set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-3368) Axis2ClientConfigurationFactory not always being used in certain platforms


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor resolved GERONIMO-3368.
---

Resolution: Fixed

 Axis2ClientConfigurationFactory not always being used in certain platforms
 --

 Key: GERONIMO-3368
 URL: https://issues.apache.org/jira/browse/GERONIMO-3368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.0
Reporter: Lin Sun
Assignee: Jarek Gawor
 Fix For: 2.0

 Attachments: G-3368.patch


 On Windows 2003  Linux, GBean TomcatWebAppContext will be started before 
 Axis2ConfigGBean. Class 
 org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl will be loaded 
 when the geronimo kernel starts TomcatWebAppContext, look at the following 
 codes in DescriptionFactoryImpl:
 private static ClientConfigurationFactory clientConfigFactory = 
 ClientConfigurationFactory.newInstance();
 This will make class DescriptionFactoryImpl can not load 
 Axis2ClientConfigurationFactory which is registered into 
 MetadataFactoryRegistry in Axis2ConfigGBean. So DescriptionFactoryImpl still 
 use the old ClientConfigurationFactory, not Axis2ClientConfigurationFactory.
 On Windows XP, GBean TomcatWebAppContext will be started after 
 Axis2ConfigGBean so the client configurationcontext is working as expected.
 GBean TomcatWebAppContext and Axis2ConfigGBean have the same priority, it's 
 not mandatory for geronimo kernel to start Axis2ConfigGBean firstly. The 
 patch will set priority of Axis2ConfigGBean as GBeanInfo.PRIORITY_CLASSLOADER.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] Release TxManager 2.0

2007-08-02 Thread Matt Hogstrom


All,


Please take a peek at the jar files for the txManagr components that  
David Jencks had busted out earlier.  A tar ball can be found at  
http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

[jira] Created: (GERONIMO-3371) Create local build of Axis2 in our local repo

Create local build of Axis2 in our local repo
-

 Key: GERONIMO-3371
 URL: https://issues.apache.org/jira/browse/GERONIMO-3371
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
Affects Versions: 2.0
Reporter: Jarek Gawor


It looks Axis2 1.3 might not be released in time for Geronimo release so we 
need to take a snapshot of the Axis2 1.3 branch and put it in our local repo.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3370) Create local build of OpenJPA in our local repo


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-3370:
---

Attachment: openjpa-1.0.0-r561970-src.zip

OpenJPA 1.0.0 Rev561970 source code used to build the jars we need.
Updated 
openjpa-kernel\src\main\java\org\apache\openjpa\conf\OpenJPAVersion.java to 
properly have version=1.0.0 and revision=561970

 Create local build of OpenJPA in our local repo
 ---

 Key: GERONIMO-3370
 URL: https://issues.apache.org/jira/browse/GERONIMO-3370
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.0
Reporter: Kevan Miller
Assignee: Donald Woods
 Fix For: 2.0

 Attachments: openjpa-1.0.0-r561970-src.zip


 For 2.0 release, we'll need to create a build of OpenJPA and put it in the 
 branches/2.0/repository. OpenJPA revision number 561970 contains the final 
 change that we need.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release specs for JACC, JSP, Servlet


+1

david jencks

On Jul 30, 2007, at 7:04 PM, Tim McConnell wrote:

Hi, Please review and vote on the release of the following Geronimo  
specs:


-- geronimo-jacc_1.1_spec-1.0
-- geronimo-jsp_2.1_spec-1.0
-- geronimo-servlet_2.5_spec-1.1

The corresponding tar files are here:

http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz

The current svn locations are here:

https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
servlet_2.5_spec-1.1


The future svn locations will be here:

https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
servlet_2.5_spec-1.1


The vote will conclude at 10:00 PM EST on Thursday, August 2nd.

--
Thanks,
Tim McConnell

Re: [VOTE] Release Genesis 1.2


+1
david jencks

On Jul 31, 2007, at 8:21 PM, Matt Hogstrom wrote:

Please review and vote on the Genesis release of 1.2.  At this  
location you will find a tar ball with the repository and related  
artifacts that will be released.


http://people.apache.org/~hogstrom/genesis-rc1

Branch with source is at https://svn.apache.org/repos/asf/geronimo/ 
genesis/branches/1.2/


[ ] +1 Release Genesis 1.2
[ ] 0 No opinion
[ ] -1  Do not release this artifact (please provide reason

Vote will complete at 2330 ET, August 3 2007.

Re: [VOTE] Release specs for JACC, JSP, Servlet

2007-08-02 Thread David Blevins


+1

David

On Jul 30, 2007, at 7:04 PM, Tim McConnell wrote:

Hi, Please review and vote on the release of the following Geronimo  
specs:


-- geronimo-jacc_1.1_spec-1.0
-- geronimo-jsp_2.1_spec-1.0
-- geronimo-servlet_2.5_spec-1.1

The corresponding tar files are here:

http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz
http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz

The current svn locations are here:

https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo- 
servlet_2.5_spec-1.1


The future svn locations will be here:

https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jacc_1.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
jsp_2.1_spec-1.0
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo- 
servlet_2.5_spec-1.1


The vote will conclude at 10:00 PM EST on Thursday, August 2nd.

--
Thanks,
Tim McConnell

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread David Blevins


+1

On Aug 2, 2007, at 9:27 AM, Matt Hogstrom wrote:


All,


Please take a peek at the jar files for the txManagr components  
that David Jencks had busted out earlier.  A tar ball can be found  
at http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

[jira] Created: (DAYTRADER-50) UserID shows up as null on Home page in EJB 3 mode

UserID shows up as null on Home page in EJB 3 mode
--

 Key: DAYTRADER-50
 URL: https://issues.apache.org/jira/browse/DAYTRADER-50
 Project: DayTrader
  Issue Type: Bug
  Components: EJB Tier
Affects Versions: 2.0
Reporter: Christopher James Blythe
Priority: Minor


The userID shows up as null on the Home page while in EJB 3 mode. Need to 
populate transient field in AccountDataBean with profile userid.

Also, using this opportunity to add a TransactionalAttribute of NOT_SUPPORTED 
as an annotation on the resetTrade method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Rick McGuire


+1

Matt Hogstrom wrote:

All,


Please take a peek at the jar files for the txManagr components that 
David Jencks had busted out earlier.  A tar ball can be found at 
http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: [VOTE] Release specs for JACC, JSP, Servlet

I'm +1 on all but...

I think the geronimo-servlet_2.5_spec-1.1-sources.jar should be
re-generated. Looks like the source files are duplicated. They are
placed in the right package name directory and also in the root
directory (without the package name).

Jarek

On 7/30/07, Tim McConnell [EMAIL PROTECTED] wrote:
 Hi, Please review and vote on the release of the following Geronimo specs:

 -- geronimo-jacc_1.1_spec-1.0
 -- geronimo-jsp_2.1_spec-1.0
 -- geronimo-servlet_2.5_spec-1.1

 The corresponding tar files are here:

 http://people.apache.org/~mcconne/geronimo-jacc_1.1_spec-1.0.tar.gz
 http://people.apache.org/~mcconne/geronimo-jsp_2.1_spec-1.0.tar.gz
 http://people.apache.org/~mcconne/geronimo-servlet_2.5_spec-1.1.tar.gz

 The current svn locations are here:

 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jacc_1.1_spec-1.0
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-jsp_2.1_spec-1.0
 https://svn.apache.org/repos/asf/geronimo/specs/branches/geronimo-servlet_2.5_spec-1.1

 The future svn locations will be here:

 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jacc_1.1_spec-1.0
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.1_spec-1.0
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1

 The vote will conclude at 10:00 PM EST on Thursday, August 2nd.

 --
 Thanks,
 Tim McConnell

[jira] Commented: (GERONIMO-1525) Error in DB Pool Portlet

2007-08-02 Thread bharteesh k (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517330
 ] 

bharteesh k commented on GERONIMO-1525:
---

Prasad,

I am still having some problem while adding a new database pool in the
Geronimo server (Websphere Community Edition 1.1).
I am trying to setup SQL Server database. All settings are properly
recognized by the
server but when I tried to Test Connection, it takes me back to the main
screen where we start
adding a new database pool. Skip Test and Deploy and Skip Test and Show
plan options
also gives me the same error as shown below:

14:06:39,207 ERROR [[DBWizard]] Servlet.service() for servlet DBWizard threw
exception
java.lang.NullPointerException
at
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(
DatabasePoolPortlet.java:877)
at
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction
(DatabasePoolPortlet.java:342)
at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java
:229)
at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.ApplicationDispatcher.invoke(
ApplicationDispatcher.java:672)
at org.apache.catalina.core.ApplicationDispatcher.doInclude(
ApplicationDispatcher.java:574)
at org.apache.catalina.core.ApplicationDispatcher.include(
ApplicationDispatcher.java:499)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(
PortletInvokerImpl.java:120)
at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(
PortletInvokerImpl.java:68)
at org.apache.pluto.PortletContainerImpl.processPortletAction(
PortletContainerImpl.java:164)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction
(PortletContainerWrapperImpl.java:82)
at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:178)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
DefaultSubjectValve.java:56)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:524)
at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(
GeronimoStandardContext.java:345)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
GeronimoBeforeAfterValve.java:31)
at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:105)
at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:107)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java
:541)
at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection
(Http11BaseProtocol.java:667)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(
PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(
LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(
ThreadPool.java:869)
at java.lang.Thread.run(Unknown Source)
14:06:39,207 ERROR [Servlet] Exception caught:
java.lang.NullPointerException
at
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(
DatabasePoolPortlet.java:877)
at
org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction
(DatabasePoolPortlet.java:342)
at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java
:229)
at org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:615)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at

Re: [VOTE] Release TxManager 2.0


+1
david jencks

On Aug 2, 2007, at 9:27 AM, Matt Hogstrom wrote:


All,


Please take a peek at the jar files for the txManagr components  
that David Jencks had busted out earlier.  A tar ball can be found  
at http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: [VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1

+1

Jarek

On 8/1/07, Prasad Kashyap [EMAIL PROTECTED] wrote:
 Hi, Please review and vote on the release of the following Geronimo specs:

 -- geronimo-schema-j2ee_1.4-1.2
 -- geronimo-schema-jee_5-1.1

 The corresponding tar files are here:
 http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
 http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz

 The current svn locations (restricted access) are here:
 https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/branches/1.2/
 https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/branches/1.1/

 The future svn locations (restricted access) will be here:
 https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2
 https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/tags/geronimo-schema-jee_5-1.1

 The vote will conclude at 10:00 PM EST on Saturday, August 4nd.

 NOTE: These schemas were built with the help of a
 org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is
 currently up for vote. The jar for this artifact is located at
 http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar
 So the schema pom.xml in svn branches have not been updated with this
 version of the artifact yet, pending it's final vote and release.

 Cheers
 Prasad

Re: [VOTE] Release TxManager 2.0

+1

Jarek

On 8/2/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,


 Please take a peek at the jar files for the txManagr components that
 David Jencks had busted out earlier.  A tar ball can be found at
 http://people.apache.org/~hogstrom/txmanager-2.0-rc1/

 [ ] +1 Release these binaries
 [ ] 0  No opinion
 [ ] -1  Do not release these binaries (please provide reason.

 Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: [VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1

+1 although I think there are some extraneous -src.jar files that  
could profitably be excluded from upload.


thanks
david jencks

On Aug 1, 2007, at 7:16 PM, Prasad Kashyap wrote:

Hi, Please review and vote on the release of the following Geronimo  
specs:


-- geronimo-schema-j2ee_1.4-1.2
-- geronimo-schema-jee_5-1.1

The corresponding tar files are here:
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz

The current svn locations (restricted access) are here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-j2ee_1.4/branches/1.2/
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-jee_5/branches/1.1/


The future svn locations (restricted access) will be here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo- 
schema-jee_5/tags/geronimo-schema-jee_5-1.1


The vote will conclude at 10:00 PM EST on Saturday, August 4nd.

NOTE: These schemas were built with the help of a
org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is
currently up for vote. The jar for this artifact is located at
http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar
So the schema pom.xml in svn branches have not been updated with this
version of the artifact yet, pending it's final vote and release.

Cheers
Prasad

Re: [VOTE] Release TxManager 2.0


+1


Matt Hogstrom wrote:

All,


Please take a peek at the jar files for the txManagr components that 
David Jencks had busted out earlier.  A tar ball can be found at 
http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.




smime.p7s
Description: S/MIME Cryptographic Signature

[jira] Closed: (GERONIMO-3370) Create local build of OpenJPA in our local repo


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-3370.
--

Resolution: Fixed

Committed revision 562207 in branches/2.0
Left trunk (2.1) at 1.0.0-SNAPSHOT

 Create local build of OpenJPA in our local repo
 ---

 Key: GERONIMO-3370
 URL: https://issues.apache.org/jira/browse/GERONIMO-3370
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.0
Reporter: Kevan Miller
Assignee: Donald Woods
 Fix For: 2.0

 Attachments: openjpa-1.0.0-r561970-src.zip


 For 2.0 release, we'll need to create a build of OpenJPA and put it in the 
 branches/2.0/repository. OpenJPA revision number 561970 contains the final 
 change that we need.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release Genesis 1.2

2007-08-02 Thread Matt Hogstrom


Oops ... here is my +1


Vote will complete at 2330 ET, August 3 2007.

Re: [VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1


+1


Prasad Kashyap wrote:

Hi, Please review and vote on the release of the following Geronimo specs:

-- geronimo-schema-j2ee_1.4-1.2
-- geronimo-schema-jee_5-1.1

The corresponding tar files are here:
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz

The current svn locations (restricted access) are here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/branches/1.2/
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/branches/1.1/

The future svn locations (restricted access) will be here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/tags/geronimo-schema-jee_5-1.1

The vote will conclude at 10:00 PM EST on Saturday, August 4nd.

NOTE: These schemas were built with the help of a
org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is
currently up for vote. The jar for this artifact is located at
http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar
So the schema pom.xml in svn branches have not been updated with this
version of the artifact yet, pending it's final vote and release.

Cheers
Prasad




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Genesis 1.2


+1


Matt Hogstrom wrote:
Please review and vote on the Genesis release of 1.2.  At this location 
you will find a tar ball with the repository and related artifacts that 
will be released.


http://people.apache.org/~hogstrom/genesis-rc1

Branch with source is at 
https://svn.apache.org/repos/asf/geronimo/genesis/branches/1.2/


[ ] +1 Release Genesis 1.2
[ ] 0 No opinion
[ ] -1  Do not release this artifact (please provide reason

Vote will complete at 2330 ET, August 3 2007. 





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Genesis 1.2

2007-08-02 Thread Rick McGuire


+1

Matt Hogstrom wrote:
Please review and vote on the Genesis release of 1.2.  At this 
location you will find a tar ball with the repository and related 
artifacts that will be released.


http://people.apache.org/~hogstrom/genesis-rc1

Branch with source is at 
https://svn.apache.org/repos/asf/geronimo/genesis/branches/1.2/


[ ] +1 Release Genesis 1.2
[ ] 0 No opinion
[ ] -1  Do not release this artifact (please provide reason

Vote will complete at 2330 ET, August 3 2007.

Re: [VOTE] Release Genesis 1.2

+1 but scm entry in genesis-1.2.pom points to trunk.

Jarek

On 7/31/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
 Please review and vote on the Genesis release of 1.2.  At this
 location you will find a tar ball with the repository and related
 artifacts that will be released.

 http://people.apache.org/~hogstrom/genesis-rc1

 Branch with source is at https://svn.apache.org/repos/asf/geronimo/
 genesis/branches/1.2/

 [ ] +1 Release Genesis 1.2
 [ ] 0 No opinion
 [ ] -1  Do not release this artifact (please provide reason

 Vote will complete at 2330 ET, August 3 2007.

[jira] Updated: (GERONIMO-3363) ArrayList thread safe problem in OpenJPA


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-3363:
---

  Priority: Major  (was: Blocker)
Patch Info: [Patch Available]

 ArrayList thread safe problem in OpenJPA
 

 Key: GERONIMO-3363
 URL: https://issues.apache.org/jira/browse/GERONIMO-3363
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: persistence
Affects Versions: 2.0-M7
Reporter: YunFeng Ma
 Fix For: 2.0.x


 When running stress testing using DayTrader with JPA mode, got a lot of 
 ArrayList thread safe problem.
 The thread safe problem happened in  
 org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction, 
 but this method has the following comments:
 // we don't need to synchronize on brokers or guard against 
 multiple
 // threads using the same trans since one JTA transaction can 
 never
 // be active on multiple concurrent threads.
 Collection brokers = (Collection) _transactional.get(trans);
 if (brokers == null) {
 brokers = new ArrayList(2);
 _transactional.put(trans, brokers);
 trans.registerSynchronization(new 
 RemoveTransactionSync(trans));
 }
 brokers.add(broker);
 Does this mean that it's Geronimo which causes the thread safe problem?
 The exception stack:
 java.rmi.RemoteException: The bean encountered a non-application exception.; 
 nested exception is:
 javax.ejb.EJBException: TradeBean.getClosedOrders - error
 at 
 org.apache.openejb.core.transaction.TransactionPolicy.throwExceptionToServer(TransactionPolicy.java:211)
 at 
 org.apache.openejb.core.transaction.TxRequired.handleSystemException(TxRequired.java:106)
 at 
 org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:210)
 at 
 org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165)
 at 
 org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:211)
 at 
 org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:65)
 at 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:232)
 at 
 org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
 at $Proxy109.getClosedOrders(Unknown Source)
 at 
 org.apache.geronimo.samples.daytrader.TradeAction.getClosedOrders(TradeAction.java:276)
 at 
 org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:76)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at 
 org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
 at 
 org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:351)
 at 
 org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
 at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:801)
 Caused by: javax.ejb.EJBException: TradeBean.getClosedOrders - error
 at 
 org.apache.geronimo.samples.daytrader.TradeJPA.getClosedOrders(TradeJPA.java:491)
 at sun.reflect.GeneratedMethodAccessor324.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:615)
 at 
 org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext
 .java:146)

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Jason Dillon


+1

--jason


On Aug 2, 2007, at 9:27 AM, Matt Hogstrom wrote:


All,


Please take a peek at the jar files for the txManagr components  
that David Jencks had busted out earlier.  A tar ball can be found  
at http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

Split off more chunks from server...

2007-08-02 Thread Jason Dillon

server/trunk is getting massive... and most folks who work on bits  
don't even care about half of that stuff... or really don't need to  
care about it.


I think we should really start to think seriously about splitting up  
server/trunk into smaller *separate* projects like the txmanager  
bits.  Maybe even each separate bit of functionality, like amq should  
bit split up like that too.  But to do that we need to get the core  
split up.  I certainly don't want to get into each module having its  
own trunk, but I'm really starting to think that we need to split  
this puppy up a lot more so that its easier to develop on the platform.


--jason

Re: [VOTE] Release Genesis 1.2

2007-08-02 Thread Paul McMahan


+1

On Jul 31, 2007, at 11:21 PM, Matt Hogstrom wrote:

Please review and vote on the Genesis release of 1.2.  At this  
location you will find a tar ball with the repository and related  
artifacts that will be released.


http://people.apache.org/~hogstrom/genesis-rc1

Branch with source is at https://svn.apache.org/repos/asf/geronimo/ 
genesis/branches/1.2/


[ ] +1 Release Genesis 1.2
[ ] 0 No opinion
[ ] -1  Do not release this artifact (please provide reason

Vote will complete at 2330 ET, August 3 2007.

[jira] Commented: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment

2007-08-02 Thread Paul McMahan (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517367
 ] 

Paul McMahan commented on GERONIMO-3342:


applied geronimo-3342fix.patch in rev 562246.   thanks for the patch Erik.

 Provide a way to launch J2G components from within Eclipse IDE environment
 --

 Key: GERONIMO-3342
 URL: https://issues.apache.org/jira/browse/GERONIMO-3342
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: J2G
 Environment: All
Reporter: Erik B. Craig
Assignee: Paul McMahan
 Attachments: geronimo-3342.patch, geronimo-3342fix.patch, 
 geronimo-3342update.patch, geronimo-3342update2.patch


 In order to be more user friendly, j2g should provide a method to launch the 
 components from within the Eclipse IDE environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3342) Provide a way to launch J2G components from within Eclipse IDE environment

2007-08-02 Thread Erik B. Craig (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik B. Craig updated GERONIMO-3342:


Attachment: geronimo-3342fix.patch

This is the *last one*, I promise.
Fixed an accidental double check for eclipse_home in the jsrc2glauncher

 Provide a way to launch J2G components from within Eclipse IDE environment
 --

 Key: GERONIMO-3342
 URL: https://issues.apache.org/jira/browse/GERONIMO-3342
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: J2G
 Environment: All
Reporter: Erik B. Craig
Assignee: Paul McMahan
 Attachments: geronimo-3342.patch, geronimo-3342fix.patch, 
 geronimo-3342update.patch, geronimo-3342update2.patch


 In order to be more user friendly, j2g should provide a method to launch the 
 components from within the Eclipse IDE environment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Paul McMahan


+1

On Aug 2, 2007, at 12:27 PM, Matt Hogstrom wrote:


All,


Please take a peek at the jar files for the txManagr components  
that David Jencks had busted out earlier.  A tar ball can be found  
at http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

[jira] Closed: (DAYTRADER-49) Add EJB 3 based Session-to-Direct mode


 [ 
https://issues.apache.org/jira/browse/DAYTRADER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher James Blythe closed DAYTRADER-49.
-

   Resolution: Fixed
Fix Version/s: 2.0
 Assignee: Christopher James Blythe

Completed

 Add EJB 3 based Session-to-Direct mode
 --

 Key: DAYTRADER-49
 URL: https://issues.apache.org/jira/browse/DAYTRADER-49
 Project: DayTrader
  Issue Type: New Feature
  Components: EJB Tier
Affects Versions: 2.0
Reporter: Christopher James Blythe
Assignee: Christopher James Blythe
 Fix For: 2.0


 This JIRA was opened to address the need for an EJB 3 based Stateless Session 
 Bean to Direct JDBC mode (similar to what was added to the EJB 2.1 
 implementation in DAYTRADER-15).
 The code changes are relatively straight forward and simply require a new 
 session bean which calls the service methods via TradeDirect.
 As previously mentioned in DAYTRADER-15. This is known to be a common method 
 for managing transactions commits/rollbacks for EJB 2.1 applications. I 
 imagine this will not change for EJB 3.0.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DAYTRADER-50) UserID shows up as null on Home page in EJB 3 mode


 [ 
https://issues.apache.org/jira/browse/DAYTRADER-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher James Blythe closed DAYTRADER-50.
-

   Resolution: Fixed
Fix Version/s: 2.0
 Assignee: Christopher James Blythe

Completed

 UserID shows up as null on Home page in EJB 3 mode
 --

 Key: DAYTRADER-50
 URL: https://issues.apache.org/jira/browse/DAYTRADER-50
 Project: DayTrader
  Issue Type: Bug
  Components: EJB Tier
Affects Versions: 2.0
Reporter: Christopher James Blythe
Assignee: Christopher James Blythe
Priority: Minor
 Fix For: 2.0


 The userID shows up as null on the Home page while in EJB 3 mode. Need to 
 populate transient field in AccountDataBean with profile userid.
 Also, using this opportunity to add a TransactionalAttribute of NOT_SUPPORTED 
 as an annotation on the resetTrade method.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3362) Enable Tomcat context level cluster


[ 
https://issues.apache.org/jira/browse/GERONIMO-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517376
 ] 

Donald Woods commented on GERONIMO-3362:


YunFeng used 2 Linux machines and the Servlet examples as described in 
http://cwiki.apache.org/confluence/display/GMOxSAMPLES/Apache+Geronimo+v1.1+Samples
to verify that the Context and Host Level sample write-ups still worked.

 Enable Tomcat context level cluster
 ---

 Key: GERONIMO-3362
 URL: https://issues.apache.org/jira/browse/GERONIMO-3362
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Clustering
Affects Versions: 2.0, 2.1
Reporter: YunFeng Ma
Assignee: Donald Woods
 Fix For: 2.0, 2.1

 Attachments: GERONIMO-3362.patch


 Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only 
 support tomcat host level cluster. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Joe Bohn


+1

Joe


Matt Hogstrom wrote:

All,


Please take a peek at the jar files for the txManagr components that 
David Jencks had busted out earlier.  A tar ball can be found at 
http://people.apache.org/~hogstrom/txmanager-2.0-rc1/


[ ] +1 Release these binaries
[ ] 0  No opinion
[ ] -1  Do not release these binaries (please provide reason.

Vote will conclude on Sunday August 5th at  1300 Eastern.

[jira] Closed: (GERONIMO-3362) Enable Tomcat context level cluster


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods closed GERONIMO-3362.
--

Resolution: Fixed

Committed revision 562257 in trunk (2.1)
Committed revision 562258 in branches/2.0

 Enable Tomcat context level cluster
 ---

 Key: GERONIMO-3362
 URL: https://issues.apache.org/jira/browse/GERONIMO-3362
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Clustering
Affects Versions: 2.0, 2.1
Reporter: YunFeng Ma
Assignee: Donald Woods
 Fix For: 2.0, 2.1

 Attachments: GERONIMO-3362.patch


 Geronimo v1.x supports tomcat context level cluster, but Geronimo v2.0.x only 
 support tomcat host level cluster. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Update README file

2007-08-02 Thread Hernan Cunico


I just updated README.txt on both trunk and branches/2.0

I also put a copy on the wiki for review 
http://cwiki.apache.org/GMOxDOC20/readmetxt.html

Based on the Proposed Branch and Release Schedule for Geronimo 2.0 I used 
August 7 for the released date.

Cheers!
Hernan

Kevan Miller wrote:

I think our README.txt file could stand a bit of updating...

Things like:

Apache Geronimo milestone build M4  (August 10, 2005)

I'd also like to see usage instructions for shell scripts (e.g. 
geronimo.sh/geronimo.bat, etc) rather than/or in addition to explicit 
java commands...


If someone wants to take a crack at this, that would be great. 
Otherwise, I'll work on it after I finish license/notice stuff.


--kevan

Re: [VOTE] Release geronimo-schema-jee_5-1.1 and geronimo-schema-jee_5-1.1

2007-08-02 Thread Joe Bohn


+1

Joe


Prasad Kashyap wrote:

Hi, Please review and vote on the release of the following Geronimo specs:

-- geronimo-schema-j2ee_1.4-1.2
-- geronimo-schema-jee_5-1.1

The corresponding tar files are here:
http://people.apache.org/~prasad/geronimo-schema-j2ee_1.4-1.2.tar.gz
http://people.apache.org/~prasad/geronimo-schema-jee_5-1.1.tar.gz

The current svn locations (restricted access) are here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/branches/1.2/
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/branches/1.1/

The future svn locations (restricted access) will be here:
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-j2ee_1.4/tags/geronimo-schema-j2ee_1.4-1.2
https://svn.apache.org/repos/tck/geronimo-tck/schema/geronimo-schema-jee_5/tags/geronimo-schema-jee_5-1.1

The vote will conclude at 10:00 PM EST on Saturday, August 4nd.

NOTE: These schemas were built with the help of a
org.codehaus.mojo/xmlbeans-maven-plugin/2.3.1 . This artifact is
currently up for vote. The jar for this artifact is located at
http://people.apache.org/~djencks/xmlbeans-maven-plugin-2.3.1.jar
So the schema pom.xml in svn branches have not been updated with this
version of the artifact yet, pending it's final vote and release.

Cheers
Prasad

[jira] Closed: (GERONIMO-3371) Create local build of Axis2 in our local repo


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jarek Gawor closed GERONIMO-3371.
-

   Resolution: Fixed
Fix Version/s: 2.0

Checked in Axis2 1.3 revision 562247 to the local repo.


 Create local build of Axis2 in our local repo
 -

 Key: GERONIMO-3371
 URL: https://issues.apache.org/jira/browse/GERONIMO-3371
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
Affects Versions: 2.0
Reporter: Jarek Gawor
 Fix For: 2.0


 It looks Axis2 1.3 might not be released in time for Geronimo release so we 
 need to take a snapshot of the Axis2 1.3 branch and put it in our local repo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Prasad Kashyap

+1

Cheers
Prasad

On 8/2/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
 All,


 Please take a peek at the jar files for the txManagr components that
 David Jencks had busted out earlier.  A tar ball can be found at
 http://people.apache.org/~hogstrom/txmanager-2.0-rc1/

 [ ] +1 Release these binaries
 [ ] 0  No opinion
 [ ] -1  Do not release these binaries (please provide reason.

 Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: [VOTE] Release Genesis 1.2

2007-08-02 Thread Prasad Kashyap

+1

Cheers
Prasad

On 7/31/07, Matt Hogstrom [EMAIL PROTECTED] wrote:
 Please review and vote on the Genesis release of 1.2.  At this
 location you will find a tar ball with the repository and related
 artifacts that will be released.

 http://people.apache.org/~hogstrom/genesis-rc1

 Branch with source is at https://svn.apache.org/repos/asf/geronimo/
 genesis/branches/1.2/

 [ ] +1 Release Genesis 1.2
 [ ] 0 No opinion
 [ ] -1  Do not release this artifact (please provide reason

 Vote will complete at 2330 ET, August 3 2007.

[jira] Commented: (GERONIMO-3371) Create local build of Axis2 in our local repo


[ 
https://issues.apache.org/jira/browse/GERONIMO-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517387
 ] 

Jarek Gawor commented on GERONIMO-3371:
---

To clarify, the Axis2 1.3 version revision 562247 was checked into branches/2.0 
only.


 Create local build of Axis2 in our local repo
 -

 Key: GERONIMO-3371
 URL: https://issues.apache.org/jira/browse/GERONIMO-3371
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
Affects Versions: 2.0
Reporter: Jarek Gawor
 Fix For: 2.0


 It looks Axis2 1.3 might not be released in time for Geronimo release so we 
 need to take a snapshot of the Axis2 1.3 branch and put it in our local repo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3206) Create and include a new patched version of Tomcat


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller closed GERONIMO-3206.
--

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

 Create and include a new patched version of Tomcat
 --

 Key: GERONIMO-3206
 URL: https://issues.apache.org/jira/browse/GERONIMO-3206
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Tomcat
Affects Versions: 2.0-M6
Reporter: Kevan Miller
Assignee: Kevan Miller
 Fix For: 2.0-M6


 We need a new version of Tomcat

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-3360) corba-marshall and corba-mytime tests failing

2007-08-02 Thread Tim McConnell (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim McConnell updated GERONIMO-3360:



Hi Rick, you had previously asked for the server-side error log for the 
marshalling problem. Here it is:

18:03:54,109 INFO  [MappedServerTransactionPolicyConfig] No tx mapping for 
operation: marshalLong__org_omg_boxedRMI_long_seq1_long
Aug 2, 2007 6:03:54 PM org.apache.yoko.orb.OB.Logger_impl warning
WARNING: Servant method raised a non-CORBA exception
Client receives this exception as CORBA::UNKNOWN
operation name: marshalLong__org_omg_boxedRMI_long_seq1_long
id: iiop
local address: 127.0.0.1:6882
remote address: 127.0.0.1:3366
java.lang.NullPointerException
at 
org.apache.geronimo.corba.StandardServant._invoke(StandardServant.java:161)
at 
org.apache.yoko.orb.OBPortableServer.ServantDispatcher.dispatch(ServantDispatcher.java:187)
at 
org.apache.yoko.orb.OBPortableServer.POA_impl._OB_dispatch(POA_impl.java:1607)
at 
org.apache.yoko.orb.OB.DispatchRequest_impl.invoke(DispatchRequest_impl.java:56)
at 
org.apache.yoko.orb.OB.DispatchSameThread_impl.dispatch(DispatchStrategyFactory_impl.java:53)
at org.apache.yoko.orb.OB.Upcall.invoke(Upcall.java:360)
at 
org.apache.yoko.orb.OB.GIOPConnectionThreaded.execReceive(GIOPConnectionThreaded.java:500)
at 
org.apache.yoko.orb.OB.GIOPConnectionThreaded$ReceiverThread.run(GIOPConnectionThreaded.java:63)



 corba-marshall and corba-mytime tests failing
 -

 Key: GERONIMO-3360
 URL: https://issues.apache.org/jira/browse/GERONIMO-3360
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: testsuite
Affects Versions: 2.0, 2.0.x, 2.1
Reporter: Prasad Kashyap
Assignee: Rick McGuire
 Fix For: 2.0.x


 exception in corba-marshall :
 {code}
 [INFO] [INFO] long passed to EJB: 1218738708599296309
 [INFO] [WARNING] java.lang.Exception: long array test RemoteException: 
 [3675022138608874094, -4905270342012320510] java.rmi.RemoteException: null; 
 nested exception is: 
 [INFO] [WARNING]  org.omg.CORBA.UNKNOWN:  vmcid: 0x0 minor code: 0x0  
 completed: No
 [INFO] [WARNING]  at 
 org.apache.geronimo.testsuite.corba.marshal.JavaPrimitives.marshal(JavaPrimitives.java:415)
 [INFO] [WARNING]  at 
 org.apache.geronimo.testsuite.corba.marshal.MarshalEJBClient.main(MarshalEJBClient.java:43)
 [INFO] [WARNING]  at java.lang.reflect.Method.invoke(Method.java:585)
 [INFO] [WARNING]  at 
 org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:185)
 {code}
 Exception in corba-mytime:
 {code}
 [WARNING] Deployer operation failed: start of 
 org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
 [WARNING] org.apache.geronimo.kernel.config.LifecycleException: start of 
 org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car failed
 [WARNING] Caused by: 
 org.apache.geronimo.kernel.config.InvalidConfigException: Unknown start 
 exception
 [WARNING] at 
 org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:514)
 [WARNING] at 
 org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
 [WARNING] at 
 org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:530)
 [WARNING] ... 35 more
 [WARNING] Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: 
 Configuration org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car 
 failed to start due to the following reasons:
 [WARNING]   The service 
 EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,StatelessSessionBean=MyTime,j2eeType=TSSLink,name=IdentityTokenNoSecurity
  did not start because 
 org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car?EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
  did not start.
 [WARNING]   The service 
 EJBModule=corba-mytime-ejb-2.0-SNAPSHOT.jar,J2EEApplication=org.apache.geronimo.testsuite/corba-mytime-ear/2.0-SNAPSHOT/car,j2eeType=CORBATSS,name=IdentityTokenNoSecurity
  did not start because IDL:omg.org/PortableServer/POA/AdapterAlreadyExists:1.0
 [WARNING] 
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-3310) Geronimo is not finding message-destination elements in ejb-jar.xmls

2007-08-02 Thread David Jencks (JIRA)


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Jencks closed GERONIMO-3310.
--

Resolution: Invalid

The code actually does look for the message-destination elements, but we only 
pay attention to them if there is an additional geronimo mapping in a geronimo 
message-destinationType element from the message-destination-name in the spec 
jar to the message-destination-name in the geronimo plan (inside an 
admin-object-instance).  If the names match, we don't need the additional 
mapping so ignore it.

 Geronimo is not finding message-destination elements in ejb-jar.xmls
 

 Key: GERONIMO-3310
 URL: https://issues.apache.org/jira/browse/GERONIMO-3310
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.0-M6
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.0.x


 daytrader has a couple message-destination elements in the ejb-jar.xml.  They 
 aren't getting picked up by the time AdminObjectRefBuilder needs to see them.
 I think in g. 1.x we had some hackery whereby the openejb deployer was 
 calling naming builders initContext with the entire ejb-jar.xml, and then 
 buildNaming for each ejb.  Not sure what we want to do yet.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Changes to server started messages

2007-08-02 Thread Jeff Genender

Yup...

The old messages made no sense at all...because Web application !=
connector and therefore its not fair to determine that the web
applications actually listen on http.  In long discussions with David
Jencks, we agreed the slapping of http in from of the URL was purely a
hack and was not correct for complex cases...i.e. the applications you
listed also are running on https *and* ajp.  In otherwords, the web
application is independent of the scheme (http) and it shouldn't know
its own scheme.

It *is* correct for the web application to know it's identified by the
context, and thats why you see them listed.

I hope this made sense.

Jeff


Kevan Miller wrote:
 I noticed that the server started messages have changed. The started Web
 Applications are now of the following form:
 
   Web Applications:
 /
 /console
 /console-standard
 /dojo
 /remote-deploy
 
 Geronimo Application Server started
 
 Where they used to be:
 
   Web Applications:
 http://coltrane:8080/
 http://coltrane:8080/console
 http://coltrane:8080/console-standard
 http://coltrane:8080/dojo
 http://coltrane:8080/remote-deploy
 
 Geronimo Application Server started
 
 I'm assuming that this is associated with the recent Connector
 changes... I preferred the old messages, but I doubt I'll lose very much
 sleep... Apologies if I missed discussion about this. Even more
 apologies if the network config on my machine has gone bonkers... ;-)
 
 --kevan

Changes to server started messages

2007-08-02 Thread Kevan Miller

I noticed that the server started messages have changed. The started  
Web Applications are now of the following form:


  Web Applications:
/
/console
/console-standard
/dojo
/remote-deploy

Geronimo Application Server started

Where they used to be:

  Web Applications:
http://coltrane:8080/
http://coltrane:8080/console
http://coltrane:8080/console-standard
http://coltrane:8080/dojo
http://coltrane:8080/remote-deploy

Geronimo Application Server started

I'm assuming that this is associated with the recent Connector  
changes... I preferred the old messages, but I doubt I'll lose very  
much sleep... Apologies if I missed discussion about this. Even more  
apologies if the network config on my machine has gone bonkers... ;-)


--kevan

[jira] Closed: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller closed GERONIMO-3348.
--

   Resolution: Duplicate
Fix Version/s: 2.0.x

This is a duplicate of GERONIMO-3265 -- 
https://issues.apache.org/jira/browse/GERONIMO-3265

Until we've removed Spring from parent ClassLoaders (this problem only occurs 
in configurations using CXF as the Web Services implementation), use a Geronimo 
deployment plan. E.g:

?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; 
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; 
xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.1;
  dep:environment
dep:moduleId
  dep:groupIdorg.mygroup/dep:groupId
  dep:artifactIdMyApp/dep:artifactId
  dep:version1.1/dep:version
  dep:typecar/dep:type
/dep:moduleId
!-- 
 Don't load spring classes or spring resources from parent ClassLoaders.
  --
hidden-classes
  filterorg.springframework./filter
  filterMETA-INF/spring/filter
/hidden-classes
  /dep:environment
/web-app


 java.lang.NoSuchMethodError in 
 org.springframework.context.i18n.LocaleContextHolder
 ---

 Key: GERONIMO-3348
 URL: https://issues.apache.org/jira/browse/GERONIMO-3348
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0-M6
 Environment: 2.6.18-gentoo-r2 #1 Sat Nov 11 03:36:37 EST 2006 i686 
 Pentium III (Katmai) GenuineIntel GNU/Linux
 JDK-1.5.0.12
Reporter: Aleksandr Tarutin
Assignee: Kevan Miller
 Fix For: 2.0.x


 When deploying and running [Proximity|http://proximity.abstracthorizon.org/] 
 it works without any problem in geronimo-1.1.1. But when the same application 
 is deployed to 2.0-M6 following exception is thrown:
 {noformat}
 15:57:53,267 INFO  [DirectoryHotDeployer] Deploying proximity
 15:57:56,690 WARN  [JettyModuleBuilder] Web application . does not contain a 
 WEB-INF/geronimo-web.xml deployment plan.  This may or may not be a problem, 
 depending on whether you have things like resource references that need to be 
 resolved.  You can also give the deployer a separate deployment plan file on 
 the command line.
 15:58:04,709 WARN  [JspModuleBuilderExtension] Invalid transformed taglib
 org.apache.xmlbeans.XmlException: Invalid deployment descriptor: errors:
 jar:file:/opt/geronimo-jetty6-jee5-2.0-M6/repository/default/proximity/1185307073730/proximity-1185307073730.war/WEB-INF/lib/bsf-2.3.0.jar!/META-INF/taglib.tld:15:3:
  error: cvc-datatype-valid.1.1: string value 'BSF JSP Support' does not match 
 pattern for tld-canonical-nameType in namespace 
 http://java.sun.com/xml/ns/javaee
 Descriptor:
 !--a tab library descriptor--
 taglib xsi:schemaLocation=http://java.sun.com/xml/ns/javaee  
 http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd; version=2.1 
 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; 
 xmlns=http://java.sun.com/xml/ns/javaee;
   !--after this the default space is
 http://java.sun.com/j2ee/dtds/jsptaglibrary_1_2.dtd--
   tlib-version2.0/tlib-version
   short-nameBSF JSP Support/short-name
   urihttp://jakarta.apache.org/taglibs//uri
   tag
 namescriptlet/name
 tag-classorg.apache.taglibs.bsf.scriptlet/tag-class
 body-contenttagdependent/body-content
 attribute
   namelanguage/name
   requiredtrue/required
 /attribute
   /tag
   tag
 nameexpression/name
 tag-classorg.apache.taglibs.bsf.expression/tag-class
 body-contenttagdependent/body-content
 attribute
   namelanguage/name
   requiredtrue/required
 /attribute
   /tag
 /taglib
   at 
 org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil.validateDD(XmlBeansUtil.java:218)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.convertToTaglibSchema(JspModuleBuilderExtension.java:675)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.parseTldFile(JspModuleBuilderExtension.java:433)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.getListenerClasses(JspModuleBuilderExtension.java:420)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.createJspClassFinder(JspModuleBuilderExtension.java:180)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension.addGBeans(JspModuleBuilderExtension.java:149)
   at 
 org.apache.geronimo.jasper.deployment.JspModuleBuilderExtension$$FastClassByCGLIB$$1f60ab3b.invoke(generated)
   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at 
 org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
   at

[jira] Closed: (GERONIMO-3350) Console needs to administer all the web connectors. Needs WebManager change.

2007-08-02 Thread David Jencks (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMO-3350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

David Jencks closed GERONIMO-3350.
--

Resolution: Fixed
Fix Version/s: 2.1

This took a lot of commits between Jeff Genender, Paul McMahan, and myself..
hopefully they all show up in the All view.

Console needs to administer all the web connectors. Needs WebManager change.
-

Key: GERONIMO-3350
URL: https://issues.apache.org/jira/browse/GERONIMO-3350
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console, Jetty, management, Tomcat
Affects Versions: 2.0-M6
Reporter: David Jencks
Assignee: David Jencks
Fix For: 2.0, 2.1

After a discussion on IRC of the problems with the console administering web
connectors jgenender, pmcmahan, and I (djencks) came up with this plan:
Modify the WebManager interface to have 3 connector related methods:
ListconnectorType getConnectorTypes();// returns a list of what kinds of
connectors are available
ListconfigItem getConnectorAttributes(connectorType);/ returns a list of
what you can configure on that connector, including display name, attribute
name, description, and value.
GBeanData configureConnector(connectorType, ListconfigItem);/ configures a
GBeanData with all the stuff needed.
Then the tomcat and jetty WebManager can tell the console what connectors are
available, how to configure them, and give it the configured gbean.
I don't know what the WebConnector class is for... returning GBeanData in
the last step may not be the best.
This might not be the best long term solution but seems like it will work and
be doable by 2.0.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Created: (GERONIMO-3348) java.lang.NoSuchMethodError in org.springframework.context.i18n.LocaleContextHolder

2007-08-02 Thread Kevan Miller



On Jul 31, 2007, at 2:53 PM, Jarek Gawor wrote:


On 7/31/07, Kevan Miller [EMAIL PROTECTED] wrote:


OK. So, there are testsuite failures. I'm not seeing problems with
other testing, however... I see why you removed the hidden-classes
filter... Looks like we're in a bit of a Catch-22...

I assume restructuring the spring-based configuration of cxf is
pretty disruptive/potentially error-prone? Looks like some apps which
include Spring and use jaxws could run into the same type of
catch-22. Their only option would be to include the same version of
spring that's used by our cxf module...


Yes, I think so. But I could spend a day or two to see what it would
take to configure CXF without Spring.


I wasn't able to get this working. As described previously, I can get  
Spring apps deploying properly by filtering Spring classes and  
resources:


hidden-classes
  filterorg.springframework./filter
  filterMETA-INF/spring/filter
/hidden-classes

However, this breaks CXF-based JAXWS client code. So, some Spring  
apps running on Jetty/CXF will require a deployment plan to perform  
the filtering. For 2.0.1, we should switch our CXF configuration to  
not use Spring.


Also, we probably should create hidden-resources to our plans. So,  
above config would become:


hidden-classes
  filterorg.springframework./filter
/hidden-classes
hidden-resources
  filterMETA-INF/spring/filter
/hidden-resources

--kevan

[jira] Updated: (GERONIMO-3265) Spring stale version in 2.0-M6-rc1


 [ 
https://issues.apache.org/jira/browse/GERONIMO-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kevan Miller updated GERONIMO-3265:
---

Affects Version/s: 2.0
Fix Version/s: 2.0.x

We should fix this in 2.0.1 by rebasing our CXF configuration to a non-Spring 
solution. Until then, you can use a Geronimo deployment plan to avoid the 
problem. Something like:

?xml version=1.0 encoding=UTF-8?
web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; 
xmlns:dep=http://geronimo.apache.org/xml/ns/deployment-1.1; 
xmlns:naming=http://geronimo.apache.org/xml/ns/naming-1.1;
  dep:environment
dep:moduleId
  dep:groupIdorg.mygroup/dep:groupId
  dep:artifactIdMyApp/dep:artifactId
  dep:version1.1/dep:version
  dep:typecar/dep:type
/dep:moduleId
!-- 
 Don't load spring classes or spring resources from parent ClassLoaders.
  --
hidden-classes
  filterorg.springframework./filter
  filterMETA-INF/spring/filter
/hidden-classes

  /dep:environment

/web-app


 Spring stale version in 2.0-M6-rc1
 --

 Key: GERONIMO-3265
 URL: https://issues.apache.org/jira/browse/GERONIMO-3265
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 2.0-M6, 2.0
 Environment: Windows XP SP2, Sun JSDK 1.5.07, Geronimo (2.0-M6-rc1) 
 obtained from:
 http://people.apache.org/~hogstrom/2.0-M6-rc1/geronimo-tomcat6-jee5-2.0-M6-rc1-bin.zip
  (2.0-M6-rc1)
Reporter: Alexei Kozich
 Fix For: 2.0.x


 1. This Geronimo build includes spring-beans.jar, spring-context.jar and 
 spring-core.jar of version 2.0.
 So as far as we know, version 2.0 does not fully support integration with JPA 
 implementations.
 2. We developed an enterprise application (ear) which utilizes Spring 2.0.2 
 and OpenJPA.
 OpenJPA comes with Geronimo.
 Deployment and start of this application fails, because of different versions 
 of Spring (our application expects spring-beans.jar, spring-context.jar and 
 spring-core.jar to be at least of version 2.0.2 but Geronimo contains libs of 
 version 2.0 (the lack of some methods in version 2.0 is the problem here).
 3. If we try to use inverse-classloading or hidden classes 
 (org.springframework) in geronimo-web.xml and include all necesary libs in 
 WEB-INF/lib following Exception is thrown during deployment and start of the 
 application (see below).
 4. We found temporary workaround: to replace  spring-beans.jar, 
 spring-context.jar and spring-core.jar of version 2.0 with jars of version 
 2.0.2 in Geronimo repository without using of inverse-classloading and hidden 
 classes and everything looks fine.
 5. So as far as I understand this out-of-the-box Geronimo build could not be 
 used as Server for Spring-OpenJPA appications. At least  Spring libs upgrade 
 could solve this problem.
 6. Another problem is following Exception when using hidden classes or 
 inverse-classloading to load application jars first.
 ERROR [ContextLoader] Context initialization failed
 org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected 
 exception parsing XML document from ServletContext resource 
 [/WEB-INF/springAppContext.xml]; nested exception is 
 java.lang.IllegalArgumentException: Class 
 [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
 NamespaceHandler interface
 Caused by: 
 java.lang.IllegalArgumentException: Class 
 [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
 NamespaceHandler interface
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.initHandlerMappings(DefaultNamespaceHandlerResolver.java:119)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:96)
   at 
 org.springframework.beans.factory.xml.DefaultNamespaceHandlerResolver.init(DefaultNamespaceHandlerResolver.java:82)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createDefaultNamespaceHandlerResolver(XmlBeanDefinitionReader.java:526)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.createReaderContext(XmlBeanDefinitionReader.java:515)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:495)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:340)
   at 
 org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:317)
   at

Re: [VOTE] Release TxManager 2.0

2007-08-02 Thread Jeff Genender

+1

Matt Hogstrom wrote:
 All,
 
 
 Please take a peek at the jar files for the txManagr components that
 David Jencks had busted out earlier.  A tar ball can be found at
 http://people.apache.org/~hogstrom/txmanager-2.0-rc1/
 
 [ ] +1 Release these binaries
 [ ] 0  No opinion
 [ ] -1  Do not release these binaries (please provide reason.
 
 Vote will conclude on Sunday August 5th at  1300 Eastern.

Re: Changes to server started messages