[BUILD] 2.0: Failed for Revision: 596217

[prasad]

Geronimo Revision: 596217 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/build-0300.log
 
Download the binaries from 
http://people.apache.org/~prasad/binaries/2.0/20071119
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 33 minutes 3 seconds
[INFO] Finished at: Mon Nov 19 03:37:28 EST 2007
[INFO] Final Memory: 200M/996M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
See the full test.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/logs-0300/test.log
 
[INFO] Running console-testsuite.basic-console
[INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.47 
sec <<< FAILURE!
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.272 
sec <<< FAILURE!
--
[INFO] Running corba-testsuite.corba-mytime
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.046 
sec <<< FAILURE!
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.05 sec 
<<< FAILURE!
[INFO] Running deployment-testsuite.jca-cms
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.058 
sec <<< FAILURE!
[INFO] Running enterprise-testsuite.jms
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.041 
sec <<< FAILURE!
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.053 
sec <<< FAILURE!
[INFO] Running web-testsuite.jsps
[INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.08 sec 
<<< FAILURE!
[INFO] Running web-testsuite.myfaces
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.047 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.security
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 
sec <<< FAILURE!
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 
sec <<< FAILURE!
[INFO] Running web-testsuite.servlets
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.072 
sec <<< FAILURE!
 

[[GShell] Dependency on sun.* packages

[Guillaume Nodet]

It seems that GShell is currently unable to run without the sun.* packages
in the classloader.
The reason is that it uses xstream advanced mode which make use of these
packages.
If these packages are not on the classpath, xstream will default to the pure
java reflection provider which will cause exceptions like the following:

Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not
have a no-args constructor
 Debugging information 
message : Cannot construct
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a
no-args constructor
cause-exception :
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---

I'm not sure if this is a good idea or if we should support that pure java
mode...

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: [[GShell] Dependency on sun.* packages

[Jason Dillon]

Can ya put this in JIRA please?

--jason


On Nov 19, 2007, at 1:41 AM, Guillaume Nodet wrote:

It seems that GShell is currently unable to run without the sun.*  
packages in the classloader.
The reason is that it uses xstream advanced mode which make use of  
these packages.
If these packages are not on the classpath, xstream will default to  
the pure java reflection provider which will cause exceptions like  
the following:


Caused by: com.thoughtworks.xstream.converters.ConversionException:  
Cannot construct org.apache.geronimo.gshell.layout.model.CommandNode  
as it does not have a no-args constructor

 Debugging information 
message : Cannot construct  
org.apache.geronimo.gshell.layout.model.CommandNode as it does not  
have a no-args constructor
cause-exception :  
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct  
org.apache.geronimo.gshell.layout.model.CommandNode as it does not  
have a no-args constructor

class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   :  
org.apache.geronimo.gshell.layout.model.CommandNode

path: /layout/nodes/command
---

I'm not sure if this is a good idea or if we should support that  
pure java mode...


--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

[jira] Created: (GSHELL-81) Depdendency on sun.* packages

[Guillaume Nodet (JIRA)]

Depdendency on sun.* packages
-

 Key: GSHELL-81
 URL: https://issues.apache.org/jira/browse/GSHELL-81
 Project: GShell
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Guillaume Nodet
Assignee: Jason Dillon


It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.
The reason is that it uses xstream advanced mode which make use of these 
packages.
If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following:

Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information 
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---

I'm not sure if this is a good idea or if we should support that pure java 
mode...



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

[jira] Updated: (GSHELL-81) Depdendency on sun.* packages

[Jason Dillon (JIRA)]

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

Jason Dillon updated GSHELL-81:
---

Description: 
It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.
The reason is that it uses xstream advanced mode which make use of these 
packages.
If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following:

{noformat}
Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information 
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---
{noformat}

I'm not sure if this is a good idea or if we should support that pure java 
mode...



  was:
It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.
The reason is that it uses xstream advanced mode which make use of these 
packages.
If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following:

Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information 
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---

I'm not sure if this is a good idea or if we should support that pure java 
mode...




> Depdendency on sun.* packages
> -
>
> Key: GSHELL-81
> URL: https://issues.apache.org/jira/browse/GSHELL-81
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Guillaume Nodet
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> It seems that GShell is currently unable to run without the sun.* packages in 
> the classloader.
> The reason is that it uses xstream advanced mode which make use of these 
> packages.
> If these packages are not on the classpath, xstream will default to the pure 
> java reflection provider which will cause exceptions like the following:
> {noformat}
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
> construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
> have a no-args constructor
>  Debugging information 
> message : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> cause-exception : 
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message   : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> class   : org.apache.geronimo.gshell.layout.model.Layout
> required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
> path: /layout/nodes/command
> ---
> {noformat}
> I'm not sure if this is a good idea or if we should support that pure java 
> mode...

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

[jira] Updated: (GSHELL-81) Depdendency on sun.* packages

[Jason Dillon (JIRA)]

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

Jason Dillon updated GSHELL-81:
---

  Component/s: Core
Fix Version/s: 1.0-alpha-2
  Description: 
It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.

The reason is that it uses xstream advanced mode which make use of these 
packages.

If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following:

{noformat}
Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information 
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---
{noformat}

I'm not sure if this is a good idea or if we should support that pure java 
mode...



  was:
It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.
The reason is that it uses xstream advanced mode which make use of these 
packages.
If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following:

{noformat}
Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information 
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path: /layout/nodes/command
---
{noformat}

I'm not sure if this is a good idea or if we should support that pure java 
mode...




> Depdendency on sun.* packages
> -
>
> Key: GSHELL-81
> URL: https://issues.apache.org/jira/browse/GSHELL-81
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Guillaume Nodet
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> It seems that GShell is currently unable to run without the sun.* packages in 
> the classloader.
> The reason is that it uses xstream advanced mode which make use of these 
> packages.
> If these packages are not on the classpath, xstream will default to the pure 
> java reflection provider which will cause exceptions like the following:
> {noformat}
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
> construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
> have a no-args constructor
>  Debugging information 
> message : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> cause-exception : 
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message   : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> class   : org.apache.geronimo.gshell.layout.model.Layout
> required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
> path: /layout/nodes/command
> ---
> {noformat}
> I'm not sure if this is a good idea or if we should support that pure java 
> mode...

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

[jira] Commented: (GSHELL-81) Depdendency on sun.* packages

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543518
 ] 

Jason Dillon commented on GSHELL-81:


I think that the pure java stuff should probably work, we can give that a try.  
If it does work, we might actually be able to put XTream on a diet and remove 
some its fat... 

> Depdendency on sun.* packages
> -
>
> Key: GSHELL-81
> URL: https://issues.apache.org/jira/browse/GSHELL-81
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Guillaume Nodet
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> It seems that GShell is currently unable to run without the sun.* packages in 
> the classloader.
> The reason is that it uses xstream advanced mode which make use of these 
> packages.
> If these packages are not on the classpath, xstream will default to the pure 
> java reflection provider which will cause exceptions like the following:
> {noformat}
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
> construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
> have a no-args constructor
>  Debugging information 
> message : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> cause-exception : 
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message   : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> class   : org.apache.geronimo.gshell.layout.model.Layout
> required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
> path: /layout/nodes/command
> ---
> {noformat}
> I'm not sure if this is a good idea or if we should support that pure java 
> mode...

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

Re: [[GShell] Dependency on sun.* packages

[Jason Dillon]

What JVM were you using BTW?

--jason


-Original Message-
From: "Guillaume Nodet" <[EMAIL PROTECTED]>

Date: Mon, 19 Nov 2007 10:41:32 
To:dev@geronimo.apache.org
Subject: [[GShell] Dependency on sun.* packages


It seems that GShell is currently unable to run without the sun.* packages in 
the classloader.
The reason is that it uses xstream advanced mode which make use of these 
packages.
If these packages are not on the classpath, xstream will default to the pure 
java reflection provider which will cause exceptions like the following: 

Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
have a no-args constructor
 Debugging information  
message : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
cause-exception : 
com.thoughtworks.xstream.converters.reflection.ObjectAccessException 
cause-message   : Cannot construct 
org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
no-args constructor
class   : org.apache.geronimo.gshell.layout.model.Layout
required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
path    : /layout/nodes/command
---

I'm not sure if this is a good idea or if we should support that pure java 
mode... 

-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/  

[jira] Commented: (GSHELL-81) Depdendency on sun.* packages

[Jason Dillon (JIRA)]

[ 
https://issues.apache.org/jira/browse/GSHELL-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543523
 ] 

Jason Dillon commented on GSHELL-81:


Do you have a stack trace for this?

>From looking at the XStream src it appears that it should detect the best 
>reflection provider... maybe its best guess bits are not happy?



> Depdendency on sun.* packages
> -
>
> Key: GSHELL-81
> URL: https://issues.apache.org/jira/browse/GSHELL-81
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Core
>Reporter: Guillaume Nodet
>Assignee: Jason Dillon
> Fix For: 1.0-alpha-2
>
>
> It seems that GShell is currently unable to run without the sun.* packages in 
> the classloader.
> The reason is that it uses xstream advanced mode which make use of these 
> packages.
> If these packages are not on the classpath, xstream will default to the pure 
> java reflection provider which will cause exceptions like the following:
> {noformat}
> Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
> construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
> have a no-args constructor
>  Debugging information 
> message : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> cause-exception : 
> com.thoughtworks.xstream.converters.reflection.ObjectAccessException
> cause-message   : Cannot construct 
> org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
> no-args constructor
> class   : org.apache.geronimo.gshell.layout.model.Layout
> required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
> path: /layout/nodes/command
> ---
> {noformat}
> I'm not sure if this is a good idea or if we should support that pure java 
> mode...

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

[jira] Closed: (GERONIMO-3586) monitoring plugin: collecting agent should have separate jetty and tomcat plugins

[Viet Hung Nguyen (JIRA)]

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

Viet Hung Nguyen closed GERONIMO-3586.
--

   Resolution: Invalid
Fix Version/s: 2.1

The problem is now invalid. There are other ways to work around this without 
having to produce two plugins for the mrc-server. e.g. Returning a general 
StatsImpl object instead of the specific Tomcat*StatsImpl and Jetty*StatsImpl 
object.

> monitoring plugin: collecting agent should have separate jetty and tomcat 
> plugins
> -
>
> Key: GERONIMO-3586
> URL: https://issues.apache.org/jira/browse/GERONIMO-3586
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: monitoring
>Affects Versions: 2.1
> Environment: windows
>Reporter: Viet Hung Nguyen
>Assignee: Jarek Gawor
> Fix For: 2.1
>
> Attachments: geronimo-3586.patch
>
>
> The collecting agent plugin needs to have separate jetty and tomcat plugins 
> in order to accommodate for the differences in container specific 
> dependencies on stats implementation (.e.g JettyContainerStatsImpl and 
> JettyConnectorStatsImpl). When the collecting agent was an EAR, this was not 
> a problem; however, as a plugin, it is more tied down to having to specify 
> all dependencies in the plugin's classpath.

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

[jira] Commented: (GERONIMO-3545) Upgrade Apache Derby to 10.3.1.4

[Jarek Gawor (JIRA)]

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

Jarek Gawor commented on GERONIMO-3545:
---

Just committed the change (revision 596325). I already sent some notes about it 
to the TCK list two days ago and also added some notes about the problem in 
this bug report.



> Upgrade Apache Derby to 10.3.1.4
> 
>
> Key: GERONIMO-3545
> URL: https://issues.apache.org/jira/browse/GERONIMO-3545
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
>Reporter: Jacek Laskowski
>Assignee: Jacek Laskowski
> Fix For: 2.1
>
>
> Upgrade Derby to 10.3.1.4

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

Re: [DISCUSS] 2.1 Release

[Hernan Cunico]

Hey Dave,
for some reason my reply never went out. 


This is great, let's keep it here on GMOxDEV while you still working on it and 
then we'll see how to include/move over the 2.1 doc.

Cheers!
Hernan

David Jencks wrote:
I started a page on new plugin stuff over here... 
http://cwiki.apache.org/confluence/display/GMOxDEV/Plugin+Guide

(next time maybe I'll look at where you want it :-( )

I can't figure out how to get ${foo} to display without confluence 
thinking its a macro so any help there would be great.


Please feel free to move this to wherever it will fit best and comment 
on all the stuff I left out :-)


thanks
david jencks


On Nov 8, 2007, at 1:17 PM, Hernan Cunico wrote:


Hey y'all,
I started to map some of the new features/functions to the 2.1 
documentation.


I just created a new wiki space http://cwiki.apache.org/GMOxDOC21
and created some initial entries. Pls chime in with your ideas for 
topics to cover but don't stop just there,
feel free to start working out some content too if you feel compelled 
to do so ;-)


Help with the documentation is GREATLY APPRECIATED!!!

I will be starting a separate thread on user@ for user feedback as well.

Cheers!
Hernan

Hernan Cunico wrote:

Agreed, we seem to have enough new stuff to call for a release.
Here is a list trying to consolidate these new functions/improvements
- GShell
- Console enhancements (dep plan generation, grouping/collapsing?)
- Monitoring
- Plugin infrastructure
- Pluggable console
- Security
- Configuration (config.xml, config-subst, etc)
- Deployment plans
- Tooling
- ...?
We will also need a whole new set of documentation to cover these in 
GMOxDOC21.
Anybody in desperate need for contributing docs for these features? 
;-) it will be very much appreciated.

Cheers!
Hernan
Kevan Miller wrote:

I think it's time to start discussing the particulars of a 2.1 release.

There's been a lot of advancements made in our plugin 
infrastructure. There's also been the pluggable console 
enhancements. It would be good to get a release out, with these 
capabilities. They provide a more solid platform for future 
enhancements, I think.


There's also GShell and new monitoring capabilities. I'm probably 
missing a few other new functions.


Finally, IIUC, 2.1 would be able to support a Terracotta plugin. I'd 
also be very interested to hear what WADI capabilities that could be 
exposed.


I'm willing to bang the release manager drum. I see that Joe has 
already started tugging on the TCK chain


What do others think? How close are we to a 2.1 release? What 
additional capabilities and bug fixes are needed? Can we wrap up 
development activities in the next week or two?


--kevan

[BUILD] 2.0: Failed for Revision: 596295

[prasad]

Geronimo Revision: 596295 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/build-0900.log
 
Download the binaries from 
http://people.apache.org/~prasad/binaries/2.0/20071119
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 74 minutes 28 seconds
[INFO] Finished at: Mon Nov 19 10:24:41 EST 2007
[INFO] Final Memory: 188M/1001M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
See the full test.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/logs-0900/test.log
 
[INFO] Running console-testsuite.basic-console
[INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.412 
sec <<< FAILURE!
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.25 
sec <<< FAILURE!
--
[INFO] Running corba-testsuite.corba-mytime
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 
sec <<< FAILURE!
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.077 
sec <<< FAILURE!
[INFO] Running deployment-testsuite.jca-cms
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.068 
sec <<< FAILURE!
[INFO] Running enterprise-testsuite.jms
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.041 
sec <<< FAILURE!
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.049 
sec <<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.072 
sec <<< FAILURE!
[INFO] Running web-testsuite.jsps
[INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.089 
sec <<< FAILURE!
[INFO] Running web-testsuite.myfaces
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.052 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.security
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.051 
sec <<< FAILURE!
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 
sec <<< FAILURE!
[INFO] Running web-testsuite.servlets
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.058 
sec <<< FAILURE!
 

Re: Can we deal generically with container specific jsr77 statistics?

[Viet Nguyen]

I believe Anita is correct on this one. The specs define that we need
the getXYZ() methods for each statistics named XYZ. At this point, I
think we need to move forward with a decision a) put everything in
g-management or b) split jetty/tomcat stats apart.

As for me, I say let's just go with option A. In order for the
monitoring plugin to work on both assemblies this issue needs to be
resolved. If we plan on releasing the monitoring plugin with 2.1,
we'll need to have time to test it on both assemblies.

Thanks,
Viet

[jira] Commented: (GERONIMO-1265) Preserve comments added by users in the config.xml file

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-1265:
-

Committed revision 596403.

Here is a new set of changes that should hopefully finish fleshing out comment 
support in config.xml.

1) If there is no 'top level' comment in config.xml then a default warning 
comment will be inserted.  Once there is a comment, it will be retained.
2) If you include a comment element in the pom.xml file of a module at the 
GBean level, it will be carried over into the config.xml.
3) A comment added to config.xml at the module level will be retained.

