date:20071128

Review SubjectRegistrationLoginModule
-

 Key: GERONIMO-3639
 URL: https://issues.apache.org/jira/browse/GERONIMO-3639
 Project: Geronimo
  Issue Type: Task
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


Review SubjectRegistrationLoginModule for potential violations and security 
risks.

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

[jira] Created: (GSHELL-82) Bring the testsuite back

Bring the testsuite back


 Key: GSHELL-82
 URL: https://issues.apache.org/jira/browse/GSHELL-82
 Project: GShell
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Blocker
 Fix For: 1.0-alpha-2


Need to bring the testsuite back so that we can create integration tests for 
commands.  Actually need to see if we can use SHITTY to allow command modules 
to create localized integration tests.

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

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

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

Jason Dillon commented on GSHELL-20:

I basically just tossed together this grammar with my somewhat limited
knowledge and experience with JavaCC. I'd really like to be able to lean on
the parser to generate a more complex AST tree which can handle more of these
language subtitles , but that is pushing the limit of hoops I can personally
make JavaCC (or another like Antlr) jump through.

Would really be nice if the universe handed us a motivated folk (or two) who
where uber-savvy with JavaCC (or Antlr3) to build more complicated AST trees...

Anyways, I know this part of the system is lacking, which is why I had hacked
around it before, like using Jexl to handle the ${...} bits and some more
specific post processing (like what is done in {{set}}) to handle (somewhat
poorly) what the feeble parser isn't doing for us.

This is definitely one of the weak parts of the system right now. I really
would like to get a parser which can take most any BASH-like syntax and make
sense of it. That is the ultimate goal IMO... complete BASH syntax
compatibility (or really, ZSH since I think its got some extra nice bits).

I will test this patch in the next day or so... though you know its just a
bandaid na? What really needs to be done is to make the parser aware of this
stuff, then maybe create a visitor to build a simple version of the tree
elements suitable for handing to the executing visitor. The intermediate could
handle things like:

{noformat}
echo foobar
{noformat}

and reduce that to simple this to pass to commands for execution:

{noformat}
echo foobar
{noformat}

Or something like that.

Maybe I can coax one of the Antlr gurus on the Groovy team to lean a hand with
this. But if you, or anyone else who reads JIRA comments, knows of someone and
they are interested, I'd really love to haver some expert help with this part
of GShell.

