[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work

2007-11-21 Thread Gianny Damour (JIRA)

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

Gianny Damour commented on GERONIMO-3620:
-

Hi Vamsi. I fixed 1. a couple of days ago.

 Remote deployment using command line deployer does not really work
 --

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


 Remote deployment using command line deployer tool does not really work 
 currently as the host has to be localhost.  Here are my observations.
 1.  Deployer.getRemoteDeployUploadURL() is not checking if the contextPath 
 starts with a '/' thus resulting in an incorrect URL like 
 http://localhost:8080//remote-deploy/upload.
 2. Using a remoteDeployAddress like http://localhost:8080 with hostname 
 localhost is not useful at all. When the host we are deploying to is the 
 local machine itself, RemoteDeploymentManager.isSameMachine() returns true 
 and in this case the local files are used directly.

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



[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work

2007-11-21 Thread Vamsavardhana Reddy (JIRA)

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

Vamsavardhana Reddy commented on GERONIMO-3620:
---

Completed: At revision: 597012  
 o Apparently rev 596561 handles the '/' in contextPath issue.
 o Merging rev 596561 from trunk.
This fix will still bomb if the contextPath is / or base url ends with /

 Remote deployment using command line deployer does not really work
 --

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


 Remote deployment using command line deployer tool does not really work 
 currently as the host has to be localhost.  Here are my observations.
 1.  Deployer.getRemoteDeployUploadURL() is not checking if the contextPath 
 starts with a '/' thus resulting in an incorrect URL like 
 http://localhost:8080//remote-deploy/upload.
 2. Using a remoteDeployAddress like http://localhost:8080 with hostname 
 localhost is not useful at all. When the host we are deploying to is the 
 local machine itself, RemoteDeploymentManager.isSameMachine() returns true 
 and in this case the local files are used directly.

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



[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work

2007-11-21 Thread Vamsavardhana Reddy (JIRA)

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

Vamsavardhana Reddy commented on GERONIMO-3620:
---

Gianny,

I am crippled at building trunk coz my laptop will crash while building 
geronimo-system module.  So, I have not built trunk recently.  Shiva hinted 
about your fix, after which I looked up the revision and merged it into 
branches\2.0.  The fix will still need to handle contextPath / as well as 
remoteDeployAddress ending in /.

++Vamsi

 Remote deployment using command line deployer does not really work
 --

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


 Remote deployment using command line deployer tool does not really work 
 currently as the host has to be localhost.  Here are my observations.
 1.  Deployer.getRemoteDeployUploadURL() is not checking if the contextPath 
 starts with a '/' thus resulting in an incorrect URL like 
 http://localhost:8080//remote-deploy/upload.
 2. Using a remoteDeployAddress like http://localhost:8080 with hostname 
 localhost is not useful at all. When the host we are deploying to is the 
 local machine itself, RemoteDeploymentManager.isSameMachine() returns true 
 and in this case the local files are used directly.

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



[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work

2007-11-21 Thread YunFeng Ma (JIRA)

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

YunFeng Ma commented on GERONIMO-3620:
--

I just submitted a patch for GERONIMO-3583 and that patch can handle the double 
// in Deployer.getRemoteDeployUploadURL(). Thanks.

 Remote deployment using command line deployer does not really work
 --

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


 Remote deployment using command line deployer tool does not really work 
 currently as the host has to be localhost.  Here are my observations.
 1.  Deployer.getRemoteDeployUploadURL() is not checking if the contextPath 
 starts with a '/' thus resulting in an incorrect URL like 
 http://localhost:8080//remote-deploy/upload.
 2. Using a remoteDeployAddress like http://localhost:8080 with hostname 
 localhost is not useful at all. When the host we are deploying to is the 
 local machine itself, RemoteDeploymentManager.isSameMachine() returns true 
 and in this case the local files are used directly.

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



[jira] Commented: (GERONIMO-3620) Remote deployment using command line deployer does not really work

2007-11-21 Thread Vamsavardhana Reddy (JIRA)

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

Vamsavardhana Reddy commented on GERONIMO-3620:
---

Completed: At revision: 597042   
http://svn.apache.org/viewvc?rev=597042view=rev
 o Normalize the URL to remove extra slashes.
 o Thanks to YunFeng Ma for pointing to the patch under GERONIMO-3583.

 Remote deployment using command line deployer does not really work
 --

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


 Remote deployment using command line deployer tool does not really work 
 currently as the host has to be localhost.  Here are my observations.
 1.  Deployer.getRemoteDeployUploadURL() is not checking if the contextPath 
 starts with a '/' thus resulting in an incorrect URL like 
 http://localhost:8080//remote-deploy/upload.
 2. Using a remoteDeployAddress like http://localhost:8080 with hostname 
 localhost is not useful at all. When the host we are deploying to is the 
 local machine itself, RemoteDeploymentManager.isSameMachine() returns true 
 and in this case the local files are used directly.

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