Todo:
1) Figure out how a comment for the entire config.xml file can be placed into 
the source and make sure that it makes it to the final config.xml.
2) Figure out how  a comment for a full module (within) config.xml can be 
placed into the source and make sure it makes it to the final config.xml).

> Preserve comments added by users in the config.xml file
> ---
>
> Key: GERONIMO-1265
> URL: https://issues.apache.org/jira/browse/GERONIMO-1265
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown, usability
>Affects Versions: 1.0-M5, 1.0, 1.1, 2.1
>Reporter: John Sisson
>Assignee: Jay D. McHugh
> Attachments: geronimo-1265.patch
>
>
> Currently if a user adds comments to the config.xml file, they will be lost 
> when Geronimo re-generates the file if a configuration change is made (e.g. 
> through the web console).
> As a temporary measure, the code that re-generates the XML will place a 
> warning at the top of the file warning users not to place comments in it.

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

[jira] Resolved: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3266.
-

   Resolution: Fixed
Fix Version/s: 2.1

I believe that the attributes-1.2.xsd is sufficient to provide comments at all 
levels of the config.xml.

If there is some other information that someone needs/wants to store in 
config.xml - speak up.

> Enhance attributes schema (relates to config.xml)
> -
>
> Key: GERONIMO-3266
> URL: https://issues.apache.org/jira/browse/GERONIMO-3266
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown, usability
>Affects Versions: 2.0, 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.1
>
>
> Create a version 1.2 of the attributes.xsd to allow for comments anywhere in 
> the file.
> Are there any other enhancements that anyone would be interested in for 
> config.xml?
> If we can figure out what future changes would be desired, maybe we can 
> 'future-proof' the schema so we won't need to
> mess with it again (at least for a while).

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