`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] Updated: (GERONIMO-3639) Review SubjectRegistrationLoginModule


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

Vamsavardhana Reddy updated GERONIMO-3639:
--

 Priority: Trivial  (was: Major)
Affects Version/s: (was: 2.0.x)
   (was: 2.1)
Fix Version/s: (was: 2.0.x)
   (was: 2.1)

Invalid since SubjectRegistrationLoginModule is no more.  See GERONIMO-3407.

At Revision: 598938
o Deleted SubjectRegistrationLoginModule.java that should have been deleted 
from branches\2.0 in rev 565936.

 Review SubjectRegistrationLoginModule
 -

 Key: GERONIMO-3639
 URL: https://issues.apache.org/jira/browse/GERONIMO-3639
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Priority: Trivial

 Review SubjectRegistrationLoginModule for potential violations and security 
 risks.

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

[jira] Closed: (GERONIMO-3639) Review SubjectRegistrationLoginModule


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

Vamsavardhana Reddy closed GERONIMO-3639.
-

Resolution: Invalid

 Review SubjectRegistrationLoginModule
 -

 Key: GERONIMO-3639
 URL: https://issues.apache.org/jira/browse/GERONIMO-3639
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: security
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
Priority: Trivial

 Review SubjectRegistrationLoginModule for potential violations and security 
 risks.

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

[jira] Commented: (GERONIMO-3407) SubjectRegistrationLoginModule conceptually can't work.


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

Vamsavardhana Reddy commented on GERONIMO-3407:
---

At Revision: 598938
o Deleted SubjectRegistrationLoginModule.java that should have been deleted 
from branches\2.0 in rev 565936.

 SubjectRegistrationLoginModule conceptually can't work.
 ---

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


 The idea of SubjectRegistrationLoginModule while attractive just can't work.  
 The idea behind subject registration is that we want to compute the 
 AccessControlContext for a subject once and cache it.  That can only be done 
 once the subject is fully populated by all login modules, so if the ACC is 
 determined by a login module it must be the last one.  However, if any 
 previous LM is marked REQUISITE no further modules will be processed.  
 Therefore we have to register the subjects in some other way.  Just maybe we 
 could preregister the subject but determine the ACC lazily??

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

[jira] Created: (GERONIMO-3640) Eliminate UPCredentialLoginModule

Eliminate UPCredentialLoginModule
-

 Key: GERONIMO-3640
 URL: https://issues.apache.org/jira/browse/GERONIMO-3640
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


UPCredentialLoginModule seems to serve the same purpose as 
GeronimoPasswordCredentialLoginModule.  Searching the codebase for references 
to UPCredentialLoginModule yields no results. Also 
GeronimoPasswordCredentialLoginModule is the one used by Security realms 
portlet.  It may be a good idea to eliminate UPCredentialLoginModule and 
related classes.

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

[jira] Updated: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server

2007-11-28 Thread Piotr Szczepanik (JIRA)


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

Piotr Szczepanik updated GERONIMODEVTOOLS-252:
--


Hi Kan,
it's not a bug indeed, so we can close it.

Thanks,
Piotr Szczepanik

 VM arguments are reverted to default ones after starting the server
 ---

 Key: GERONIMODEVTOOLS-252
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.0.0
 Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 
 1.6.0_03-b05
Reporter: Piotr Szczepanik
Priority: Minor
 Attachments: ServerVMArguments.jpg


 If you change VM arguments in the Run Dialog for Apache Geronimo (ie. 
 adding -XX:MaxPermSize=128m which is needed on my platform) they are 
 reverted back to default value after you successfully the server.
 What is worse they are not applied to the server that has just started.
 Steps to reproduce:
 1. Change VM arguments
 2. Start the server
 3. Wait for the start of the server
 4. Check the VM arguments
 5. They are reverted back to default one

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

[jira] Created: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule

NamedUPCredentialLoginModule vs 
ConfiguredIdentityNamedUsernamePasswordLoginModule
--

 Key: GERONIMO-3641
 URL: https://issues.apache.org/jira/browse/GERONIMO-3641
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and 
NamedUPCredentialLoginModule are added to geronimo codebase around the same 
time (rev 159325 and rev 159560).  The difference between the two is that 
NamedUPCredentialLoginModule uses the user supplied username and password where 
as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username and 
password from options supplied to the login module.  
NamedUPCredentialLoginModule is used by the Security realms portlet whereas 
there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule 
in the codebase.  I guess one of them (most likely 
ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it should 
be eliminated.  What am I missing?

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

[jira] Updated: (GERONIMO-3636) replace refresh link on console log views with buttons and fix broken server log viewer filter

2007-11-28 Thread Joe Bohn (JIRA)


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

Joe Bohn updated GERONIMO-3636:
---

Description: Cosmetic change to replace the refresh links on the log view 
pages with buttons.  Also, improve the terminology on the filter criteria 
selections and fix the server log viewer filter to work again (currently 
doesn't show selected log level in drop down and does not preserve the 
selection upon response).  (was: Cosmetic change to replace the refresh links 
on the log view pages with buttons.  Also, improve the terminology on the 
filter criteria selections.)
Summary: replace refresh link on console log views with buttons and fix 
broken server log viewer filter  (was: replace refresh link on console log 
views with buttons)

 replace refresh link on console log views with buttons and fix broken server 
 log viewer filter
 --

 Key: GERONIMO-3636
 URL: https://issues.apache.org/jira/browse/GERONIMO-3636
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: console
Affects Versions: 2.1
Reporter: Joe Bohn
Assignee: Joe Bohn
Priority: Minor

 Cosmetic change to replace the refresh links on the log view pages with 
 buttons.  Also, improve the terminology on the filter criteria selections and 
 fix the server log viewer filter to work again (currently doesn't show 
 selected log level in drop down and does not preserve the selection upon 
 response).

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

[jira] Created: (GERONIMO-3642) monitoring client to provide the ability to test connections

monitoring client to provide the ability to test connections


 Key: GERONIMO-3642
 URL: https://issues.apache.org/jira/browse/GERONIMO-3642
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3642.patch

The monitoring client allows the user to add and edit the server; however, it 
will be nice if the user was able to determine their configuration of the 
server is actually a valid one. A test connection option will be ideal to 
have for this purpose.

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

[jira] Commented: (GERONIMO-3642) monitoring client to provide the ability to test connections


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

Erik B. Craig commented on GERONIMO-3642:
-

Committed revision 599039.
Thanks Viet

 monitoring client to provide the ability to test connections
 

 Key: GERONIMO-3642
 URL: https://issues.apache.org/jira/browse/GERONIMO-3642
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3642.patch


 The monitoring client allows the user to add and edit the server; however, it 
 will be nice if the user was able to determine their configuration of the 
 server is actually a valid one. A test connection option will be ideal to 
 have for this purpose.

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

[jira] Updated: (GERONIMO-3642) monitoring client to provide the ability to test connections


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

Viet Hung Nguyen updated GERONIMO-3642:
---

Attachment: geronimo-3642.patch

 monitoring client to provide the ability to test connections
 

 Key: GERONIMO-3642
 URL: https://issues.apache.org/jira/browse/GERONIMO-3642
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3642.patch


 The monitoring client allows the user to add and edit the server; however, it 
 will be nice if the user was able to determine their configuration of the 
 server is actually a valid one. A test connection option will be ideal to 
 have for this purpose.

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

[jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-11-28 Thread Jay D. McHugh (JIRA)

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

Jay D. McHugh updated GERONIMO-3300:

Description:
Dojo 1.0 is now available.

But, to upgrade we will either need to rewrite all of the plugins that use Dojo
widgets to use the new (backward incompatible) versions -or- include both the
0.4.3 and 1.0.0 versions of Dojo.

Having both versions would make it possible to transition over to the newer
version of Dojo in a more leisurely fashion but would introduce a fairly
significant amount of bloat.

I would prefer that we would just replace the old version and rewrite whatever
needs to be rewritten but that would depend on how soon we are trying to get
G2.1 out the door.

was:
The new Dojo 0.9 Beta was just released.

It will reduce the footprint of the main dojo.js to under 50k - But will
require that some of the console
screens to be reworked because the widget system was completely redesigned and
is incompatible.

Affects Version/s: (was: 2.0-M7)
2.1
Summary: Upgrade Dojo to 1.0 (was: Upgrade Dojo to 0.9)

Upgrade Dojo to 1.0
---

Key: GERONIMO-3300
URL: https://issues.apache.org/jira/browse/GERONIMO-3300
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

Dojo 1.0 is now available.
But, to upgrade we will either need to rewrite all of the plugins that use
Dojo widgets to use the new (backward incompatible) versions -or- include
both the 0.4.3 and 1.0.0 versions of Dojo.
Having both versions would make it possible to transition over to the newer
version of Dojo in a more leisurely fashion but would introduce a fairly
significant amount of bloat.
I would prefer that we would just replace the old version and rewrite
whatever needs to be rewritten but that would depend on how soon we are
trying to get G2.1 out the door.

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

Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-11-28 Thread Jay D. McHugh

Hello all,

I was wondering, what timeframe most folks have in mind for getting 2.1
released?

I would like to be able to get Dojo 1.0 in as the only version that we
include in the server - but rewriting everything to use the new widgets
may take a while.

Jay
Jay D. McHugh (JIRA) wrote:
[
https://issues.apache.org/jira/browse/GERONIMO-3300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jay D. McHugh updated GERONIMO-3300:

Description:
Dojo 1.0 is now available.

But, to upgrade we will either need to rewrite all of the plugins that use
Dojo widgets to use the new (backward incompatible) versions -or- include
both the 0.4.3 and 1.0.0 versions of Dojo.

Having both versions would make it possible to transition over to the newer
version of Dojo in a more leisurely fashion but would introduce a fairly
significant amount of bloat.

I would prefer that we would just replace the old version and rewrite
whatever needs to be rewritten but that would depend on how soon we are
trying to get G2.1 out the door.

was:
The new Dojo 0.9 Beta was just released.

Affects Version/s: (was: 2.0-M7)
2.1
Summary: Upgrade Dojo to 1.0 (was: Upgrade Dojo to 0.9)

Upgrade Dojo to 1.0
---

[jira] Updated: (GERONIMO-3643) monitoring plugin should also package both client and server into one deployable


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

Viet Hung Nguyen updated GERONIMO-3643:
---

Attachment: geronimo-3643.patch

 monitoring plugin should also package both client and server into one 
 deployable
 

 Key: GERONIMO-3643
 URL: https://issues.apache.org/jira/browse/GERONIMO-3643
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3643.patch


 Monitoring plugin should have a Client Plugin, a Server Plugin, and also 
 a Client + Server Plugin (in case anyone wants to monitor the local 
 machine).

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

[jira] Created: (GERONIMO-3643) monitoring plugin should also package both client and server into one deployable

monitoring plugin should also package both client and server into one deployable


 Key: GERONIMO-3643
 URL: https://issues.apache.org/jira/browse/GERONIMO-3643
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3643.patch

Monitoring plugin should have a Client Plugin, a Server Plugin, and also a 
Client + Server Plugin (in case anyone wants to monitor the local machine).

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

[jira] Created: (GERONIMO-3644) Adding a second TomcatContainer is resulting in IllegalArgumentException

Adding a second TomcatContainer is resulting in IllegalArgumentException


 Key: GERONIMO-3644
 URL: https://issues.apache.org/jira/browse/GERONIMO-3644
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Tomcat
Affects Versions: 2.0.2, 2.0.1, 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


I have added a second TomcatContainer gbean to config.xml using the following 
xml:

gbean gbeanInfo=org.apache.geronimo.tomcat.TomcatContainer 
name=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer
attribute name=catalinaHomevar/catalina/attribute
reference name=EngineGBean
patternnameTomcatEngine/name/pattern
/reference
reference name=ServerInfo
patternnameServerInfo/name/pattern
/reference
reference name=WebManager
patternnameTomcatWebManager/name/pattern
/reference
/gbean

Upon starting the server, I am getting an IllegalArgumentException.  Exception 
is occurring since no name is set for defaultContext created around line 221 in 
TomcatContainer.java it is using a name which is an empty string.  StackTrace 
is given below.

21:51:11,359 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
the FAILED state: 
abstractName=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer
java.lang.IllegalArgumentException: addChild:  Child name '' is not unique
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at 
org.apache.geronimo.tomcat.TomcatContainer.doStart(TomcatContainer.java:232)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
at 
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
at 
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at 
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at 
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
at 
org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
at 
org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:448)
at 
org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
at

[jira] Resolved: (GERONIMO-3642) monitoring client to provide the ability to test connections


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

Viet Hung Nguyen resolved GERONIMO-3642.


   Resolution: Fixed
Fix Version/s: 2.1

 monitoring client to provide the ability to test connections
 

 Key: GERONIMO-3642
 URL: https://issues.apache.org/jira/browse/GERONIMO-3642
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Fix For: 2.1

 Attachments: geronimo-3642.patch


 The monitoring client allows the user to add and edit the server; however, it 
 will be nice if the user was able to determine their configuration of the 
 server is actually a valid one. A test connection option will be ideal to 
 have for this purpose.

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

[jira] Resolved: (GERONIMO-3637) monitoring client does not save the editted snapshot duration


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

Viet Hung Nguyen resolved GERONIMO-3637.


   Resolution: Fixed
Fix Version/s: 2.1

 monitoring client does not save the editted snapshot duration
 -

 Key: GERONIMO-3637
 URL: https://issues.apache.org/jira/browse/GERONIMO-3637
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Fix For: 2.1

 Attachments: geronimo-3637.patch


 monitoring client needs to make a call to the server to save the snapshot 
 duration into the snapshot-config.xml.

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

Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-11-28 Thread Viet Nguyen

Hi Jay,

Is there a reason why you just want Dojo 1.0 and scratch 0.4.3? I think it's
easier for users who have already tuned their applications to use 0.4.3, to
have both versions in there. I do not think Dojo will take up a significant
amount of space.

This way, we don't have to necessarily rewrite all modules that use Dojo
0.4.3.

Regards,
Viet

Re: [jira] Created: (GERONIMO-3643) monitoring plugin should also package both client and server into one deployable

2007-11-28 Thread Erik B. Craig


Viet Hung Nguyen (JIRA) wrote:

monitoring plugin should also package both client and server into one deployable


 Key: GERONIMO-3643
 URL: https://issues.apache.org/jira/browse/GERONIMO-3643
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3643.patch

Monitoring plugin should have a Client Plugin, a Server Plugin, and also a 
Client + Server Plugin (in case anyone wants to monitor the local machine).

  

Excellent
(this is a guise for an email test)

Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-11-28 Thread Jay D. McHugh

I don't have a particularly strong reason for scratching 0.4.3 except
that 1.0 is where they started calling it 'production ready'.

I guess we could just repackage Dojo as two plugins - one for 0.4.3 and
one for 1.0.1 and have the version as part of the path.  Then gradually
move things over.

I do think that it will be worthwhile to rework the console to use the
new version eventually though.  Supposedly, the new widgets are more
stable and faster.

Jay

Viet Nguyen wrote:
 Hi Jay,
 
 Is there a reason why you just want Dojo 1.0 and scratch 0.4.3? I think it's
 easier for users who have already tuned their applications to use 0.4.3, to
 have both versions in there. I do not think Dojo will take up a significant
 amount of space.
 
 This way, we don't have to necessarily rewrite all modules that use Dojo
 0.4.3.
 
 Regards,
 Viet

[jira] Commented: (GERONIMO-3643) monitoring plugin should also package both client and server into one deployable


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

Erik B. Craig commented on GERONIMO-3643:
-

Committed revision 599077
Thanks Viet

 monitoring plugin should also package both client and server into one 
 deployable
 

 Key: GERONIMO-3643
 URL: https://issues.apache.org/jira/browse/GERONIMO-3643
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3643.patch


 Monitoring plugin should have a Client Plugin, a Server Plugin, and also 
 a Client + Server Plugin (in case anyone wants to monitor the local 
 machine).

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

Re: [jira] Updated: (GERONIMO-3300) Upgrade Dojo to 1.0

2007-11-28 Thread Erik B. Craig

Jay,
Although I don't have any idea on the timeframe for 2.1, I am definitely
in favor of getting Dojo 1.0 in before 2.1, as I would be very eager to
be able to move the monitoring client that Viet and I are working on
over to the new charting abilities.
As far as keeping 0.4.3 in vs. removing it... it would probably be more
realistic to keep it in not only for concerns with moving the entire
console over, but also with concern for the complete lack of backwards
compatibility for the user base... anyone that may be using our
implemented Dojo.

Thanks,
Erik B. Craig
[EMAIL PROTECTED]

Jay D. McHugh wrote:

Hello all,

I was wondering, what timeframe most folks have in mind for getting 2.1
released?

I would like to be able to get Dojo 1.0 in as the only version that we
include in the server - but rewriting everything to use the new widgets
may take a while.

Jay
Jay D. McHugh (JIRA) wrote:

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

Jay D. McHugh updated GERONIMO-3300:

Description:
Dojo 1.0 is now available.

But, to upgrade we will either need to rewrite all of the plugins that use Dojo
widgets to use the new (backward incompatible) versions -or- include both the
0.4.3 and 1.0.0 versions of Dojo.

Having both versions would make it possible to transition over to the newer
version of Dojo in a more leisurely fashion but would introduce a fairly
significant amount of bloat.

I would prefer that we would just replace the old version and rewrite whatever
needs to be rewritten but that would depend on how soon we are trying to get
G2.1 out the door.

was:
The new Dojo 0.9 Beta was just released.

Affects Version/s: (was: 2.0-M7)
2.1
Summary: Upgrade Dojo to 1.0 (was: Upgrade Dojo to 0.9)

Upgrade Dojo to 1.0
---

Key: GERONIMO-3300
URL: https://issues.apache.org/jira/browse/GERONIMO-3300
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: console

Affects Versions: 2.1
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh

Dojo 1.0 is now available.
But, to upgrade we will either need to rewrite all of the plugins that use Dojo
widgets to use the new (backward incompatible) versions -or- include both the
0.4.3 and 1.0.0 versions of Dojo.
Having both versions would make it possible to transition over to the newer
version of Dojo in a more leisurely fashion but would introduce a fairly
significant amount of bloat.
I would prefer that we would just replace the old version and rewrite whatever
needs to be rewritten but that would depend on how soon we are trying to get
G2.1 out the door.

[jira] Closed: (GERONIMODEVTOOLS-252) VM arguments are reverted to default ones after starting the server

2007-11-28 Thread Tim McConnell (JIRA)


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

Tim McConnell closed GERONIMODEVTOOLS-252.
--

   Resolution: Invalid
Fix Version/s: 2.0.2

Closing per Kan and Piotr

 VM arguments are reverted to default ones after starting the server
 ---

 Key: GERONIMODEVTOOLS-252
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-252
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.0.0
 Environment: Ubuntu Linux 7.10 (i386), Eclipse 3.3.1, Java 
 1.6.0_03-b05
Reporter: Piotr Szczepanik
Priority: Minor
 Fix For: 2.0.2

 Attachments: ServerVMArguments.jpg


 If you change VM arguments in the Run Dialog for Apache Geronimo (ie. 
 adding -XX:MaxPermSize=128m which is needed on my platform) they are 
 reverted back to default value after you successfully the server.
 What is worse they are not applied to the server that has just started.
 Steps to reproduce:
 1. Change VM arguments
 2. Start the server
 3. Wait for the start of the server
 4. Check the VM arguments
 5. They are reverted back to default one

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

[jira] Updated: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default

2007-11-28 Thread Sangjin Lee (JIRA)


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

Sangjin Lee updated GERONIMO-3638:
--

Attachment: patch.zip

A suggested fix.  It appears the charset variable in HttpMessage is unused, and 
it seems to be intended for the content charset.  The only place this charset 
is used is when we URL encode the form/query.


 should allow URL encoding with custom encoding charset other than the default
 -

 Key: GERONIMO-3638
 URL: https://issues.apache.org/jira/browse/GERONIMO-3638
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
 Attachments: patch.zip


 Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
 query string.  However, applications may want to use a different encoding 
 than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
 specify an encoding that AHC should use to encode the query string.

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

[jira] Closed: (GERONIMO-3644) Adding a second TomcatContainer is resulting in IllegalArgumentException


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

Vamsavardhana Reddy closed GERONIMO-3644.
-

Resolution: Fixed

Completed: At revision: 599076  
 o Made the defaultContext use a name instead of ''.

 Adding a second TomcatContainer is resulting in IllegalArgumentException
 

 Key: GERONIMO-3644
 URL: https://issues.apache.org/jira/browse/GERONIMO-3644
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Tomcat
Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 I have added a second TomcatContainer gbean to config.xml using the following 
 xml:
 gbean gbeanInfo=org.apache.geronimo.tomcat.TomcatContainer 
 name=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer
 attribute name=catalinaHomevar/catalina/attribute
 reference name=EngineGBean
 patternnameTomcatEngine/name/pattern
 /reference
 reference name=ServerInfo
 patternnameServerInfo/name/pattern
 /reference
 reference name=WebManager
 patternnameTomcatWebManager/name/pattern
 /reference
 /gbean
 Upon starting the server, I am getting an IllegalArgumentException.  
 Exception is occurring since no name is set for defaultContext created around 
 line 221 in TomcatContainer.java it is using a name which is an empty string. 
  StackTrace is given below.
 21:51:11,359 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
 the FAILED state: 
 abstractName=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/tomcat6/2.0.3-SNAPSHOT/car,j2eeType=GBean,name=MyTomcatWebContainer
 java.lang.IllegalArgumentException: addChild:  Child name '' is not unique
   at 
 org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:781)
   at 
 org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
   at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
   at 
 org.apache.geronimo.tomcat.TomcatContainer.doStart(TomcatContainer.java:232)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:996)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:539)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
   at 
 org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
   at 
 org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
   at 
 org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:553)
   at

[BUILD] 2.1: Failed for Revision: 599124

2007-11-28 Thread prasad

OpenEJB trunk at 599096
Geronimo Revision: 599124 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/~prasad/binaries/trunk/20071128/build-1500.log
 
[INFO] Installing 
/home/prasad/geronimo/trunk/framework/modules/geronimo-cli/target/geronimo-cli-2.1-SNAPSHOT.jar
 to 
/home/prasad/.m2/repository/org/apache/geronimo/modules/geronimo-cli/2.1-SNAPSHOT/geronimo-cli-2.1-SNAPSHOT.jar
[INFO] 

[INFO] Building Geronimo Modules :: System
[INFO]task-segment: [install]
[INFO] 

[INFO] artifact org.codehaus.mojo:jaxb2-maven-plugin: checking for updates from 
central
Downloading: 
http://repo1.maven.org/maven2/org/codehaus/mojo/jaxb2-maven-plugin/1.2/jaxb2-maven-plugin-1.2.pom
2K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo/11/mojo-11.pom
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to resolve artifact.

GroupId: org.codehaus.mojo
ArtifactId: mojo
Version: 11

Reason: Unable to download the artifact from any repository

  org.codehaus.mojo:mojo:pom:11

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org)


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error resolving version 
for 'org.codehaus.mojo:jaxb2-maven-plugin': Unable to read the metadata file 
for artifact 'org.codehaus.mojo:jaxb2-maven-plugin:pom': Cannot find parent: 
org.codehaus.mojo:mojo for project: null:jaxb2-maven-plugin:maven-plugin:1.2 
for project null:jaxb2-maven-plugin:maven-plugin:1.2
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1266)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindPluginToLifecycle(DefaultLifecycleExecutor.java:1221)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:987)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.version.PluginVersionResolutionException: 
Error resolving version for 'org.codehaus.mojo:jaxb2-maven-plugin': Unable to 
read the metadata file for artifact 'org.codehaus.mojo:jaxb2-maven-plugin:pom': 
Cannot find parent: org.codehaus.mojo:mojo for project: 
null:jaxb2-maven-plugin:maven-plugin:1.2 for project 
null:jaxb2-maven-plugin:maven-plugin:1.2
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolveMetaVersion(DefaultPluginVersionManager.java:681)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:186)
at 
org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:90)
at 
org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:166)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1257)
... 17 more
Caused by: 
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable 
to read the metadata file for artifact 
'org.codehaus.mojo:jaxb2-maven-plugin:pom': Cannot find parent: 
org.codehaus.mojo:mojo for project: null:jaxb2-maven-plugin:maven-plugin:1.2 
for project null:jaxb2-maven

[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default

2007-11-28 Thread Jay D. McHugh (JIRA)


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

Jay D. McHugh commented on GERONIMO-3638:
-

Content can be in any character set, but I am pretty sure that you are only 
allowed to use a portion of the 8859 character set in URLs.

snippet from RFC1738
Thus, only alphanumerics, the special characters $-_.+!*'(),, and reserved 
characters used for their reserved  purposes may be used unencoded within a URL.
/snippet

Since this is an HTTP client, shouldn't it be limited to the characters allowed 
by the URL spec?

 should allow URL encoding with custom encoding charset other than the default
 -

 Key: GERONIMO-3638
 URL: https://issues.apache.org/jira/browse/GERONIMO-3638
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
 Attachments: patch.zip


 Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
 query string.  However, applications may want to use a different encoding 
 than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
 specify an encoding that AHC should use to encode the query string.

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

[jira] Commented: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule

2007-11-28 Thread David Jencks (JIRA)

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

David Jencks commented on GERONIMO-3641:

ConfiguredIdentityNamedUsernamePasswordLoginModule is pretty much essential for
the TCK. You use it in case you want to supply credentials for the server when
its calling another server, e.g. a remote web service and you are relying on
the server credentials rather than the user credentials. You can get a similar
effect with a run-as where the run-as subject has been set up with
NamedUPCredentialLoginModule but using
ConfiguredIdentityNamedUsernamePasswordLoginModule means you can avoid the
run-as.

NamedUPCredentialLoginModule vs
ConfiguredIdentityNamedUsernamePasswordLoginModule
--

Key: GERONIMO-3641
URL: https://issues.apache.org/jira/browse/GERONIMO-3641
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Fix For: 2.0.x, 2.1

I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and
NamedUPCredentialLoginModule are added to geronimo codebase around the same
time (rev 159325 and rev 159560). The difference between the two is that
NamedUPCredentialLoginModule uses the user supplied username and password
where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the username
and password from options supplied to the login module.
NamedUPCredentialLoginModule is used by the Security realms portlet whereas
there are no references to ConfiguredIdentityNamedUsernamePasswordLoginModule
in the codebase. I guess one of them (most likely
ConfiguredIdentityNamedUsernamePasswordLoginModule) is redundant and it
should be eliminated. What am I missing?

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

Re: [jira] Commented: (GERONIMO-3641) NamedUPCredentialLoginModule vs ConfiguredIdentityNamedUsernamePasswordLoginModule

2007-11-28 Thread Vamsavardhana Reddy

Thanks for the clarification David.

++Vamsi

On Nov 29, 2007 2:05 AM, David Jencks (JIRA) [EMAIL PROTECTED] wrote:

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

David Jencks commented on GERONIMO-3641:

ConfiguredIdentityNamedUsernamePasswordLoginModule is pretty much
essential for the TCK. You use it in case you want to supply credentials
for the server when its calling another server, e.g. a remote web service
and you are relying on the server credentials rather than the user
credentials. You can get a similar effect with a run-as where the run-as
subject has been set up with NamedUPCredentialLoginModule but using
ConfiguredIdentityNamedUsernamePasswordLoginModule means you can avoid the
run-as.

NamedUPCredentialLoginModule vs
ConfiguredIdentityNamedUsernamePasswordLoginModule

I see that ConfiguredIdentityNamedUsernamePasswordLoginModule and
NamedUPCredentialLoginModule are added to geronimo codebase around the same
time (rev 159325 and rev 159560). The difference between the two is that
NamedUPCredentialLoginModule uses the user supplied username and password
where as ConfiguredIdentityNamedUsernamePasswordLoginModule gets the
username and password from options supplied to the login module.
NamedUPCredentialLoginModule is used by the Security realms portlet whereas
there are no references to
ConfiguredIdentityNamedUsernamePasswordLoginModule in the codebase. I guess
one of them (most likely ConfiguredIdentityNamedUsernamePasswordLoginModule)
is redundant and it should be eliminated. What am I missing?

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

[jira] Commented: (GERONIMO-3640) Eliminate UPCredentialLoginModule

2007-11-28 Thread David Jencks (JIRA)


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

David Jencks commented on GERONIMO-3640:


OK.  It might be a good idea to move NamedUPCredentialLoginModule to 
o.a.g.s.realm.providers as long as we are breaking backward compatibility 
anyway.

 Eliminate UPCredentialLoginModule
 -

 Key: GERONIMO-3640
 URL: https://issues.apache.org/jira/browse/GERONIMO-3640
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 2.0.x, 2.1
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy
 Fix For: 2.0.x, 2.1


 UPCredentialLoginModule seems to serve the same purpose as 
 GeronimoPasswordCredentialLoginModule.  Searching the codebase for references 
 to UPCredentialLoginModule yields no results. Also 
 GeronimoPasswordCredentialLoginModule is the one used by Security realms 
 portlet.  It may be a good idea to eliminate UPCredentialLoginModule and 
 related classes.

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

[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default

2007-11-28 Thread Sangjin Lee (JIRA)


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

Sangjin Lee commented on GERONIMO-3638:
---

Hmm, I swear I remember seeing the RFCs (2616 and 2396 which supplants 1738) 
mention different *URL* encoding than us-ascii (e.g. utf-8), but I cannot find 
it at the moment...

At minimum, shouldn't we use ISO-8859-1 or US-ASCII explicitly instead of 
using Charset.defaultCharset()?  If the JVM is running on a non-US box, 
Charset.defaultCharset() would return a different charset than ascii, no?  
Thanks.

 should allow URL encoding with custom encoding charset other than the default
 -

 Key: GERONIMO-3638
 URL: https://issues.apache.org/jira/browse/GERONIMO-3638
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
 Attachments: patch.zip


 Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
 query string.  However, applications may want to use a different encoding 
 than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
 specify an encoding that AHC should use to encode the query string.

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

[jira] Created: (GERONIMO-3645) Monitoring plugins build fails

Monitoring plugins build fails
--

 Key: GERONIMO-3645
 URL: https://issues.apache.org/jira/browse/GERONIMO-3645
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: monitoring
Reporter: Erik B. Craig
Assignee: Erik B. Craig


Monitoring plugins build fails when there is a clean (empty) local maven 
repository due to lack of the artifacts
org.apache.geronimo.modules:modules and
org.apache.geronimo.configs:configs

Need to sift through poms and clean up to prevent this

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

[jira] Commented: (GERONIMO-3638) should allow URL encoding with custom encoding charset other than the default

2007-11-28 Thread Jay D. McHugh (JIRA)


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

Jay D. McHugh commented on GERONIMO-3638:
-

RFC 2396 seems to say the same character set (a portion of latin with numerics 
and some special characters).

As far as whether we should be using the Charset.defaultCharset() - You may be 
right.

Maybe we should be either using US-ASCII or ISO-8859-1 explicitly rather than 
letting the JVM pick which one we use.

Anyone else have a comment or suggestion?

 should allow URL encoding with custom encoding charset other than the default
 -

 Key: GERONIMO-3638
 URL: https://issues.apache.org/jira/browse/GERONIMO-3638
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: AsyncHttpClient
Affects Versions: 1.x
Reporter: Sangjin Lee
 Attachments: patch.zip


 Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
 query string.  However, applications may want to use a different encoding 
 than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
 specify an encoding that AHC should use to encode the query string.

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

[jira] Created: (GERONIMO-3646) monitoring client does not update the last_seen attribute

monitoring client does not update the last_seen attribute
---

 Key: GERONIMO-3646
 URL: https://issues.apache.org/jira/browse/GERONIMO-3646
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3646.patch

The monitoring client needs to update the last_seen attribute for the Graphs 
and the Servers. Additionally, there are several places where connections are 
intricately intertwined. These connections should be sorted out as well to 
prevent future bugs.

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

[jira] Updated: (GERONIMO-3646) monitoring client does not update the last_seen attribute


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

Viet Hung Nguyen updated GERONIMO-3646:
---

Attachment: geronimo-3646.patch

 monitoring client does not update the last_seen attribute
 ---

 Key: GERONIMO-3646
 URL: https://issues.apache.org/jira/browse/GERONIMO-3646
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3646.patch


 The monitoring client needs to update the last_seen attribute for the Graphs 
 and the Servers. Additionally, there are several places where connections are 
 intricately intertwined. These connections should be sorted out as well to 
 prevent future bugs.

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

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


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

Jason Warner commented on GSHELL-20:


I do indeed realize that this is just a bandaid.  If we can get the parser to 
handle this all without the post-processing, that would be fantastic.  I don't 
know anywhere near enough about JavaCC to accomplish that myself, though.  I 
thought that, given the hopes and dreams of a gshell release, it would be 
better to have something than nothing in regards to this jira.  

 `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: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Dillon commented on GSHELL-20:


Yup and that is the right thing to do :-)  Hopefully I can get a release ready 
in the next week, or ready to vote at least.

Anyways, no worries, was not meaning to be critical to you, just was babbling 
about things as usual.  I appreciate your help for sure :-)

 `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] Created: (GERONIMO-3647) Monitoring client should use icons for action links

Monitoring client should use icons for action links
---

 Key: GERONIMO-3647
 URL: https://issues.apache.org/jira/browse/GERONIMO-3647
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: monitoring
Reporter: Erik B. Craig
Assignee: Erik B. Craig


Currently the monitoring client uses various ascii characters for some of the 
action links (~ for edit, + for add/maximize, _ for minimize, X for close,  
for back). These should be replaced with some small icons to make things easier 
on the eyes

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

[jira] Resolved: (GERONIMO-3646) monitoring client does not update the last_seen attribute


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

Viet Hung Nguyen resolved GERONIMO-3646.


Resolution: Fixed

 monitoring client does not update the last_seen attribute
 ---

 Key: GERONIMO-3646
 URL: https://issues.apache.org/jira/browse/GERONIMO-3646
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3646.patch


 The monitoring client needs to update the last_seen attribute for the Graphs 
 and the Servers. Additionally, there are several places where connections are 
 intricately intertwined. These connections should be sorted out as well to 
 prevent future bugs.

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

[jira] Commented: (GERONIMO-3646) monitoring client does not update the last_seen attribute


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

Erik B. Craig commented on GERONIMO-3646:
-

Committed revision 599235
Thanks Viet

 monitoring client does not update the last_seen attribute
 ---

 Key: GERONIMO-3646
 URL: https://issues.apache.org/jira/browse/GERONIMO-3646
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Attachments: geronimo-3646.patch


 The monitoring client needs to update the last_seen attribute for the Graphs 
 and the Servers. Additionally, there are several places where connections are 
 intricately intertwined. These connections should be sorted out as well to 
 prevent future bugs.

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

[jira] Resolved: (GERONIMO-3643) monitoring plugin should also package both client and server into one deployable


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

Viet Hung Nguyen resolved GERONIMO-3643.


   Resolution: Fixed
Fix Version/s: 2.1

 monitoring plugin should also package both client and server into one 
 deployable
 

 Key: GERONIMO-3643
 URL: https://issues.apache.org/jira/browse/GERONIMO-3643
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.1
 Environment: windows
Reporter: Viet Hung Nguyen
Assignee: Viet Hung Nguyen
 Fix For: 2.1

 Attachments: geronimo-3643.patch


 Monitoring plugin should have a Client Plugin, a Server Plugin, and also 
 a Client + Server Plugin (in case anyone wants to monitor the local 
 machine).

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

[jira] Created: (GSHELL-83) Upgrade to plexus-cdc-anno 1.0-alpha-1

Upgrade to plexus-cdc-anno 1.0-alpha-1
--

 Key: GSHELL-83
 URL: https://issues.apache.org/jira/browse/GSHELL-83
 Project: GShell
  Issue Type: Sub-task
  Security Level: public (Regular issues)
  Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-1




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

Administering geronimo remotely

2007-11-28 Thread Anita Kulshreshtha

   I am trying to administer a geronimo instance remotely using admin
console. I can install jars to remote g instance using Repository
link, i.e. the jar files from local file system get installed in remote
g repo as expected. I tried a car and was able to install it too! This
car (a J2EE Connector) showed up in stopped state, so I started it
(using 'start' link on remote console). This caused a lifecycle
operation failed ...
org.apache.geronimo.kernel.config.NoSuchConfigException: error. Is
this the expected behavior?
   if I select the local .m2 repo as plugin repository in plugins
portlet, should I expect the selected plugin to be installed at the
remote instance using jars/cars from the local files system?

Thanks
Anita
 


  

Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

[jira] Closed: (GSHELL-79) Upgrade plexus-maven-plugin to 1.3.6


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

Jason Dillon closed GSHELL-79.
--

Resolution: Fixed

 Upgrade plexus-maven-plugin to 1.3.6
 

 Key: GSHELL-79
 URL: https://issues.apache.org/jira/browse/GSHELL-79
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Blocker
 Fix For: 1.0-alpha-1


 This is required for java5 anno-based descriptor generation.

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

[jira] Commented: (GSHELL-83) Upgrade to plexus-cdc-anno 1.0-alpha-1


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

Jason Dillon commented on GSHELL-83:


Also need a release of plexus-component-annotations

 Upgrade to plexus-cdc-anno 1.0-alpha-1
 --

 Key: GSHELL-83
 URL: https://issues.apache.org/jira/browse/GSHELL-83
 Project: GShell
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
  Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-1




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

[jira] Resolved: (GERONIMO-3647) Monitoring client should use icons for action links


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

Erik B. Craig resolved GERONIMO-3647.
-

Resolution: Fixed

Committed revision 599251
Done.

 Monitoring client should use icons for action links
 ---

 Key: GERONIMO-3647
 URL: https://issues.apache.org/jira/browse/GERONIMO-3647
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: monitoring
Reporter: Erik B. Craig
Assignee: Erik B. Craig

 Currently the monitoring client uses various ascii characters for some of the 
 action links (~ for edit, + for add/maximize, _ for minimize, X for close,  
 for back). These should be replaced with some small icons to make things 
 easier on the eyes

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

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


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

Jason Dillon commented on GSHELL-20:


This seems to work okay for:

{noformat}
set foo=bar
{noformat}

As it sets {{foo}} to {{bar}}, but this does not work:

{noformat}
set foo='bar'
{noformat}

It sets {{foo}} to _empty_ and {{bar}} to {{true}}... :-(

 `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: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Warner commented on GSHELL-20:


That is actually somewhat expected behavior.  I didn't realize that single
quotes should be parsed the same as double quotes.  Should double and single
quotes be working in the same manner?  I was working on the jira in a
literal sense.  Was there more outside of what was described that was in the
scope of the jira?




 `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: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Warner commented on GSHELL-20:


That is actually somewhat expected behavior.  I didn't realize that single 
quotes should be parsed the same as double quotes.  Should double and single 
quotes be working in the same manner?  I was working on the jira in a literal 
sense.  Was there more outside of what was described that was in the scope of 
the jira?

 `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: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Dillon commented on GSHELL-20:


Yes and no ;-)  The expansion of  strings happens internally with a wee 
bandaid using jexl in the executing visitor.  So by the time it gets to the 
command  and '' are basically the same.  And really there should be no quotes 
on anything anymore at this point.

Basically, it should work like BASH does eventually... one day... ;-)

Anyways, this is not a big deal, there are larger fish to fry feel like 
cooking?

 `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] Updated: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Warner updated GSHELL-20:
---

Attachment: GShell-20SingleQuote.patch

Well, I was done and testing this patch before I got your response.  It's a 
simple change that pretty much just mimics the change for the double quotes.  
But yes, I do feel like cooking.  I make an excellent omelette. 

 `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, GShell-20SingleQuote.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: (GSHELL-20) `set foo=bar` does not work as expected


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

Jason Dillon commented on GSHELL-20:


I spent some time today and worked more on a POC using Antlr3 to implement a 
BASH grammar... still need some work, and well, I think I'll probably end up 
using JavaCC, unless I suddenly gain +10 comprehension of Antlr3 and succumb to 
the byte cost of the additional jars... dunno yet.

I think the next release will probably see a brand new parser (maybe crippled) 
but abale to parse BASH-ish syntax

 `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, GShell-20SingleQuote.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: (GSHELL-80) Upgrade maven-remote-resources-plugin to 1.0-alpha-7