[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674612#action_12674612
]
Jason Warner commented on GERONIMO-3759:
Your config.xml is missing the module entry for mconsole-ds. I'm not sure why
this is. There could be a number of reasons. I suggest you start with a fresh
server and copy only the changes necessary from any external config.xml. For
example, start with the default config.xml and copy over only the necessary
clustering config from the attached config_ag21.xml. I'm not sure how you lost
the mconsole-ds module since it seems to be present both in the config_ag21.xml
as well as the default config.xml that my server build starts with. For
clarification, I ran this on Geronimo Tomcat Java EE 5 2.1.3. If you have any
further trouble with this, please post questions to the user list with a
reference to this jira. I don't believe the comment section of a long closed
jira is the best place for discussing bugs that aren't really related to the
changes made in relation to that jira.
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch, config.xml,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671994#action_12671994
]
Jason Warner commented on GERONIMO-3759:
If you're still having trouble with this, please post the config.xml that you
are using. I just attempted to start the server using the configuration
provided here and had no issues.
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670895#action_12670895
]
Jason Warner commented on GERONIMO-3759:
I'm not sure what specifically the error you receive has to do with this jira
other than that you're using the config.xml posted here, which also confuses
me. What are you attempting to do?
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3
Upgrade to shitty-maven-plugin 1.0-alpha-3 -- Key: GERONIMO-4453 URL: https://issues.apache.org/jira/browse/GERONIMO-4453 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: dependencies Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 There's a bug[1] in version 1.0-alpha-2 of the shitty-maven-plugin that causes tests to fail when run through anthill pro. This bug seems to have been fixed in 1.0-alpha-3. [1] No such property: loh for class: org.codehaus.mojo.shitty.TestBuild -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4453) Upgrade to shitty-maven-plugin 1.0-alpha-3
[ https://issues.apache.org/jira/browse/GERONIMO-4453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-4453. Resolution: Fixed revision 724797 in trunk Upgrade to shitty-maven-plugin 1.0-alpha-3 -- Key: GERONIMO-4453 URL: https://issues.apache.org/jira/browse/GERONIMO-4453 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: dependencies Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 There's a bug[1] in version 1.0-alpha-2 of the shitty-maven-plugin that causes tests to fail when run through anthill pro. This bug seems to have been fixed in 1.0-alpha-3. [1] No such property: loh for class: org.codehaus.mojo.shitty.TestBuild -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12639554#action_12639554 ] Jason Warner commented on GERONIMO-4335: Discussion on this change can be found here: http://www.nabble.com/An-idea-for-defining-custom-valves-in-config.xml-td19804490s134.html Implement the ability to define a custom valve in config.xml Key: GERONIMO-4335 URL: https://issues.apache.org/jira/browse/GERONIMO-4335 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner There currently is no good way to define a custom valve in config.xml. There are a couple of work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
Implement the ability to define a custom valve in config.xml Key: GERONIMO-4335 URL: https://issues.apache.org/jira/browse/GERONIMO-4335 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner There currently is no good way to define a custom valve in config.xml. There a couple work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4335) Implement the ability to define a custom valve in config.xml
[ https://issues.apache.org/jira/browse/GERONIMO-4335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4335: --- Description: There currently is no good way to define a custom valve in config.xml. There are a couple of work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 was: There currently is no good way to define a custom valve in config.xml. There a couple work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 Implement the ability to define a custom valve in config.xml Key: GERONIMO-4335 URL: https://issues.apache.org/jira/browse/GERONIMO-4335 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner There currently is no good way to define a custom valve in config.xml. There are a couple of work arounds [1][2] that will result in the desired functionality, but i believe there should be a simpler and more intuitive way to accomplish this goal. [1] https://issues.apache.org/jira/browse/GERONIMO-4113 [2] http://www.nabble.com/Problem-with-defining-custom-Valve-in-config.xml-td12794364.html#a12794364 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3468) Links broken through Ajp13.
[ https://issues.apache.org/jira/browse/GERONIMO-3468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-3468. -- Resolution: Fixed Fix Version/s: 2.0.2 Assignee: Jason Warner (was: Joseph Leong) This seems to have been fixed in 2.0.2 Links broken through Ajp13. --- Key: GERONIMO-3468 URL: https://issues.apache.org/jira/browse/GERONIMO-3468 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.0.1 Environment: Linux 2.6.21-gentoo-r4 #1 SMP Wed Jul 25 22:03:40 EDT 2007 i686 Pentium III (Katmai) GenuineIntel GNU/Linux apache-2.2.6 mod_jk-1.2.23 sun-jdk-1.5.0.12 Reporter: Aleksandr Tarutin Assignee: Jason Warner Fix For: 2.0.2 When running behind apache through the Ajp13 connector the 'edit' and 'usage' links on the 'Database Pools' page in the console don't work and just return to the 'Database Pools' page. This happens in Geronimo with Jetty. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-58) Layout command aliases should be allowed to reference relative command paths for targets
[
https://issues.apache.org/jira/browse/GSHELL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner closed GSHELL-58.
--
Resolution: Won't Fix
Layout has been removed. This issue is no longer applicable
Layout command aliases should be allowed to reference relative command paths
for targets
Key: GSHELL-58
URL: https://issues.apache.org/jira/browse/GSHELL-58
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
For example:
{code}
...
group
nameremote/name
nodes
command
namersh/name
idgshell-remote:rsh/id
/command
command
namersh-server/name
idgshell-remote:rsh-server/id
/command
alias
namershd/name
commandrsh-server/command
/alias
/nodes
/group
/nodes
/layout
{code}
In this example, the {{remote/rshd}} command alias really wants to point to
{{remote/rsh-server}} but current alias target resolve works from the layout
root.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager
[ https://issues.apache.org/jira/browse/GSHELL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GSHELL-54. -- Resolution: Won't Fix Layout has been removed. This jira no longer seems applicable Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager - Key: GSHELL-54 URL: https://issues.apache.org/jira/browse/GSHELL-54 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4264: --- Fix Version/s: (was: 2.2) Enable static configuration of a wadi cluster - Key: GERONIMO-4264 URL: https://issues.apache.org/jira/browse/GERONIMO-4264 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Wadi has the capability to be statically configured, and this feature needs to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4264) Enable static configuration of a wadi cluster
Enable static configuration of a wadi cluster - Key: GERONIMO-4264 URL: https://issues.apache.org/jira/browse/GERONIMO-4264 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Wadi has the capability to be statically configured, and this feature needs to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-4264. Resolution: Fixed Fix Version/s: 2.2 committed in revision 689137 Enable static configuration of a wadi cluster - Key: GERONIMO-4264 URL: https://issues.apache.org/jira/browse/GERONIMO-4264 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Wadi has the capability to be statically configured, and this feature needs to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4264) Enable static configuration of a wadi cluster
[ https://issues.apache.org/jira/browse/GERONIMO-4264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4264. -- Enable static configuration of a wadi cluster - Key: GERONIMO-4264 URL: https://issues.apache.org/jira/browse/GERONIMO-4264 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Wadi has the capability to be statically configured, and this feature needs to be exposed through the geronimo wadi clustering support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT
Update to latest wadi 2.0-SNAPSHOT -- Key: GERONIMO-4244 URL: https://issues.apache.org/jira/browse/GERONIMO-4244 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4244) Update to latest wadi 2.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4244. -- Resolution: Fixed Fix Version/s: 2.2 committed in revision 686040 Update to latest wadi 2.0-SNAPSHOT -- Key: GERONIMO-4244 URL: https://issues.apache.org/jira/browse/GERONIMO-4244 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Fix For: 2.2 Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4244) Update to latest wadi 2.1-SNAPSHOT
[ https://issues.apache.org/jira/browse/GERONIMO-4244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-4244: --- Summary: Update to latest wadi 2.1-SNAPSHOT (was: Update to latest wadi 2.0-SNAPSHOT) updating to correct snapshot, committed in revision 686113 Update to latest wadi 2.1-SNAPSHOT -- Key: GERONIMO-4244 URL: https://issues.apache.org/jira/browse/GERONIMO-4244 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Fix For: 2.2 Updating to the latest wadi snapshot to pick up some new functionality. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4220) Tomcat Cluster Sender gbean should allow Transport element
[ https://issues.apache.org/jira/browse/GERONIMO-4220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4220. -- Resolution: Fixed Fix Version/s: 2.2 committed in trunk (rev. 682729) Tomcat Cluster Sender gbean should allow Transport element -- Key: GERONIMO-4220 URL: https://issues.apache.org/jira/browse/GERONIMO-4220 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Fix For: 2.2 In tomcat, the sender element can have a transport subelement that allows for more configuration options. The geronimo implementation of this clustering should be expanded to allow for the same options. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4220) Tomcat Cluster Sender gbean should allow Transport element
Tomcat Cluster Sender gbean should allow Transport element -- Key: GERONIMO-4220 URL: https://issues.apache.org/jira/browse/GERONIMO-4220 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.1.3, 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor In tomcat, the sender element can have a transport subelement that allows for more configuration options. The geronimo implementation of this clustering should be expanded to allow for the same options. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner closed GERONIMO-3759.
--
Resolution: Fixed
revision 680780 in trunk
revision 680793 in branches/2.1
Many thanks to Shiva for all the work done before.
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3759) Geronimo Tomcat Clustering - No GBeans for adding Static Members
[
https://issues.apache.org/jira/browse/GERONIMO-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-3759:
--
Assignee: Jason Warner
Geronimo Tomcat Clustering - No GBeans for adding Static Members
Key: GERONIMO-3759
URL: https://issues.apache.org/jira/browse/GERONIMO-3759
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Clustering
Affects Versions: 2.1, 2.1.1
Reporter: Shiva Kumar H R
Assignee: Jason Warner
Fix For: 2.1.3, 2.2
Attachments: ClusteringStaticMembers_GERONIMO-3759.patch,
config_ag21.xml, tomcat_server.xml
Tomcat uses multicasting for discovering cluster members. It also supports
static memberships using the StaticMembershipInterceptor if you want to
extend your membership to points beyond multicasting, using configuration as
below:
Interceptor
className=org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor
Member className=org.apache.catalina.tribes.membership.StaticMember
port=5678
securePort=-1
host=tomcat01.mydomain.com
domain=staging-cluster
uniqueId={0,1,2,3,4,5,6,7,8,9}/
/Interceptor
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
http://tomcat.apache.org/tomcat-6.0-doc/config/cluster-interceptor.html
However, to add this configuration in Geronimo's config.xml, we don't have
the required GBeans for Member element.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4193) Enable unicast configurations for tomcat clustering
[ https://issues.apache.org/jira/browse/GERONIMO-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4193. -- Resolution: Duplicate Fix Version/s: (was: 2.2) duplicate of https://issues.apache.org/jira/browse/GERONIMO-3759 Enable unicast configurations for tomcat clustering --- Key: GERONIMO-4193 URL: https://issues.apache.org/jira/browse/GERONIMO-4193 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner The tomcat clustering configurations should have the option to use unicast instead of multicast. To do this, the user must have the ability to define static members in an interceptor in the config.xml. The interceptor gbean currently does not allow for this type of configuration and must be changed accordingly. Also, the ability to disable multicasting must be exposed before a unicast configuration can be implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4193) Enable unicast configurations for tomcat clustering
[ https://issues.apache.org/jira/browse/GERONIMO-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617506#action_12617506 ] Jason Warner commented on GERONIMO-4193: Thanks for the info Shiva. I don't believe the work was in vain at all. I'll reassign the older jira to myself and close this one as a duplicate. Enable unicast configurations for tomcat clustering --- Key: GERONIMO-4193 URL: https://issues.apache.org/jira/browse/GERONIMO-4193 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner The tomcat clustering configurations should have the option to use unicast instead of multicast. To do this, the user must have the ability to define static members in an interceptor in the config.xml. The interceptor gbean currently does not allow for this type of configuration and must be changed accordingly. Also, the ability to disable multicasting must be exposed before a unicast configuration can be implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4187) setManagerClassName has been deprecated for the SimpleTCPCluster class in Tomcat Clustering
[ https://issues.apache.org/jira/browse/GERONIMO-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-4187. Resolution: Fixed fix committed to trunk in revision 677382 setManagerClassName has been deprecated for the SimpleTCPCluster class in Tomcat Clustering --- Key: GERONIMO-4187 URL: https://issues.apache.org/jira/browse/GERONIMO-4187 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Currently when configuring tomcat clustering in geronimo, the manager class name for the cluster is passed through as an init parameter and is set using the setManagerClassName method. This method has been deprecated in Tomcat 6 and an alternate method of setting the manager has been introduced. The manager can now be set as a subelement of the cluster element in the configuration. Geronimo should switch to this new method of configuring a manager so that we're better poised to maintain compatibility with future tomcat releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4193) Enable unicast configurations for tomcat clustering
Enable unicast configurations for tomcat clustering --- Key: GERONIMO-4193 URL: https://issues.apache.org/jira/browse/GERONIMO-4193 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 The tomcat clustering configurations should have the option to use unicast instead of multicast. To do this, the user must have the ability to define static members in an interceptor in the config.xml. The interceptor gbean currently does not allow for this type of configuration and must be changed accordingly. Also, the ability to disable multicasting must be exposed before a unicast configuration can be implemented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4187) setManagerClassName has been deprecated for the SimpleTCPCluster class in Tomcat Clustering
setManagerClassName has been deprecated for the SimpleTCPCluster class in Tomcat Clustering --- Key: GERONIMO-4187 URL: https://issues.apache.org/jira/browse/GERONIMO-4187 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Clustering Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.2 Currently when configuring tomcat clustering in geronimo, the manager class name for the cluster is passed through as an init parameter and is set using the setManagerClassName method. This method has been deprecated in Tomcat 6 and an alternate method of setting the manager has been introduced. The manager can now be set as a subelement of the cluster element in the configuration. Geronimo should switch to this new method of configuring a manager so that we're better poised to maintain compatibility with future tomcat releases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4181) Upgrade derby to 10.4.1.3
Upgrade derby to 10.4.1.3 - Key: GERONIMO-4181 URL: https://issues.apache.org/jira/browse/GERONIMO-4181 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: databases Reporter: Jason Warner Fix For: 2.2 Our current version of derby is over 2 years old. Upgrading to the 10.4.1.3 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4181) Upgrade derby to 10.4.1.3
[ https://issues.apache.org/jira/browse/GERONIMO-4181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609975#action_12609975 ] Jason Warner commented on GERONIMO-4181: revision 673443 in trunk Upgrade derby to 10.4.1.3 - Key: GERONIMO-4181 URL: https://issues.apache.org/jira/browse/GERONIMO-4181 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: databases Reporter: Jason Warner Fix For: 2.2 Our current version of derby is over 2 years old. Upgrading to the 10.4.1.3 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4177) FarmWarDeployerGBean.java uses incorrect hardcoded tomcat class
[ https://issues.apache.org/jira/browse/GERONIMO-4177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4177. -- Resolution: Fixed 673138 in branches/2.1 673140 in trunk FarmWarDeployerGBean.java uses incorrect hardcoded tomcat class --- Key: GERONIMO-4177 URL: https://issues.apache.org/jira/browse/GERONIMO-4177 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.x, 2.2 FarmWarDeployerGBean.java uses a hardcoded tomcat class. This class was was refactored in Tomcat 6.0.X. The class needs to be updated to use the correct class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4177) FarmWarDeployerGBean.java uses incorrect hardcoded tomcat class
FarmWarDeployerGBean.java uses incorrect hardcoded tomcat class --- Key: GERONIMO-4177 URL: https://issues.apache.org/jira/browse/GERONIMO-4177 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.x, 2.2 FarmWarDeployerGBean.java uses a hardcoded tomcat class. This class was was refactored in Tomcat 6.0.X. The class needs to be updated to use the correct class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-117) GShell doesn't support \ in the path in Widnows platform
[
https://issues.apache.org/jira/browse/GSHELL-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12606412#action_12606412
]
Jason Warner commented on GSHELL-117:
-
I'm not sure if that would work or not. The error occurs during parsing of the
command line, which occurs before gshell attempts to determine what the command
is or what arguments are present. Any character replacement would have to be
done blindly, without any knowledge of context. I'm not familiar enough with
all the use cases of gshell to accurately predict whether this could cause
failures in certain situations or not. Alternatively, we could have a check
for the specific commands in which a file name could be provided and have
preparsing done before the command reaches the parser on just those commands.
That seems like a really large hack, though, and is really not a solution in my
mind, although it's probably the easiest solution to implement that has the
least chance of breaking other commands. I'm having trouble coming up with a
fix that I'd personally be comfortable with short of figuring out just what the
parser hates so much about '\' and teaching it how to play nice. I'm not
familiar enough with the parser to estimate how difficult that would be. Maybe
someone who is more familiar with the parser or gshell as a whole could comment
on that, or anything else I just said for that matter.
GShell doesn't support \ in the path in Widnows platform
--
Key: GSHELL-117
URL: https://issues.apache.org/jira/browse/GSHELL-117
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: CLI
Affects Versions: 1.0-alpha-1, 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Dillon
Fix For: 1.0-alpha-3
Run the following command and get errors in Windows
{noformat}
deploy/deploy H:\FTP_ROOT\Build\cviewer.war
ERROR TokenMgrError: Lexical error at line 1, column 18. Encountered: F
(70), after : \\
{noformat}
It works fine for double slash:
deploy/deploy H:\\FTP_ROOT\\Build\\cviewer.war
It's not convenience for windows users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4106) Gshell - unable to deploy modules with absolute path on windows
[ https://issues.apache.org/jira/browse/GERONIMO-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4106. -- Resolution: Duplicate Duplicate of https://issues.apache.org/jira/browse/GSHELL-117 Gshell - unable to deploy modules with absolute path on windows --- Key: GERONIMO-4106 URL: https://issues.apache.org/jira/browse/GERONIMO-4106 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.1 Environment: winxp + sun jdk 1.5 14 Reporter: Lin Sun Using gshell to deploy a war file with its absolute path resulting the failure below - [EMAIL PROTECTED]:/ deploy/deploy C:\working\server\branches\samples\applications\jaxws-calculator\target\jaxws-calculator-axis2-2.1.0.0.war ERROR TokenMgrError: Lexical error at line 1, column 18. Encountered: w (119), after : \\ Workaround is to copy the war file to current dir so I don't have to specify a path: [EMAIL PROTECTED]:/ deploy/deploy jaxws-calculator-axis2-2.1.0.0.war Connecting to Geronimo server: localhost:1099 Username: system Password: *** Connection established Deployed org.apache.geronimo.samples.jws/Calculator/1.0/car @ /jaxws-calculator-1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4106) Gshell - unable to deploy modules with absolute path on windows
[ https://issues.apache.org/jira/browse/GERONIMO-4106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604021#action_12604021 ] Jason Warner commented on GERONIMO-4106: An alternate workaround would be to use a forward slash instead of a back slash in the path (C:/working/server/branches/samples/applications/jaxws-calculator/target/jaxws-calculator-axis2-2.1.0.0.war). The issue comes from the parser in gshell not being able to handle a back slash and not from the commands themselves. This issue is a duplicate of https://issues.apache.org/jira/browse/GSHELL-117 . According to this issue, a double backslash (C:\\working\\...) can be used as well. Gshell - unable to deploy modules with absolute path on windows --- Key: GERONIMO-4106 URL: https://issues.apache.org/jira/browse/GERONIMO-4106 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.1 Environment: winxp + sun jdk 1.5 14 Reporter: Lin Sun Using gshell to deploy a war file with its absolute path resulting the failure below - [EMAIL PROTECTED]:/ deploy/deploy C:\working\server\branches\samples\applications\jaxws-calculator\target\jaxws-calculator-axis2-2.1.0.0.war ERROR TokenMgrError: Lexical error at line 1, column 18. Encountered: w (119), after : \\ Workaround is to copy the war file to current dir so I don't have to specify a path: [EMAIL PROTECTED]:/ deploy/deploy jaxws-calculator-axis2-2.1.0.0.war Connecting to Geronimo server: localhost:1099 Username: system Password: *** Connection established Deployed org.apache.geronimo.samples.jws/Calculator/1.0/car @ /jaxws-calculator-1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-117) GShell doesn't support \ in the path in Widnows platform
[
https://issues.apache.org/jira/browse/GSHELL-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12604022#action_12604022
]
Jason Warner commented on GSHELL-117:
-
I looked at this issue briefly for Geronimo-4106 before I noticed this issue.
I checked the use of both single and double quotes and noted that neither
resolved the issue. Forward slashes can be used instead of backslashes to get
this to work properly.
GShell doesn't support \ in the path in Widnows platform
--
Key: GSHELL-117
URL: https://issues.apache.org/jira/browse/GSHELL-117
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: CLI
Affects Versions: 1.0-alpha-1, 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Dillon
Fix For: 1.0-alpha-3
Run the following command and get errors in Windows
{noformat}
deploy/deploy H:\FTP_ROOT\Build\cviewer.war
ERROR TokenMgrError: Lexical error at line 1, column 18. Encountered: F
(70), after : \\
{noformat}
It works fine for double slash:
deploy/deploy H:\\FTP_ROOT\\Build\\cviewer.war
It's not convenience for windows users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GERONIMO-4036:
---
Fix Version/s: 2.2
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2, 2.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner resolved GERONIMO-4036.
Resolution: Fixed
rev. 664148 in branches/2.1
rev. 664243 in trunk
Many thanks to Jarek for his incredibly helpful suggestions.
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2, 2.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602423#action_12602423
]
Jason Warner commented on GERONIMO-4036:
Jarek, I attempted your suggestion with the same results that YunFeng reported.
I thought I understood what was going on but now I'm not so sure. I'll have
to look into what's actually happening further
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-112) Can not evaluate a variable followed by a quotation mark
[
https://issues.apache.org/jira/browse/GSHELL-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner closed GSHELL-112.
---
Resolution: Fixed
most recent changes committed in 662780
Can not evaluate a variable followed by a quotation mark
Key: GSHELL-112
URL: https://issues.apache.org/jira/browse/GSHELL-112
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Parser
Affects Versions: 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Dillon
Priority: Minor
Fix For: 1.0-alpha-2
Run the following steps in gshell:
{noformat}
set username=system
set password=manager
set login=deploy/connect -u $username -w $password
{noformat}
get the following Error message:
{noformat}
[EMAIL PROTECTED]:/ set login=deploy/connect -u $username -w $password
ERROR SyntaxException: Failed to evaluate: password
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-112) Can not evaluate a variable followed by a quotation mark
[
https://issues.apache.org/jira/browse/GSHELL-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601918#action_12601918
]
Jason Warner commented on GSHELL-112:
-
Added in some checking for the usage of single quotes as well. I agree that
this should be handled in the parser first, but as discussed in irc, left this
change in as a quick hack fix until the parser stuff gets sorted out.
Can not evaluate a variable followed by a quotation mark
Key: GSHELL-112
URL: https://issues.apache.org/jira/browse/GSHELL-112
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Parser
Affects Versions: 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Dillon
Priority: Minor
Fix For: 1.0-alpha-2
Run the following steps in gshell:
{noformat}
set username=system
set password=manager
set login=deploy/connect -u $username -w $password
{noformat}
get the following Error message:
{noformat}
[EMAIL PROTECTED]:/ set login=deploy/connect -u $username -w $password
ERROR SyntaxException: Failed to evaluate: password
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-112) Can not evaluate a variable followed by a quotation mark
[
https://issues.apache.org/jira/browse/GSHELL-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner closed GSHELL-112.
---
Resolution: Fixed
committed in revision 662552
Can not evaluate a variable followed by a quotation mark
Key: GSHELL-112
URL: https://issues.apache.org/jira/browse/GSHELL-112
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Parser
Affects Versions: 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Run the following steps in gshell:
{noformat}
set username=system
set password=manager
set login=deploy/connect -u $username -w $password
{noformat}
get the following Error message:
{noformat}
[EMAIL PROTECTED]:/ set login=deploy/connect -u $username -w $password
ERROR SyntaxException: Failed to evaluate: password
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12601191#action_12601191
]
Jason Warner commented on GERONIMO-4036:
The warning's are a result of the connection to the server being closed when
the server succesfully shut's down. There's no way to avoid it that I know of.
I'm not sure if there's a way to hide those warning messages. Is anyone aware
of how to do that?
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4079) redeploy should support inPlace deployment
[
https://issues.apache.org/jira/browse/GERONIMO-4079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-4079:
--
Assignee: Jason Warner
redeploy should support inPlace deployment
--
Key: GERONIMO-4079
URL: https://issues.apache.org/jira/browse/GERONIMO-4079
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.2
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 2.2
redeploy should support inPlace deployment like deploy, such as:
{noformat}
deploy.bat/sh redeploy --inPlace PATH_TO_APP
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-112) Can not evaluate a variable followed by a quotation mark
[
https://issues.apache.org/jira/browse/GSHELL-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-112:
---
Assignee: Jason Warner (was: Jason Dillon)
Can not evaluate a variable followed by a quotation mark
Key: GSHELL-112
URL: https://issues.apache.org/jira/browse/GSHELL-112
Project: GShell
Issue Type: Bug
Security Level: public(Regular issues)
Components: Parser
Affects Versions: 1.0-alpha-2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Run the following steps in gshell:
{noformat}
set username=system
set password=manager
set login=deploy/connect -u $username -w $password
{noformat}
get the following Error message:
{noformat}
[EMAIL PROTECTED]:/ set login=deploy/connect -u $username -w $password
ERROR SyntaxException: Failed to evaluate: password
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4087) Improve usability of gshell commands deploy/* when failing to connect to server
[
https://issues.apache.org/jira/browse/GERONIMO-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GERONIMO-4087:
---
Fix Version/s: 2.2
Improve usability of gshell commands deploy/* when failing to connect to
server
---
Key: GERONIMO-4087
URL: https://issues.apache.org/jira/browse/GERONIMO-4087
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 2.1.2, 2.1.x, 2.2
Run the below gshell commands when the server is stopped
deploy/list-modules
It should output a message saying something like Connection refused instead
of the following exceptions:
{noformat}
19:24:42,578 FATAL [BaseDeploymentFactory] caught
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.ServiceUnav
ailableException [Root exception is java.rmi.ConnectException: Connection
refuse
d to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:33
2)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto
ry.java:263)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.newRemoteDeploymentManager(BaseDeploymentFactory.java:173)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.getDeploymentManager(BaseDeploymentFactory.java:137)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.get
DeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:186)
at
org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRe
try(ServerConnection.java:240)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:182)
at
org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConn
ection.java:94)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java
:161)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma
inConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31
)
Caused by:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectExce
ption: Connection refused to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:112)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.j
ava:200)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnect
or.java:1822)
at
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.j
ava:1792)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:27
4)
... 12 more
Caused by:
java.rmi.ConnectException: Connection refused to host: localhost; nested
excepti
on is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:590)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204
)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:321)
at
sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:88)
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:108)
... 17 more
Caused by:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385)
at java.net.Socket.connect(Socket.java:541)
at java.net.Socket.connect(Socket.java:491)
at java.net.Socket.init(Socket.java:399)
at java.net.Socket.init(Socket.java:208)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirect
SocketFactory.java:41)
at
[jira] Resolved: (GERONIMO-4087) Improve usability of gshell commands deploy/* when failing to connect to server
[
https://issues.apache.org/jira/browse/GERONIMO-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner resolved GERONIMO-4087.
Resolution: Fixed
committed proposed changes to revision 661343 in branches/2.1 and revision
661346 in trunk
Improve usability of gshell commands deploy/* when failing to connect to
server
---
Key: GERONIMO-4087
URL: https://issues.apache.org/jira/browse/GERONIMO-4087
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 2.1.2, 2.1.x, 2.2
Run the below gshell commands when the server is stopped
deploy/list-modules
It should output a message saying something like Connection refused instead
of the following exceptions:
{noformat}
19:24:42,578 FATAL [BaseDeploymentFactory] caught
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.ServiceUnav
ailableException [Root exception is java.rmi.ConnectException: Connection
refuse
d to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:33
2)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto
ry.java:263)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.newRemoteDeploymentManager(BaseDeploymentFactory.java:173)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.getDeploymentManager(BaseDeploymentFactory.java:137)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.get
DeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:186)
at
org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRe
try(ServerConnection.java:240)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:182)
at
org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConn
ection.java:94)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java
:161)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma
inConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31
)
Caused by:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectExce
ption: Connection refused to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:112)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.j
ava:200)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnect
or.java:1822)
at
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.j
ava:1792)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:27
4)
... 12 more
Caused by:
java.rmi.ConnectException: Connection refused to host: localhost; nested
excepti
on is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:590)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204
)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:321)
at
sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:88)
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:108)
... 17 more
Caused by:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385)
at java.net.Socket.connect(Socket.java:541)
at java.net.Socket.connect(Socket.java:491)
at java.net.Socket.init(Socket.java:399)
at java.net.Socket.init(Socket.java:208)
at
[jira] Assigned: (GERONIMO-4087) Improve usability of gshell commands deploy/* when failing to connect to server
[
https://issues.apache.org/jira/browse/GERONIMO-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-4087:
--
Assignee: Jason Warner
Improve usability of gshell commands deploy/* when failing to connect to
server
---
Key: GERONIMO-4087
URL: https://issues.apache.org/jira/browse/GERONIMO-4087
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 2.1.2, 2.1.x
Run the below gshell commands when the server is stopped
deploy/list-modules
It should output a message saying something like Connection refused instead
of the following exceptions:
{noformat}
19:24:42,578 FATAL [BaseDeploymentFactory] caught
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.ServiceUnav
ailableException [Root exception is java.rmi.ConnectException: Connection
refuse
d to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:33
2)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto
ry.java:263)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.newRemoteDeploymentManager(BaseDeploymentFactory.java:173)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.getDeploymentManager(BaseDeploymentFactory.java:137)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.get
DeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:186)
at
org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRe
try(ServerConnection.java:240)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:182)
at
org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConn
ection.java:94)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java
:161)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma
inConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31
)
Caused by:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectExce
ption: Connection refused to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:112)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.j
ava:200)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnect
or.java:1822)
at
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.j
ava:1792)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:27
4)
... 12 more
Caused by:
java.rmi.ConnectException: Connection refused to host: localhost; nested
excepti
on is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:590)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204
)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:321)
at
sun.rmi.registry.RegistryImpl_Stub.lookup(RegistryImpl_Stub.java:88)
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:108)
... 17 more
Caused by:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:372)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:233)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:220)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385)
at java.net.Socket.connect(Socket.java:541)
at java.net.Socket.connect(Socket.java:491)
at java.net.Socket.init(Socket.java:399)
at java.net.Socket.init(Socket.java:208)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirect
SocketFactory.java:41)
at
[jira] Commented: (GERONIMO-4087) Improve usability of gshell commands deploy/* when failing to connect to server
[
https://issues.apache.org/jira/browse/GERONIMO-4087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600611#action_12600611
]
Jason Warner commented on GERONIMO-4087:
The messages that are being shown are log messages. The exception they are
taken from seems to be caught and handled appropriately by the gshell interface
already. The code that results in this message being logged is
{noformat}
} catch (IOException e) {
log.fatal(caught , e);
DeploymentManagerCreationException
deploymentManagerCreationException =
(DeploymentManagerCreationException) new
DeploymentManagerCreationException(e.getMessage()).initCause(e);
log.fatal(throwing , deploymentManagerCreationException);
throw deploymentManagerCreationException;
{noformat}
I suggest we change the log level to debug for these and wrap them in an if
statement. I'm not sure why they were set to fatal (log.error in trunk) and
don't want to make the change without some other input. Thoughts?
Improve usability of gshell commands deploy/* when failing to connect to
server
---
Key: GERONIMO-4087
URL: https://issues.apache.org/jira/browse/GERONIMO-4087
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2
Reporter: YunFeng Ma
Assignee: Jason Warner
Priority: Minor
Fix For: 2.1.2, 2.1.x
Run the below gshell commands when the server is stopped
deploy/list-modules
It should output a message saying something like Connection refused instead
of the following exceptions:
{noformat}
19:24:42,578 FATAL [BaseDeploymentFactory] caught
java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.ServiceUnav
ailableException [Root exception is java.rmi.ConnectException: Connection
refuse
d to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:33
2)
at
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFacto
ry.java:263)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.newRemoteDeploymentManager(BaseDeploymentFactory.java:173)
at
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory
.getDeploymentManager(BaseDeploymentFactory.java:137)
at
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.get
DeploymentManager(DeploymentFactoryManager.java:111)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:186)
at
org.apache.geronimo.deployment.cli.ServerConnection.doAuthPromptAndRe
try(ServerConnection.java:240)
at
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(Serv
erConnection.java:182)
at
org.apache.geronimo.deployment.cli.ServerConnection.init(ServerConn
ection.java:94)
at
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java
:161)
at
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(Ma
inConfigurationBootstrapper.java:45)
at
org.apache.geronimo.cli.AbstractCLI.executeMain(AbstractCLI.java:67)
at
org.apache.geronimo.cli.deployer.DeployerCLI.main(DeployerCLI.java:31
)
Caused by:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectExce
ption: Connection refused to host: localhost; nested exception is:
java.net.ConnectException: Connection refused: connect]
at
com.sun.jndi.rmi.registry.RegistryContext.lookup(RegistryContext.java
:112)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.j
ava:200)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at
javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnect
or.java:1822)
at
javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.j
ava:1792)
at
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:27
4)
... 12 more
Caused by:
java.rmi.ConnectException: Connection refused to host: localhost; nested
excepti
on is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:590)
at
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:204
)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:190)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:321)
at
[jira] Commented: (GERONIMO-4085) Change tomcat version to 6.0.16
[ https://issues.apache.org/jira/browse/GERONIMO-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600214#action_12600214 ] Jason Warner commented on GERONIMO-4085: missed a couple file deletes. committed in revision 660624 for branches/2.1 Change tomcat version to 6.0.16 --- Key: GERONIMO-4085 URL: https://issues.apache.org/jira/browse/GERONIMO-4085 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.x, 2.2 Version 6.0.16 of tomcat provides a more stable nio connector. Upgrading to take advantage of that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-4085) Change tomcat version to 6.0.16
[ https://issues.apache.org/jira/browse/GERONIMO-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12600236#action_12600236 ] Jason Warner commented on GERONIMO-4085: committed in revision 660639 for trunk Change tomcat version to 6.0.16 --- Key: GERONIMO-4085 URL: https://issues.apache.org/jira/browse/GERONIMO-4085 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.x, 2.2 Version 6.0.16 of tomcat provides a more stable nio connector. Upgrading to take advantage of that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4085) Change tomcat version to 6.0.16
[ https://issues.apache.org/jira/browse/GERONIMO-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4085. -- Resolution: Fixed trunk committed in 660639 branches/2.1 committed in 660624 Change tomcat version to 6.0.16 --- Key: GERONIMO-4085 URL: https://issues.apache.org/jira/browse/GERONIMO-4085 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.x, 2.2 Version 6.0.16 of tomcat provides a more stable nio connector. Upgrading to take advantage of that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4036) Warning message after running gsh geronimo/stop-server
[
https://issues.apache.org/jira/browse/GERONIMO-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-4036:
--
Assignee: Jason Warner
Warning message after running gsh geronimo/stop-server
--
Key: GERONIMO-4036
URL: https://issues.apache.org/jira/browse/GERONIMO-4036
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.2, 2.1.x, 2.2
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.2
About 10 seconds after running geronimo/stop-server successfully, got the
following warning messages in the gsh console:
{noformat}
[EMAIL PROTECTED]:/ 2008-5-20 13:51:12 ClientCommunicatorAdmin restart
Warning: Failed to restart: java.io.IOException: Failed to get a RMI stub:
javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is:
java.net.ConnectException: Connection refused: connect]
2008-5-20 13:51:13 RMIConnector RMIClientCommunicatorAdmin-doStop
Warning: Failed to call the method close():java.rmi.ConnectException:
Connection refused to host: 9.186.117.32; nested exception is:
java.net.ConnectException: Connection refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: Failed to check connection: java.net.ConnectException: Connection
refused: connect
2008-5-20 13:51:13 ClientCommunicatorAdmin Checker-run
Warning: stopping
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4007) Exceptions received in Async HTTP sample app when under heavy load.
[ https://issues.apache.org/jira/browse/GERONIMO-4007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-4007. -- Resolution: Fixed Changes made in revision 655505 Exceptions received in Async HTTP sample app when under heavy load. --- Key: GERONIMO-4007 URL: https://issues.apache.org/jira/browse/GERONIMO-4007 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Fix For: 2.2 During testing of the Asynchronous HTTP Client using the Async HTTP sample app, there were multiple exceptions caused by lack of synchronization in the application and some not thread safe code in event handling. Changes include: *Increase synchronization *Access session Id only on begin event *Addition of a debug option -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4007) Exceptions received in Async HTTP sample app when under heavy load.
Exceptions received in Async HTTP sample app when under heavy load. --- Key: GERONIMO-4007 URL: https://issues.apache.org/jira/browse/GERONIMO-4007 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: sample apps Affects Versions: 2.2 Reporter: Jason Warner Assignee: Jason Warner Priority: Minor Fix For: 2.2 During testing of the Asynchronous HTTP Client using the Async HTTP sample app, there were multiple exceptions caused by lack of synchronization in the application and some not thread safe code in event handling. Changes include: *Increase synchronization *Access session Id only on begin event *Addition of a debug option -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3994) GShell command remote-control/server-control can not control the remote server
[
https://issues.apache.org/jira/browse/GERONIMO-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-3994:
--
Assignee: Jason Warner
GShell command remote-control/server-control can not control the remote server
--
Key: GERONIMO-3994
URL: https://issues.apache.org/jira/browse/GERONIMO-3994
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: commands
Affects Versions: 2.1.1, 2.1.2, 2.1.x
Environment: Windows
Reporter: YunFeng Ma
Assignee: Jason Warner
Fix For: 2.1.1, 2.1.2, 2.1.x
First run remote/rsh to login the remote rsh-server, then run the following
gsh commands:
{noformat}
remote-control/server-control start defaultServer
{noformat}
No any response.
Here is the gshell log in the remote server.
{noformat}
19:36:47,234 DEBUG (SocketAcceptorIoProcessor-0.0)
[org.apache.mina.filter.executor.ExecutorFilter] Launching thread for
/127.0.0.1:3699
19:36:47,234 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.remote.server.RshServer$Handler]
[/127.0.0.1:3699] RECEIVED: ExecuteMessage{ flavor=STRING, path=null,
args=[ remote-control/server-control start defaultServer ], id=7, cid=null,
sequence=7, timestamp=1209436607234 }
19:36:47,234 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing (String):
remote-control/server-control start defaultServer
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.parser.CommandLineParser] Parsing from reader:
[EMAIL PROTECTED]
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] CommandLine
(org.apache.geronimo.gshell.parser.ASTCommandLine)
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] Expression
(org.apache.geronimo.gshell.parser.ASTExpression)
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] PlainString(
remote-control/server-control )
(org.apache.geronimo.gshell.parser.ASTPlainString)
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] PlainString( start )
(org.apache.geronimo.gshell.parser.ASTPlainString)
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] PlainString(
defaultServer ) (org.apache.geronimo.gshell.parser.ASTPlainString)
19:36:47,234 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing
(remote-control/server-control): [start, defaultServer]
19:36:47,234 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.plugin.PlexusCommandWrapper] Child container
realm: gshell:e47ff117-c940-4e2e-87a8-5b9257bc16e9
19:36:47,343 DEBUG (TcpTransportServer-0-0)
[org.codehaus.plexus.PlexusContainer] Found 0 components to load on start
19:36:47,343 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.commands.RemoteServerControlCommand.geronimo-commands:remote-server-control]
Executing w/args: [start, defaultServer]
19:36:47,390 DEBUG (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.remote.server.handler.ExecuteHandler] Fault:
java.lang.IllegalStateException: File D:\geronimo
server-1\bin\etc\server-configuration.xml does not exist
19:36:47,390 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.remote.server.RshServer$Handler]
[/127.0.0.1:3699] WRITE: Fault{ result=java.lang.IllegalStateException: File
D:\geronimo server-1\bin\etc\server-configuration.xml does not exist, id=10,
cid=7, sequence=10, timestamp=1209436607390 }
19:36:47,390 DEBUG (TcpTransportServer-0-0)
[org.apache.mina.filter.executor.ExecutorFilter] Exiting since queue is empty
for /127.0.0.1:3699
19:36:47,390 DEBUG (SocketAcceptorIoProcessor-0.0)
[org.apache.mina.filter.executor.ExecutorFilter] Launching thread for
/127.0.0.1:3699
19:36:47,453 INFO (TcpTransportServer-0-0)
[org.apache.geronimo.gshell.remote.server.RshServer$Handler]
[/127.0.0.1:3699] SENT: Fault{ result=java.lang.IllegalStateException: File
D:\geronimo server-1\bin\etc\server-configuration.xml does not exist, id=10,
cid=7, sequence=10, timestamp=1209436607390 }
19:36:47,453 DEBUG (TcpTransportServer-0-0)
[org.apache.mina.filter.executor.ExecutorFilter] Exiting since queue is empty
for /127.0.0.1:3699
{noformat}
Obvious the gshell is trying to find the configuration file in D:\geronimo
server-1\bin\etc\, it should be D:\geronimo server-1\etc\.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3932) several enhancements to the async container client sample app
[ https://issues.apache.org/jira/browse/GERONIMO-3932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner resolved GERONIMO-3932. Resolution: Fixed Fix Version/s: 2.2 Committed revision 651688 Thanks, Sangjin! several enhancements to the async container client sample app - Key: GERONIMO-3932 URL: https://issues.apache.org/jira/browse/GERONIMO-3932 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: sample apps Affects Versions: 2.2 Reporter: Sangjin Lee Assignee: Jason Warner Priority: Minor Fix For: 2.2 Attachments: GERONIMO-3932.patch I made a few enhancements and bug fixes in the async client sample app. The changes include - calls HttpServletResponse.flushBuffer() to address a Tomcat NPE - added a dump query that dumps some stats - made Callback thread safe using an AtomicBoolean - wrote Utils to be a little more efficient - and so on Thanks! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-101) Implement command context
[ https://issues.apache.org/jira/browse/GSHELL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-101: Attachment: GShell-101.patch Patch. Added new file ContextCommand.java. This implements the ability to change context. The command is not actually necessary to change the context. You can just type the new context you want and as long as it's a valid path, the context will be changed automatically. The command can also be used to make the change (i,e. context optional). I also added an option for the context command to display the current context (context -c). Implement command context - Key: GSHELL-101 URL: https://issues.apache.org/jira/browse/GSHELL-101 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Support - CLP Affects Versions: 1.0-alpha-2, 1.0-alpha-3 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2, 1.0-alpha-3 Attachments: GShell-101.patch Gshell current lacks the ability to change the context from which a command is run. All commands default to running from a root directory. To be able to launch a command without fully qualifying (i.e; /bsf/script), the command search path must be used. It would be nice if we could also changed the context such that we can run any bsf command (or other command group commands) without having to modify the command search path. This will also allow us to use relative command paths (../ and ./). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-101) Implement command context
[ https://issues.apache.org/jira/browse/GSHELL-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-101: Summary: Implement command context (was: Inplement command context) Implement command context - Key: GSHELL-101 URL: https://issues.apache.org/jira/browse/GSHELL-101 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Support - CLP Affects Versions: 1.0-alpha-2, 1.0-alpha-3 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2, 1.0-alpha-3 Gshell current lacks the ability to change the context from which a command is run. All commands default to running from a root directory. To be able to launch a command without fully qualifying (i.e; /bsf/script), the command search path must be used. It would be nice if we could also changed the context such that we can run any bsf command (or other command group commands) without having to modify the command search path. This will also allow us to use relative command paths (../ and ./). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12580059#action_12580059 ] Jason Warner commented on GERONIMO-3902: Joe, I just did a quick scan through the rest of the commands and it looks like StartClientCommand.java uses it in the same manner that StartServerCommand.java does. I suggest that this change be made to that file as well and will post a patch shortly for that. In regards to checking individual options, I agree that that is an ideal approach but the same effect can also be accomplished within the rc.d groovy file if a user chose to do so, and I wanted to make as few changes as possible to the command groovy files. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-3902: --- Attachment: Geronimo-3902-IncludesStartClient.patch This patch makes the changes in both StartServerCommand.groovy and StartClientCommand.groovy. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902-IncludesStartClient.patch, Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3902) start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell
[ https://issues.apache.org/jira/browse/GERONIMO-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GERONIMO-3902: --- Attachment: Geronimo-3902.patch I modified the start-server,default.groovy script so that it checked to see if any java opts were added on the command line. It's an all or nothing check so this script won't set anything even if it's an unrelated java opt that's been set. I had to make a change in StartServerCommand.groovy since the script was processed after some default java opts were added to the list. This made the check always fail. I moved the addition of those default java opts to until after the script is processed to fix this. I haven't taken a look at the other command scripts, but this same change might need to be made in them as well to allow the same functionality in the rc.d scripts if we wanted that. start-server, default.groovy in etc/rc.d overrides -Xmx value when starting server using gshell --- Key: GERONIMO-3902 URL: https://issues.apache.org/jira/browse/GERONIMO-3902 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.1.1, 2.2 Attachments: Geronimo-3902.patch The start-server, default.groovy file is included in etc/rc.d directory and contains a command to set the max heap size for geronimo when starting through gshell. This file overrides any max heap size values that are set via the command line causing issues when starting the server with non-default max heap values. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3869) geronimo/stop-server doesn't use connection established by deploy/connect in gshell
geronimo/stop-server doesn't use connection established by deploy/connect in gshell --- Key: GERONIMO-3869 URL: https://issues.apache.org/jira/browse/GERONIMO-3869 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 2.1, 2.1.1, 2.2 Reporter: Jason Warner Fix For: 2.2 When using the gshell command line to work with geronimo, hostname and possibly port (depending on geronimo configuration) must be provided to geronimo/stop-server even if the gshell session is already connected to that remote server via deploy/connect. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DAYTRADER-58) org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0)
org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) --- Key: DAYTRADER-58 URL: https://issues.apache.org/jira/browse/DAYTRADER-58 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Reporter: Jason Warner Fix For: 2.0 Received the following stacktrace when trying to build from DayTrader trunk. org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 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.artifact.versioning.OverConstrainedVersionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:291) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAYTRADER-58) org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0)
[ https://issues.apache.org/jira/browse/DAYTRADER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated DAYTRADER-58: -- Attachment: Daytrader-58.patch I changed all the spec entries version requirements in the root pom to [1.0,2.1). org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) --- Key: DAYTRADER-58 URL: https://issues.apache.org/jira/browse/DAYTRADER-58 Project: DayTrader Issue Type: Bug Components: buildsystem Affects Versions: 2.0 Reporter: Jason Warner Fix For: 2.0 Attachments: Daytrader-58.patch Received the following stacktrace when trying to build from DayTrader trunk. org.apache.maven.lifecycle.LifecycleExecutionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) 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.artifact.versioning.OverConstrainedVersionException: Couldn't find a version in [2.0.0] to match range [1.0,2.0) org.apache.geronimo.specs:geronimo-jaxrpc_1.1_spec:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org), apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:291) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) at org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-101) Inplement command context
Inplement command context - Key: GSHELL-101 URL: https://issues.apache.org/jira/browse/GSHELL-101 Project: GShell Issue Type: New Feature Security Level: public (Regular issues) Components: Support - CLP Affects Versions: 1.0-alpha-2, 1.0-alpha-3 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2, 1.0-alpha-3 Gshell current lacks the ability to change the context from which a command is run. All commands default to running from a root directory. To be able to launch a command without fully qualifying (i.e; /bsf/script), the command search path must be used. It would be nice if we could also changed the context such that we can run any bsf command (or other command group commands) without having to modify the command search path. This will also allow us to use relative command paths (../ and ./). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-13) Implement command search path
[ https://issues.apache.org/jira/browse/GSHELL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-13: --- Attachment: GShell-13.patch This implements the beginnings of command path search. An environment variable path can be set so that commands can be used without fully qualifying the path every time (i.e, script instead of bsf/script). An issue I came across is that the set command doesn't like when you try to add to the path via path=$path:bsf. This causes an error and the path isn't set properly. Can gshell load environmental variables from a .profile type file, yet? Having a persistent path based on such a file would be neat. If it doesn't exist, I might just have to look into it. As a side note, I made the command path work such that you can always access the builtins in case someone accidentally mucks up their path. I did that during testing and none of the commands could be found, including quit (ctrl + c to the rescue!). Implement command search path - Key: GSHELL-13 URL: https://issues.apache.org/jira/browse/GSHELL-13 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Core Affects Versions: 0.0.1 Reporter: Jason Dillon Assignee: Jason Warner Fix For: 1.0-alpha-2 Attachments: GShell-13.patch Command search path. * ~/.gshell/ * profile.gsh * settings.gsh? settings.properties? settings.xml? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-13) Implement command search path
[ https://issues.apache.org/jira/browse/GSHELL-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-13: -- Assignee: Jason Warner (was: Jason Dillon) Implement command search path - Key: GSHELL-13 URL: https://issues.apache.org/jira/browse/GSHELL-13 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Core Affects Versions: 0.0.1 Reporter: Jason Dillon Assignee: Jason Warner Fix For: 1.0-alpha-2 Command search path. * ~/.gshell/ * profile.gsh * settings.gsh? settings.properties? settings.xml? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GSHELL-98. -- Resolution: Invalid After a quick chat with Jason Dillon, it became apparent I was just using GShell wrong. The path for the command I was using was incomplete. Things are working as intended. NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Dillon Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12560218#action_12560218 ] Jason Warner commented on GSHELL-98: Sure. I ran across it when trying to use the script command. This was when using the full assembly. I'm not sure if I was doing something wrong that caused it so let me just explain how i got to that point to see if maybe I did something incorrectly. I checked out the latest revision. I then ran an mvn install. I used tar -xvf (after gunzip) on the full assembly. I then changed to the bin directory in the recently untarred assembly and ran ./gsh. I then used help to verify that the commands were listed in the layout. After verifying that script existed and was part of this assembly I tried to run script using script -l javascript. I received a NotFoundException for script. This also occurred with the commands listed under optional (wait, sleep, etc...). It might have occurred with the rsh commands but I didn't check. NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Dillon Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-54) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager
[ https://issues.apache.org/jira/browse/GSHELL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-54: -- Assignee: Jason Warner (was: Jason Dillon) Allow relative (../ and ./) as well as absolute paths (/foo/bar) to resolve as expected in the layout manager - Key: GSHELL-54 URL: https://issues.apache.org/jira/browse/GSHELL-54 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-58) Layout command aliases should be allowed to reference relative command paths for targets
[
https://issues.apache.org/jira/browse/GSHELL-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-58:
--
Assignee: Jason Warner (was: Jason Dillon)
Layout command aliases should be allowed to reference relative command paths
for targets
Key: GSHELL-58
URL: https://issues.apache.org/jira/browse/GSHELL-58
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Core
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
For example:
{code}
...
group
nameremote/name
nodes
command
namersh/name
idgshell-remote:rsh/id
/command
command
namersh-server/name
idgshell-remote:rsh-server/id
/command
alias
namershd/name
commandrsh-server/command
/alias
/nodes
/group
/nodes
/layout
{code}
In this example, the {{remote/rshd}} command alias really wants to point to
{{remote/rsh-server}} but current alias target resolve works from the layout
root.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
[ https://issues.apache.org/jira/browse/GSHELL-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-98: --- Attachment: GShell-98.patch The issue ended up being that the find function in GroupNode was not able to handle nested GroupNodes. I enhanced it to provide a recursive search that should work for any amount of nesting that you so desire. NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2 Attachments: GShell-98.patch The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GSHELL-48:
---
Attachment: GShell-48.patch
This includes the functionality of both GShell-48 and it's subtask, GShell-49.
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Attachments: GShell-48.patch
Should be able to give the BSF {{script}} command a file or URL to execute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12559296#action_12559296
]
jawarner edited comment on GSHELL-48 at 1/15/08 4:10 PM:
-
This includes the functionality of both GShell-48 and the subtask, GShell-49.
was (Author: jawarner):
This includes the functionality of both GShell-48 and it's subtask,
GShell-49.
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Attachments: GShell-48.patch
Should be able to give the BSF {{script}} command a file or URL to execute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-48) Add file/URL support to the script command
[
https://issues.apache.org/jira/browse/GSHELL-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-48:
--
Assignee: Jason Warner
Add file/URL support to the script command
--
Key: GSHELL-48
URL: https://issues.apache.org/jira/browse/GSHELL-48
Project: GShell
Issue Type: New Feature
Security Level: public(Regular issues)
Components: Commands - BSF
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Should be able to give the BSF {{script}} command a file or URL to execute.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-49) When --language is not given and we have a file/URL try and figure out the lang to use
[ https://issues.apache.org/jira/browse/GSHELL-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-49: -- Assignee: Jason Warner When --language is not given and we have a file/URL try and figure out the lang to use -- Key: GSHELL-49 URL: https://issues.apache.org/jira/browse/GSHELL-49 Project: GShell Issue Type: Sub-task Security Level: public(Regular issues) Components: Commands - BSF Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-98) NotFoundException when trying to use non-builtin commands in full assembly
NotFoundException when trying to use non-builtin commands in full assembly -- Key: GSHELL-98 URL: https://issues.apache.org/jira/browse/GSHELL-98 Project: GShell Issue Type: Bug Security Level: public (Regular issues) Components: Core Affects Versions: 1.0-alpha-2 Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-2 The full assembly of gshell includes all the available commands by default. When trying to use one of the commands included outside of builtins, a NotFoundException is received. This seems to be caused by the groupings in the layout.xml file. When the groupings were removed, all the commands could be used successfully. Ideally, we'd like to be able to keep the groupings, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-66) Auto-generate cli syntax/usage string when displaying --help
[
https://issues.apache.org/jira/browse/GSHELL-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GSHELL-66:
---
Attachment: GShell-66.patch
I added some code to printUsage to generate the appropriate lists and syntax
command only if those pieces were present. I'm not attached to the wording or
format, so if you feel like tweaking those go right ahead.
Auto-generate cli syntax/usage string when displaying --help
Key: GSHELL-66
URL: https://issues.apache.org/jira/browse/GSHELL-66
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Support - CLP
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Minor
Fix For: 1.0-alpha-2
Attachments: GShell-66.patch
When generating a commands --help, the syntax/usage should be auto-generated.
For example take the {{help}} command's {{--help}}:
{noformat}
[EMAIL PROTECTED]:/ help --help
help
--
VALCommand name
-h (--help)Display this help message
{noformat}
Ideally this should be rendered as:
{noformat}
[EMAIL PROTECTED]:/ help --help
syntax: help [options] [COMMAND]
arguments:
COMMANDCommand name
options:
-h (--help) Display this help message
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2682) Sending a message throws a SendFailedException
[
https://issues.apache.org/jira/browse/GERONIMO-2682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GERONIMO-2682:
--
Assignee: (was: Jason Warner)
Sending a message throws a SendFailedException
--
Key: GERONIMO-2682
URL: https://issues.apache.org/jira/browse/GERONIMO-2682
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: mail
Affects Versions: 2.0.x
Reporter: Geist Alexander
Fix For: 2.0.x
// Get system properties
Properties props = System.getProperties();
// Setup mail server
props.put(mail.smtp.host, Settings.smtpServer);
props.put(mail.imap.partialfetch, false);
props.put(mail.smtp.auth, true);
Authenticator auth = new Authenticator()
{
protected PasswordAuthentication getPasswordAuthentication()
{
return new PasswordAuthentication(Settings.user, Settings.key);
}
};
return Session.getDefaultInstance(props, auth);
The method was used to get the session. It works.
Next step is to build and to send the message.
// Define message
MimeMessage message = new MimeMessage(mailParam.getSession());
// Set the from address
message.setFrom(new InternetAddress(Settings.from));
// Empfänger
message.addRecipient(Message.RecipientType.TO, new
InternetAddress(mailParam.getMailAddress()));
// Set the subject
message.setSubject(Subject);
BodyPart messageBodyPart = new MimeBodyPart();
String text =
getEmailText(mailParam.getXmgKey(),mailParam.getXlgKey(),
mailParam.getDate());
messageBodyPart.setContent(text, text/html);
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
// Put parts in message
message.setContent(multipart);
// Send message
Transport.send(message);
Transport.send(message) is throwing this Exception
javax.mail.SendFailedException: Send failure (javax.mail.MessagingException:
Connection error (java.net.ConnectException: Connection refused: connect))
at javax.mail.Transport.send(Transport.java:163)
at javax.mail.Transport.send(Transport.java:48)
at keygen.main.MailSender.sendMail(MailSender.java:44)
at keygen.main.MailSender.main(MailSender.java:112)
Caused by: javax.mail.MessagingException: Connection error
(java.net.ConnectException: Connection refused: connect)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:403)
at javax.mail.Service.connect(Service.java:254)
at javax.mail.Service.connect(Service.java:85)
at javax.mail.Service.connect(Service.java:70)
at javax.mail.Transport.send(Transport.java:94)
... 3 more
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.init(Socket.java:366)
at java.net.Socket.init(Socket.java:239)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.getConnectedSocket(SMTPTransport.java:1091)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.getConnection(SMTPTransport.java:851)
at
org.apache.geronimo.javamail.transport.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:380)
... 7 more
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-70) Boolean options should be able to take an optional argument to negate, ie. --foo=false
[
https://issues.apache.org/jira/browse/GSHELL-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner updated GSHELL-70:
---
Attachment: GShell-70.patch
This works as described. I added a flag in the handler class so that it could
be inherited by the boolean handler. It might be helpful other places in the
future, though I don't have a specific scenario in mind.
Boolean options should be able to take an optional argument to negate, ie.
--foo=false
--
Key: GSHELL-70
URL: https://issues.apache.org/jira/browse/GSHELL-70
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Support - CLP
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
Attachments: GShell-70.patch
Boolean options, like:
{code:java}
@Option(name=-f, aliases={--foo})
private boolean foo;
{code}
Should support negation with:
{noformat}
--foo=false
{noformat}
or:
{noformat}
-f=false
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-2806) mail.null.host property not resolved by SMTPTransport class
[ https://issues.apache.org/jira/browse/GERONIMO-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner closed GERONIMO-2806. -- mail.null.host property not resolved by SMTPTransport class --- Key: GERONIMO-2806 URL: https://issues.apache.org/jira/browse/GERONIMO-2806 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: mail Affects Versions: 1.1.1 Reporter: Jason Warner Assignee: Jason Warner Fix For: 2.0-M5 Attachments: Geronimo-2806_Javamail.patch, Geronimo-2806_Specs.patch There's a problem in the base class that's causing it to read the property mail.null.host rather than mail.smtp.host, like it should. There's also a secondary problem where the SMTPTransport class in its protocolConnect() method is not detecting a null host and reading the property itself -- 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_12550683
]
Jason Warner commented on GSHELL-20:
Are we deciding to forgo this band-aid and put our hopes in a more fleshed out
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, 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-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549896 ] Jason Warner commented on GSHELL-46: Actually, it works with setting the property within GShell as well. I just needed to remember that the set command defaults to setting the value as a variable rather than as a property. When setting the mode to PROPERTY, it works just as it should. Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Attachments: GShell-46.patch Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-46: --- Attachment: GShell-46.patch Assuming this is what you were looking for, this was a lot easier than I kept making it out to be once I found what I was looking for. The only issue is, it only works when activated when launching gshell. I'm still trying to figure out why the system property doesn't get picked up when it's set from within the gshell environment. Are the system properties being used by DefaultGshell.java and SetCommand.java different? Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Attachments: GShell-46.patch Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548525 ] Jason Warner commented on GSHELL-46: I just type up a whole long thing for this and then lost it when I clicked add and my session had timed out, so I'll be brief. I found I can get the exception stack traces by setting the verbosity level to VERBOSE. I'm not sure if this is what you were looking for or not, even though it seems to accomplish the goal. My only issue is that the only difference between this and --verbose is --verbose also alters the log level. I also looked into setting a system property. Assuming changing the verbosity is sufficient, it would only be a matter of checking this property at set points and then changing the verbosity accordingly. I thought this check could be done on ever output, but then realized that output is done through PrintWriters that have already been defined. Is there a good place to perform this check? If you don't actually know of a place off hand, let me know and I'll do my own leg work. I just thought it'd be fun to leverage the knowledge of someone with a ton more GShell experience than myself. Finally, I like the idea of persistent options loaded from the preferences but think that probably should be covered in a separate jira as it's work effort is outside the scope of this one. If there isn't one already, I'll open one up myself. Ok, that wasn't too brief. My mistake. Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GSHELL-46) Add flag to show exception stacktraces
[ https://issues.apache.org/jira/browse/GSHELL-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner reassigned GSHELL-46: -- Assignee: Jason Warner Add flag to show exception stacktraces -- Key: GSHELL-46 URL: https://issues.apache.org/jira/browse/GSHELL-46 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: CLI Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Priority: Trivial Fix For: 1.0-alpha-2 Add a flag to the main CLI to show exception stacktraces (like mvn -e) -- 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_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] 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] Assigned: (GSHELL-70) Boolean options should be able to take an optional argument to negate, ie. --foo=false
[
https://issues.apache.org/jira/browse/GSHELL-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Warner reassigned GSHELL-70:
--
Assignee: Jason Warner
Boolean options should be able to take an optional argument to negate, ie.
--foo=false
--
Key: GSHELL-70
URL: https://issues.apache.org/jira/browse/GSHELL-70
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Support - CLP
Reporter: Jason Dillon
Assignee: Jason Warner
Fix For: 1.0-alpha-2
Boolean options, like:
{code:java}
@Option(name=-f, aliases={--foo})
private boolean foo;
{code}
Should support negation with:
{noformat}
--foo=false
{noformat}
or:
{noformat}
-f=false
{noformat}
--
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-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] Updated: (GSHELL-37) New Command: clear
[ https://issues.apache.org/jira/browse/GSHELL-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-37: --- Attachment: GShell-37ANSI.patch This worked as expected on linux. I tried testing on windows, but I had issues building GShell on windows. The error was actually an error in ant 1.7.0. Have you had an issue with this? New Command: clear -- Key: GSHELL-37 URL: https://issues.apache.org/jira/browse/GSHELL-37 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Commands Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-1 Attachments: GShell-37.patch, GShell-37ANSI.patch Implement the ability to use the clear command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-37) New Command: clear
[ https://issues.apache.org/jira/browse/GSHELL-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542353 ] Jason Warner commented on GSHELL-37: No problem. I've got a patch but I can't quite figure out how to disable ansi to test it. Also, should we still attempt to execute the command after the warning, or is that going to cause an exception? New Command: clear -- Key: GSHELL-37 URL: https://issues.apache.org/jira/browse/GSHELL-37 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Commands Reporter: Jason Warner Assignee: Jason Warner Fix For: 1.0-alpha-1 Attachments: GShell-37.patch Implement the ability to use the clear command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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 reassigned GSHELL-20:
--
Assignee: Jason Warner
`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-1
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:
---
Affects Version/s: 0.0.1
`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
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:
---
Fix Version/s: (was: 1.0-alpha-1)
1.0-alpha-2
Affects Version/s: (was: 0.0.1)
`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
Reporter: Jason Dillon
Assignee: Jason Warner
Priority: Critical
Fix For: 1.0-alpha-2
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-16) New command: ssh
[ https://issues.apache.org/jira/browse/GSHELL-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540648 ] Jason Warner commented on GSHELL-16: Hey Ken, You might want to take this question and re-post it to the dev-list. I'm not sure how much attention it's going to get here. Also, this jira is currently assigned to Jason Dillon. You might want to check with him and make sure he's not actively working on it right now. New command: ssh Key: GSHELL-16 URL: https://issues.apache.org/jira/browse/GSHELL-16 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Commands Reporter: Jason Dillon Assignee: Jason Dillon Priority: Minor Fix For: 1.0-alpha-1 Can wrap the Jsch API to make a ssh command -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-37) New Command: Clear
[ https://issues.apache.org/jira/browse/GSHELL-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-37: --- Attachment: GShell-37.patch This seems to work. It's simple. It uses the JLine clear screen command to clear the screen (shocking. I know). That's pretty much it. Any other code is just setting up for JLine. Nothing fancy, but it satisfies my obsessive compulsive need to keep my terminal cleared. New Command: Clear -- Key: GSHELL-37 URL: https://issues.apache.org/jira/browse/GSHELL-37 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Commands Reporter: Jason Warner Assignee: Jason Warner Attachments: GShell-37.patch Implement the ability to use the clear command. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-36) The clp does not allow --help to execute if a required argument or option is configured
[ https://issues.apache.org/jira/browse/GSHELL-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Warner updated GSHELL-36: --- Attachment: GShell-36AnnotationChange.patch I gave it another shot with the annotation change. I like it better this way. It feels neater. The clp does not allow --help to execute if a required argument or option is configured --- Key: GSHELL-36 URL: https://issues.apache.org/jira/browse/GSHELL-36 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.0-alpha-1 Reporter: Jason Dillon Assignee: Jason Warner Fix For: 1.0-alpha-1 Attachments: GShell-36.patch, GShell-36AnnotationChange.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