[jira] Resolved: (GERONIMO-3271) Update all users of the attributes schema to use new version

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3271.
-

   Resolution: Fixed
Fix Version/s: 2.1

All programs that were referencing attributes-1.1.xsd have been changed over to 
use attributes-1.2.xsd.

> Update all users of the attributes schema to use new version
> 
>
> Key: GERONIMO-3271
> URL: https://issues.apache.org/jira/browse/GERONIMO-3271
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown
>Affects Versions: 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.1
>
>


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

svn: Can't move source to dest on Windows

[Jarek Gawor]

SVN checkout on Windows is failing for me becuase recently a file was
renamed to have ":" in the name. That's not supported on Windows. Can
we change this back?

Here's the change:
http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/

Here's the error I'm seeing:

svn: In directory
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d'
svn: Can't move source to dest
svn: Can't move
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,default.groovy.svn-base'
to 
'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,default.groovy.svn-base':
No such file or directory

Jarek

Remote Deployment

[Tim McConnell]

Hi, does anyone have a general understanding of how remote deployment using the 
Geronimo CLI is supposed to work ?? Reason I ask is that it doesn't appear to be 
working. Here are the messages I'm getting below:


Uploading 1 file(s) to server
Uploading mytime.ear: 11 KB
Uploading mytime.ear: 20 KB
File upload complete (Server status=OK)
File(s) transferred to server.  Resuming deployment operation.
Error: Unable to distribute mytime.ear:
java.io.FileNotFoundException: C:\TEMP\TRUNK\TC\var\temp\mytime.ear
(The system cannot find the path specified)

C:\TEMP\TRUNK\TC\var\temp\mytime.ear (The system cannot find the
path specified)

It seems like the deployable artifact is getting uploaded correctly to the 
remote server, but it also appears that the remote server is expecting it to 
have been uploaded to a particular path, which it is not -- thus the 
FileNotFoundException from the remote server. In this particular case, I'm using 
Geronimo 2.0.2 on both the remote and local servers. Thanks much for any 
pointers.



--
Thanks,
Tim McConnell

Re: Can we deal generically with container specific jsr77 statistics?

[David Jencks]

On Nov 19, 2007, at 7:33 AM, Viet Nguyen wrote:


I believe Anita is correct on this one. The specs define that we need
the getXYZ() methods for each statistics named XYZ. At this point, I
think we need to move forward with a decision a) put everything in
g-management or b) split jetty/tomcat stats apart.

As for me, I say let's just go with option A. In order for the
monitoring plugin to work on both assemblies this issue needs to be
resolved. If we plan on releasing the monitoring plugin with 2.1,
we'll need to have time to test it on both assemblies.


After reading Anita's explanation I agree A is the way to go.  Sorry  
for the apachecon delay in responding.


thanks
david jencks


Thanks,
Viet

[jira] Created: (GERONIMO-3608) Move Jetty*Stats and Jetty*StatsImpl to geronimo-management

[Anita Kulshreshtha (JIRA)]

Move Jetty*Stats and Jetty*StatsImpl to geronimo-management 


 Key: GERONIMO-3608
 URL: https://issues.apache.org/jira/browse/GERONIMO-3608
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Jetty, management
Affects Versions: 2.1
 Environment: All
Reporter: Anita Kulshreshtha
Assignee: Anita Kulshreshtha


Move Jetty*Stats and Jetty*StatsImpl to geronimo-management . The relevant 
discussion can be found at - 
http://www.nabble.com/Re%3A-Can-we-deal-generically-with-container-specific-jsr77-statistics--p13688310s134.html

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

[jira] Commented: (GERONIMO-3608) Move Jetty*Stats and Jetty*StatsImpl to geronimo-management

[Anita Kulshreshtha (JIRA)]

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

Anita Kulshreshtha commented on GERONIMO-3608:
--

committed in rev. 596514, also fixed statistics names in WebContainerStatsImpl 
to comply with JSR77.6.10.1.1

> Move Jetty*Stats and Jetty*StatsImpl to geronimo-management 
> 
>
> Key: GERONIMO-3608
> URL: https://issues.apache.org/jira/browse/GERONIMO-3608
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Jetty, management
>Affects Versions: 2.1
> Environment: All
>Reporter: Anita Kulshreshtha
>Assignee: Anita Kulshreshtha
>
> Move Jetty*Stats and Jetty*StatsImpl to geronimo-management . The relevant 
> discussion can be found at - 
> http://www.nabble.com/Re%3A-Can-we-deal-generically-with-container-specific-jsr77-statistics--p13688310s134.html

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

[BUILD] 2.0: Failed for Revision: 596510

[prasad]

Geronimo Revision: 596510 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/build-2100.log
 
Download the binaries from 
http://people.apache.org/~prasad/binaries/2.0/20071119
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 32 minutes 39 seconds
[INFO] Finished at: Mon Nov 19 21:37:55 EST 2007
[INFO] Final Memory: 199M/974M
[INFO] 
 
TESTSUITE RESULTS (Failures only)
=
See detailed results at 
http://people.apache.org/~prasad/testsuite/ResultsSummary.html
See the full test.log file at 
http://people.apache.org/~prasad/binaries/2.0/20071119/logs-2100/test.log
 
[INFO] Running console-testsuite.basic-console
[INFO] Tests run: 38, Failures: 38, Errors: 0, Skipped: 0, Time elapsed: 0.43 
sec <<< FAILURE!
[INFO] Running console-testsuite.advance-test
[INFO] Tests run: 12, Failures: 12, Errors: 0, Skipped: 0, Time elapsed: 0.276 
sec <<< FAILURE!
--
[INFO] Running corba-testsuite.corba-mytime
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 
sec <<< FAILURE!
[INFO] Running deployment-testsuite.deployment
[INFO] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.056 
sec <<< FAILURE!
[INFO] Running deployment-testsuite.jca-cms
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.056 
sec <<< FAILURE!
[INFO] Running enterprise-testsuite.jms
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.043 
sec <<< FAILURE!
[INFO] Running jpa-testsuite.jpa
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.05 sec 
<<< FAILURE!
[INFO] Running sec-testsuite.security
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.052 
sec <<< FAILURE!
[INFO] Running web-testsuite.jsps
[INFO] Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 0.081 
sec <<< FAILURE!
[INFO] Running web-testsuite.myfaces
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.055 
sec <<< FAILURE!
--
[INFO] Running web-testsuite.security
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.045 
sec <<< FAILURE!
[INFO] Running web-testsuite.references
[INFO] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.048 
sec <<< FAILURE!
[INFO] Running web-testsuite.servlets
[INFO] Tests run: 2, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec 
<<< FAILURE!
 

[jira] Created: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty

[Jarek Gawor (JIRA)]

JNDI lookup problem on fowarded calls in Jetty
--

 Key: GERONIMO-3609
 URL: https://issues.apache.org/jira/browse/GERONIMO-3609
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Jetty
Affects Versions: 2.0.x, 2.1
Reporter: Jarek Gawor


I am having trouble looking up a DataSource from an EAR containing a
WAR (which is where the lookup takes place) using JNDI. I find it to
be really weird, because I can look up the DataSource fine if I do it
through a JSP page or a servlet. However, when I try to look it up in
portlet code, the jndi name does not seem to be visible, although it
is visible in the JNDI viewer. Additionally, I have successfully
looked it up through jsp and servlets.

This is only a problem in Jetty, because the same code works fine for Tomcat.


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

Re: JNDI lookup problem in Jetty portlet

[Jarek Gawor]

I've looked at this a bit and here's my current understanding of the
problem. First, we are dealing with two different web application
contexts (/console and /MonitoringPortlet) and both web app contexts
have different JNDI trees with different resources. The console is
basically forwarding a request from /console to /MonitoringPortlet. It
looks like on Jetty when a request is forwarded from one context to
another, the JNDI tree associated with the current thread does NOT
change for the duration of the call. That means, when a monitoring
portlet looks for resources in JNDI it actaully gets /console JNDI
tree instead of its own.
Your portlet works on Tomcat as Tomcat appears to be properly
switching the JNDI trees during the call.

So this seems like a bug in Jetty but I couldn't really find much info
on how this should work in the specs. Does anybody know?

For now I opened a bug to track this issue:
https://issues.apache.org/jira/browse/GERONIMO-3609

Jarek

On Nov 16, 2007 11:03 AM, Viet Nguyen <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I am having trouble looking up a DataSource from an EAR containing a
> WAR (which is where the lookup takes place) using JNDI. I find it to
> be really weird, because I can look up the DataSource fine if I do it
> through a JSP page or a servlet. However, when I try to look it up in
> portlet code, the jndi name does not seem to be visible, although it
> is visible in the JNDI viewer. Additionally, I have successfully
> looked it up through jsp and servlets.
>
> This is only a problem in Jetty, because the same code works fine for Tomcat.
>
> Is this possibly a Geronimo/XBean bug in how we bind JNDI names? I am
> not familiar with the jndi binding process, so any expertise in that
> area or the portlet area will be much appreciated.
>
> Thanks,
> Viet
>

[jira] Updated: (GSHELL-20) `set foo="bar"` does not work as expected

[Jason Warner (JIRA)]

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

Jason Warner updated GSHELL-20:
---

Attachment: GShell-20.patch

I was hoping to handle this purely in the parser, but I'm not sure if that is 
possible.  There's a little bit of code in the SetCommand.java file that parses 
the input string to remove the quotes.  I couldn't figure a way to remove them 
using just the parser.  

> `set foo="bar"` does not work as expected
> -
>
> Key: GSHELL-20
> URL: https://issues.apache.org/jira/browse/GSHELL-20
> Project: GShell
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Commands, Core
>Affects Versions: 0.0.1
>Reporter: Jason Dillon
>Assignee: Jason Warner
>Priority: Critical
> Fix For: 1.0-alpha-2
>
> Attachments: GShell-20.patch
>
>
> Due to the way parsing happens, this line:
> {noformat}
> set foo="bar"
> {noformat}
> Ends up calling the command with 2 arguments: "foo=" and "bar", which is not 
> what the command expects, which is one argument of: "foo=bar"

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

[jira] Commented: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty

[Jarek Gawor (JIRA)]

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

Jarek Gawor commented on GERONIMO-3609:
---

First, we are dealing with two different web application
contexts (/console and /MonitoringPortlet) and both web app contexts
have different JNDI trees with different resources. The console is
basically forwarding a request from /console to /MonitoringPortlet. It
looks like on Jetty when a request is forwarded from one context to
another, the JNDI tree associated with the current thread does NOT
change for the duration of the call. That means, when a monitoring
portlet looks for resources in JNDI it actaully gets /console JNDI
tree instead of its own.
Your portlet works on Tomcat as Tomcat appears to be properly
switching the JNDI trees during the call.


> JNDI lookup problem on fowarded calls in Jetty
> --
>
> Key: GERONIMO-3609
> URL: https://issues.apache.org/jira/browse/GERONIMO-3609
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.0.x, 2.1
>Reporter: Jarek Gawor
>
> I am having trouble looking up a DataSource from an EAR containing a
> WAR (which is where the lookup takes place) using JNDI. I find it to
> be really weird, because I can look up the DataSource fine if I do it
> through a JSP page or a servlet. However, when I try to look it up in
> portlet code, the jndi name does not seem to be visible, although it
> is visible in the JNDI viewer. Additionally, I have successfully
> looked it up through jsp and servlets.
> This is only a problem in Jetty, because the same code works fine for Tomcat.

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

Re: svn: Can't move source to dest on Windows

[Vamsavardhana Reddy]

There is also a comma in the filename!!  Should that be got rid of too?

++Vamsi

On Nov 20, 2007 1:27 AM, Jarek Gawor <[EMAIL PROTECTED]> wrote:

> SVN checkout on Windows is failing for me becuase recently a file was
> renamed to have ":" in the name. That's not supported on Windows. Can
> we change this back?
>
> Here's the change:
>
> http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/
>
> Here's the error I'm seeing:
>
> svn: In directory
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d'
> svn: Can't move source to dest
> svn: Can't move
>
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/tmp/prop-base/geronimo-commands:start-server,
> default.groovy.svn-base'
> to
> 'assemblies/geronimo-boilerplate-minimal/src/main/underlay/etc/rc.d/.svn/prop-base/geronimo-commands:start-server,
> default.groovy.svn-base':
> No such file or directory
>
> Jarek
>

[jira] Created: (GERONIMO-3610) Allows the override of XML JavaBean attribute in config.xml

[Gianny Damour (JIRA)]

Allows the override of XML JavaBean attribute in config.xml
---

 Key: GERONIMO-3610
 URL: https://issues.apache.org/jira/browse/GERONIMO-3610
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: management
Affects Versions: 2.0.2
Reporter: Gianny Damour
Assignee: Gianny Damour
 Fix For: 2.0.x


At the moment, it is not so easy to override an attribute defined by a JavaBean 
xml-attribute element in a configuration plan. It should be possible to 
override such JavaBean xml-attributes by specifying a custom property editor 
relying on the same xml-attribute processing to build JavaBeans and override an 
attribute.

Also, users should be able to declare which JavaBean attributes need to be 
encrypted prior to write them in config.xml (replicate the handling of 
"password" attribute for GBean attribute overrides).

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

[jira] Closed: (GERONIMO-3610) Allows the override of XML JavaBean attribute in config.xml

[Gianny Damour (JIRA)]

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

Gianny Damour closed GERONIMO-3610.
---

Resolution: Fixed

Now implemented.

> Allows the override of XML JavaBean attribute in config.xml
> ---
>
> Key: GERONIMO-3610
> URL: https://issues.apache.org/jira/browse/GERONIMO-3610
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: management
>Affects Versions: 2.0.2
>Reporter: Gianny Damour
>Assignee: Gianny Damour
> Fix For: 2.0.x
>
>
> At the moment, it is not so easy to override an attribute defined by a 
> JavaBean xml-attribute element in a configuration plan. It should be possible 
> to override such JavaBean xml-attributes by specifying a custom property 
> editor relying on the same xml-attribute processing to build JavaBeans and 
> override an attribute.
> Also, users should be able to declare which JavaBean attributes need to be 
> encrypted prior to write them in config.xml (replicate the handling of 
> "password" attribute for GBean attribute overrides).

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

[jira] Updated: (GERONIMO-3609) JNDI lookup problem on fowarded calls in Jetty

[Jarek Gawor (JIRA)]

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

Jarek Gawor updated GERONIMO-3609:
--

Attachment: GERONIMO-3609.patch

Proposed fix for this issue.


> JNDI lookup problem on fowarded calls in Jetty
> --
>
> Key: GERONIMO-3609
> URL: https://issues.apache.org/jira/browse/GERONIMO-3609
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Jetty
>Affects Versions: 2.0.x, 2.1
>Reporter: Jarek Gawor
> Attachments: GERONIMO-3609.patch
>
>
> I am having trouble looking up a DataSource from an EAR containing a
> WAR (which is where the lookup takes place) using JNDI. I find it to
> be really weird, because I can look up the DataSource fine if I do it
> through a JSP page or a servlet. However, when I try to look it up in
> portlet code, the jndi name does not seem to be visible, although it
> is visible in the JNDI viewer. Additionally, I have successfully
> looked it up through jsp and servlets.
> This is only a problem in Jetty, because the same code works fine for Tomcat.

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