[jira] [Updated] (GERONIMO-5743) ServletContext.getRealPath() returns null

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-5743:


Comment: was deleted

(was: Is this happening for Tomcat or Jetty (or both)?

And, is it returning null when you do not send it a parameter - or when there 
is a parameter passed in too?)

> ServletContext.getRealPath() returns null
> -
>
> Key: GERONIMO-5743
> URL: https://issues.apache.org/jira/browse/GERONIMO-5743
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 3.0-M1
>Reporter: Jarek Gawor
>Assignee: Ivan
> Fix For: 3.0
>
>
> In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous 
> versions of Geronimo a real path was returned. Returning null is ok from 
> specification point of view but it breaks compatibility for applications. It 
> also looks like there are a number of web applications that rely on the 
> getRealPath() to return a non-null value. One such application is Nexus web 
> app.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-5743) ServletContext.getRealPath() returns null

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-5743:
-

Is this happening for Tomcat or Jetty (or both)?

And, is it returning null when you do not send it a parameter - or when there 
is a parameter passed in too?

> ServletContext.getRealPath() returns null
> -
>
> Key: GERONIMO-5743
> URL: https://issues.apache.org/jira/browse/GERONIMO-5743
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 3.0-M1
>Reporter: Jarek Gawor
>Assignee: Ivan
> Fix For: 3.0
>
>
> In 3.0 M1 and trunk, ServletContext.getRealPath() returns null. In previous 
> versions of Geronimo a real path was returned. Returning null is ok from 
> specification point of view but it breaks compatibility for applications. It 
> also looks like there are a number of web applications that rely on the 
> getRealPath() to return a non-null value. One such application is Nexus web 
> app.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869772#action_12869772
 ] 

Jay D. McHugh commented on GERONIMO-4130:
-

This ticket has two parts.  The original issue was enabling and disabling 
services.  The issue of comments came up because that used to be the way to 
accomplish enabling and disabling services.

I think that the issue of enabling and disabling services is already handled by 
the 'load' attribute of the 'module' entities.  If I am mistaken about using 
the load attribute to control whether a particular module starts or not then 
this ticket is valid.  And we need to make sure that there is a simple and 
straight forward way to determine which modules are started (we also need to 
make sure that the title of this ticket is changed to reflect the actual 
problem).

If the load attribute does control which modules actually start, then the use 
of comments in the config.xml file is a completely separate issue.  And, it 
should get it's own (new) ticket.

Here is a discussion of how comments are being handled in the config.xml and 
why.  If anyone thinks that it would be worthwhile to handle 'true XML 
comments' then we should open a new ticket to track that.

There is a problem with using 'real' comments.  And that problem is that the 
tools that are being used to parse the XML files completely ignore them.

So, whenever one of these files are parsed and then recreated - the comment 
would be lost.  That is why the  tag was used in the first place.  
Comments are normally 'for human consumption' only.  We needed to put them into 
the actual XML data in order to tell the parser that they really are a part of 
the data and not just fluff for people to read.

The config.xml file is read in during server start up and recreated from 
scratch during shutdown.  Real XML style comments (and their location within 
the file) do not appear to be maintained by the parser/builder.  We would need 
to make our own XML parser that internally converted the comments into XML data 
and a new XML builder that would re-convert that special comment data back into 
actual comments.

Sorry that it took so long for me to realize that I was answering a different 
problem than the real issue.  

Lin,

Have I finally seen the problem that you were trying to bring up (modifying 
which services start)?

Do you still think that there is a problem with how comments are being handled?

Jay

> Unable to preserve comments from plan.xml into config.xml
> -
>
> Key: GERONIMO-4130
> URL: https://issues.apache.org/jira/browse/GERONIMO-4130
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.x, 2.2
>Reporter: Lin Sun
> Fix For: 2.2.1, Wish List
>
>
> I got a user asking me how to turn off tomcat access log.
> It was easy in previous releases, as we could provide comment in config.xml 
> and tell the users to "To disable accesslogging uncomment the following 
> section...".   However, with our new config.xml, we don't preserve any 
> comments, which makes hard for users to config things.

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

[jira] Commented: (GERONIMO-5216) CLONE -getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-5216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12851427#action_12851427
 ] 

Jay D. McHugh commented on GERONIMO-5216:
-

Hey Matthias,

It looks like this must be a problem with how the tag library is processing the 
 tag.

I will try to take a look as soon as I have some time.

Jay

> CLONE -getContextRoot() returns forward slash rather than empty string for 
> apps deployed to root context
> 
>
> Key: GERONIMO-5216
> URL: https://issues.apache.org/jira/browse/GERONIMO-5216
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.2
>Reporter: Matthias Koch
>Assignee: Jay D. McHugh
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Commented: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761772#action_12761772
 ] 

Jay D. McHugh commented on GERONIMO-4901:
-

Here is a portion of the geronimo.log file that seems to show my app being 
disassembled
during shutdown and reconstituted during startup:
(Using current 2.1.5 snapshot as of 10/02/2009)

During shutdown:
2009-10-02 18:01:56,810 INFO  [startup] Undeploying app: 
/opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar
   
2009-10-02 18:01:56,835 INFO  [startup] Undeploying app: 
/opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil1436047464632244742.jar
   
2009-10-02 18:02:02,120 INFO  [startup] Undeploying app: 
/usr/src/mavenRepository/org/apache/geronimo/plugins/geronimo-mejb/2.1.5-SNAPSHOT/geronimo-mejb-2.1.5-SNAPSHOT.jar
 
2009-10-02 18:02:02,163 INFO  [remote] Received stop signal  


While coming back up - after starting all of the Geronimo services:
2009-10-02 18:10:54,602 INFO  [startup] Assembling app: 
/opt/geronimo-tomcat6-javaee5-2.1.5-SNAPSHOT/var/temp/geronimo-deploymentUtil4824243862298920212.jar

2009-10-02 18:10:58,546 INFO  [startup] Jndi(name=ComponentClassBeanLocal) --> 
Ejb(deployment-id=palmBeans.jar/ComponentClassBean) 
 
2009-10-02 18:10:58,547 INFO  [startup] Jndi(name=VClean7Local) --> 
Ejb(deployment-id=palmBeans.jar/VClean7)

2009-10-02 18:10:58,547 INFO  [startup] Jndi(name=GenericComponentBeanLocal) 
--> Ejb(deployment-id=palmBeans.jar/GenericComponentBean)   
   
2009-10-02 18:10:58,547 INFO  [startup] Jndi(name=VClean2Local) --> 
Ejb(deployment-id=palmBeans.jar/VClean2)

2009-10-02 18:10:58,547 INFO  [startup] Jndi(name=ESDBeanLocal) --> 
Ejb(deployment-id=palmBeans.jar/ESDBean)
..

> Shutting down Geronimo destroys pending Timers
> --
>
> Key: GERONIMO-4901
> URL: https://issues.apache.org/jira/browse/GERONIMO-4901
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0
> Environment: Geronimo 2.1.4
>Reporter: Jay D. McHugh
>
> Here is what SEEMS to be happening:
> Shutting down and bringing Geronimo back up seems to be effectively 
> undeploying everything, then redeploying it.
> So, pending Timers are being destroyed.
> This may not be the actual cause of this - Based upon the log entries during 
> shutdown and restart.

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

[jira] Created: (GERONIMO-4901) Shutting down Geronimo destroys pending Timers

[Jay D. McHugh (JIRA)]

Shutting down Geronimo destroys pending Timers
--

 Key: GERONIMO-4901
 URL: https://issues.apache.org/jira/browse/GERONIMO-4901
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: OpenEJB
Affects Versions: 2.1.4, 2.1.5, 2.2, 3.0
 Environment: Geronimo 2.1.4
Reporter: Jay D. McHugh


Here is what SEEMS to be happening:

Shutting down and bringing Geronimo back up seems to be effectively undeploying 
everything, then redeploying it.
So, pending Timers are being destroyed.

This may not be the actual cause of this - Based upon the log entries during 
shutdown and restart.

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

[jira] Commented: (GERONIMO-3832) Timers created using the Timer Services are not dropeed when the associated ejb module is stopped or undeployed.

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761715#action_12761715
 ] 

Jay D. McHugh commented on GERONIMO-3832:
-

Antonio - Could you please double check that this is still a problem on either 
2.1.4 or trunk (or both)?

I would suspect that it was quietly fixed without updating this ticket.

> Timers created using the Timer Services are not dropeed when the associated 
> ejb module is stopped or undeployed.
> 
>
> Key: GERONIMO-3832
> URL: https://issues.apache.org/jira/browse/GERONIMO-3832
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: OpenEJB
>Affects Versions: 2.0.2, 2.1.1
> Environment: windows 2000, jdk 1.5.0
>Reporter: Antonio Muñoz
>Priority: Minor
>
> When a periodic timer is scheduled using the geronimo timer service, the 
> ejbtimeout method is called properly every time the period is reached. The 
> problems comes when our ejb module is stopped or undeployed because the 
> ejbtimeout is tried to be called again and again every time the period is 
> reached even when the ejb module is already stopped. The logical solution 
> should be stopping every timer associated to the ejb module is being stopped 
> or undeployed.

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

[jira] Commented: (GERONIMO-4723) Replace our dojo repackaging with the released dojo-war

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12730511#action_12730511
 ] 

Jay D. McHugh commented on GERONIMO-4723:
-

(I accidentally put the wrong Jira number in the commit comment)

Sendingplugins/dojo/dojo-jetty/pom.xml
Sendingplugins/dojo/dojo-jetty/src/main/history/dependencies.xml
Sendingplugins/dojo/dojo-tomcat/pom.xml
Sendingplugins/dojo/dojo-tomcat/src/main/history/dependencies.xml
Sendingplugins/dojo/pom.xml
Transmitting file data .
Committed revision 793687.

> Replace our dojo repackaging with the released dojo-war
> ---
>
> Key: GERONIMO-4723
> URL: https://issues.apache.org/jira/browse/GERONIMO-4723
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: web
>Affects Versions: 2.2
>Reporter: David Jencks
> Attachments: GERONIMO-2723.patch
>
>
> dojo has a dojo-war that looks pretty similar to our repacked dojo war.  I 
> can't quite tell if it works.  Maybe someone who understands what dojo does 
> could try it?

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

[jira] Commented: (GERONIMO-4130) Unable to preserve comments from plan.xml into config.xml

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715948#action_12715948
 ] 

Jay D. McHugh commented on GERONIMO-4130:
-

I just checked 2.1.5 to see if the comment function was still working.  And it 
is.

Is it not working in 2.2?

The way to put in comments is to wrap them in a comment element.

example

This will be preserved

You should be able to add a comment element at any level of the config.

> Unable to preserve comments from plan.xml into config.xml
> -
>
> Key: GERONIMO-4130
> URL: https://issues.apache.org/jira/browse/GERONIMO-4130
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: car-maven-plugin
>Affects Versions: 2.1.x, 2.2
>Reporter: Lin Sun
> Fix For: Wish List
>
>
> I got a user asking me how to turn off tomcat access log.
> It was easy in previous releases, as we could provide comment in config.xml 
> and tell the users to "To disable accesslogging uncomment the following 
> section...".   However, with our new config.xml, we don't preserve any 
> comments, which makes hard for users to config things.

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

[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build after updating OpenEJB to released version (3.0)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-4527:


Description: 
Because of a number of changes that have occurred in dependencies of Geronimo 
it will no longer build.

In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 3.0, 
the build stopped working.

Due to changes in the group/artifact names of the artifacts for XBeans - 
OpenEJB 3.0 no longer builds.  There is now a new snapshot version of OpenEJB 
(3.0.1-SNAPSHOT).  These changes include the new snapshot version of OpenEJB 
rather than the unbuildable 3.0 version.

  was:Because of a number of changes that have occurred in dependencies of 
Geronimo it will no longer build.

Summary: Geronimo 2.0.x branch does not build after updating OpenEJB to 
released version (3.0)  (was: Geronimo 2.0.x branch does not build with tests)

Sorry for any confusion.

This issue sprung up as a result of removing the dependency to the beta version 
of OpenEJB locally.

> Geronimo 2.0.x branch does not build after updating OpenEJB to released 
> version (3.0)
> -
>
> Key: GERONIMO-4527
> URL: https://issues.apache.org/jira/browse/GERONIMO-4527
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, kernel, OpenEJB
>Affects Versions: 2.0.3
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.3
>
> Attachments: geronimo-4527.diff
>
>
> Because of a number of changes that have occurred in dependencies of Geronimo 
> it will no longer build.
> In particular, after changing the dependency on OpenEJB from 3.0-beta-1 to 
> 3.0, the build stopped working.
> Due to changes in the group/artifact names of the artifacts for XBeans - 
> OpenEJB 3.0 no longer builds.  There is now a new snapshot version of OpenEJB 
> (3.0.1-SNAPSHOT).  These changes include the new snapshot version of OpenEJB 
> rather than the unbuildable 3.0 version.

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

[jira] Commented: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670246#action_12670246
 ] 

Jay D. McHugh commented on GERONIMO-4527:
-

I have been trying to get 2.0 ready for release - including removing 
dependencies on beta versions.

When I moved it to point it at OpenEJB 3.0 (rather than 3.0-beta-1), the build 
stopped working.

If you switch away from the beta version, does the build still work for you?

> Geronimo 2.0.x branch does not build with tests
> ---
>
> Key: GERONIMO-4527
> URL: https://issues.apache.org/jira/browse/GERONIMO-4527
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, kernel, OpenEJB
>Affects Versions: 2.0.3
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.3
>
> Attachments: geronimo-4527.diff
>
>
> Because of a number of changes that have occurred in dependencies of Geronimo 
> it will no longer build.

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

[jira] Resolved: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-4527.
-

   Resolution: Fixed
Fix Version/s: 2.0.3

Changes committed to branches/2.0

Sending
modules/geronimo-client/src/main/java/org/apache/geronimo/client/AppClientContainer.java
Sending
modules/geronimo-openejb/src/main/java/org/apache/geronimo/openejb/OpenEjbSystemGBean.java
Sending
modules/geronimo-openejb-builder/src/main/java/org/apache/geronimo/openejb/deployment/EjbRefBuilder.java
Sendingpom.xml
Transmitting file data 
Committed revision 740608.


> Geronimo 2.0.x branch does not build with tests
> ---
>
> Key: GERONIMO-4527
> URL: https://issues.apache.org/jira/browse/GERONIMO-4527
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, kernel, OpenEJB
>Affects Versions: 2.0.3
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.3
>
> Attachments: geronimo-4527.diff
>
>
> Because of a number of changes that have occurred in dependencies of Geronimo 
> it will no longer build.

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

[jira] Updated: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-4527:


Attachment: geronimo-4527.diff

Put all of the changes here so that there would be an easily reviewable set of 
changes if anyone cared to see what was changed to fix the build.

> Geronimo 2.0.x branch does not build with tests
> ---
>
> Key: GERONIMO-4527
> URL: https://issues.apache.org/jira/browse/GERONIMO-4527
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: core, kernel, OpenEJB
>Affects Versions: 2.0.3
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Attachments: geronimo-4527.diff
>
>
> Because of a number of changes that have occurred in dependencies of Geronimo 
> it will no longer build.

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

[jira] Created: (GERONIMO-4527) Geronimo 2.0.x branch does not build with tests

[Jay D. McHugh (JIRA)]

Geronimo 2.0.x branch does not build with tests
---

 Key: GERONIMO-4527
 URL: https://issues.apache.org/jira/browse/GERONIMO-4527
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: core, kernel, OpenEJB
Affects Versions: 2.0.3
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh


Because of a number of changes that have occurred in dependencies of Geronimo 
it will no longer build.

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

[jira] Updated: (GERONIMO-4295) Upgrade to Derby 10.4.2.0

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-4295:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Upgrade to Derby 10.4.2.0
> -
>
> Key: GERONIMO-4295
> URL: https://issues.apache.org/jira/browse/GERONIMO-4295
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: dependencies
>Affects Versions: 2.0.3, 2.1.3, 2.2
>Reporter: Donald Woods
>Assignee: Donald Woods
>Priority: Minor
> Fix For: 2.0.4, 2.1.4, 2.2
>
>
> Upgrade to Derby 10.4.2.0, which was released on Sept. 5, 2008.

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

[jira] Updated: (GERONIMO-1807) Remove uses of ObjectName from core server

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-1807:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Remove uses of ObjectName from core server
> --
>
> Key: GERONIMO-1807
> URL: https://issues.apache.org/jira/browse/GERONIMO-1807
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: kernel
>Reporter: Dain Sundstrom
> Fix For: 2.0.4
>
>
> Using the ObjectName class in the core server causes a dependency on the jmx 
> classes.  We are also in the process of moving away from these, but there are 
> still many places that use this class.

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

[jira] Updated: (GERONIMO-4222) Database pool unusable after database unavailable for awhile

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-4222:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Database pool unusable after database unavailable for awhile
> 
>
> Key: GERONIMO-4222
> URL: https://issues.apache.org/jira/browse/GERONIMO-4222
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.0.2, 2.1, 2.1.1, 2.1.2, 2.1.4, 2.2
> Environment: Red Hat Enterprise Linux Server v5.2
> WAS-CE v2.0.0.1, based on Geronimo v2.0.2
>Reporter: David Frahm
>Assignee: Donald Woods
> Fix For: 2.0.4, 2.1.4, 2.2
>
> Attachments: before and after wasce restart.txt, stacktrace.txt
>
>
> I have frequent trouble with my database pool to an AS/400.  The database is 
> taken down every night for backup, and at least once a week the connection 
> pool is unusable after the database comes back up.  Restarting the connection 
> pool makes everything work again. 
> We are new to Geronimo/WAS-CE -- just this one app on one server -- so I 
> don't have anything to compare to.  However, we have had this same issue with 
> a couple 1.x/1.1.x versions before we upgraded to v2.  Also, there are 
> several WebSphere (full WAS, not WAS-CE) apps that do not have this trouble.
> Configuration Info
> Driver: JTOpen v6.1 (com.ibm.as400.access.AS400JDBCDriver)
> Pool Min Size: 0
> Pool Max Size: 100
> Blocking Timeout: 5000
> Idle Timeout: 15

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

[jira] Updated: (GERONIMO-4124) Tomcat jacc usage is messed up

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-4124:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Tomcat jacc usage is messed up
> --
>
> Key: GERONIMO-4124
> URL: https://issues.apache.org/jira/browse/GERONIMO-4124
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0.2, 2.1.1, 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.4, 2.1.4, 2.2
>
>
> Several problems:
> 1. UserDataPermissions are not getting evaluated by jacc due to the check for 
> Subject in handler data.
> 2. Subject is never set into handler data (also  a problem in jetty, dunno 
> about openejb).
> 3. TomcatGeronimoRealm is calling ContextManager.setCallers before permission 
> checks.  This is wrong.

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

[jira] Updated: (GERONIMO-3815) ContextManager.getCurrentContext() throws NullPointerException

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-3815:


Fix Version/s: (was: 2.0.3)
   2.0.4

> ContextManager.getCurrentContext() throws NullPointerException
> --
>
> Key: GERONIMO-3815
> URL: https://issues.apache.org/jira/browse/GERONIMO-3815
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: security
>Affects Versions: 2.0.2, 2.1
>Reporter: Vamsavardhana Reddy
> Fix For: 2.0.4, 2.1.4, 2.2
>
> Attachments: GERONIMO-3815-2.debug.patch, 
> GERONIMO-3815-3.debug.patch, GERONIMO-3815.debug.patch
>
>
> ContextManager.getCurrentContext() is throwing a NullPointerException.  This 
> is observed only when there is heavy load on the application.  Most likely it 
> is a threading issue where one thread is unregistering the subject while 
> another is executing getCurrentContext().  Excerpt from stacktrace given 
> below.
> 
> Caused by: java.lang.NullPointerException
> at 
> org.apache.geronimo.security.ContextManager.getCurrentContext(ContextManager.java:197)
> at 
> org.apache.geronimo.openejb.GeronimoSecurityService.isCallerAuthorized(GeronimoSecurityService.java:101)
> at 
> org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:142)
> at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267)
> at 
> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158)
> at 
> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:321)
> at 
> org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
> at $Proxy16.create(Unknown Source)
> ... 53 more
>  

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

[jira] Updated: (GERONIMO-1842) Dynamically load jars from the WEB-INF/lib directory

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-1842:


Fix Version/s: (was: 2.0.3)
   (was: 1.x)
   2.0.4

> Dynamically load jars from the WEB-INF/lib directory
> 
>
> Key: GERONIMO-1842
> URL: https://issues.apache.org/jira/browse/GERONIMO-1842
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: core
>Reporter: Prasad Kashyap
> Fix For: 2.0.4
>
>
> Currently the server has a hardcoded list of what it expects in the 
> WEB-INF/lib dir. This means that additions/deletion of jars in that directory 
> will not be picked up without actually redeploying that app. This seems like 
> a major irritant.
> The best thing of course would be to dynamically pick up or drop jars from 
> the lib directory as they are added/deleted. 
> But we can, for now, settle for loading/unloading them at an app restart. 
> This should be the bare minimum requirement.

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

[jira] Updated: (GERONIMO-2045) Plugin prerequisites: for DB pools, support DB type/version and table validation

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2045:


Fix Version/s: (was: 2.0.3)
   (was: 1.x)
   2.0.4

> Plugin prerequisites: for DB pools, support DB type/version and table 
> validation
> 
>
> Key: GERONIMO-2045
> URL: https://issues.apache.org/jira/browse/GERONIMO-2045
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: Plugins
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Fix For: 2.0.4
>
>
> More robust database pool prerequisites for plugins:
>  - check that one of a specific set of RDBMS name/version combinations is set 
> for a connection pool prerequisite
>  - check the schema somehow -- e.g. that some table exists, or some query 
> returns an expected value

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

[jira] Updated: (GERONIMO-1829) Service Plans should allow GBean references by interface (vs. by name)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-1829:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Service Plans should allow GBean references by interface (vs. by name)
> --
>
> Key: GERONIMO-1829
> URL: https://issues.apache.org/jira/browse/GERONIMO-1829
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: kernel
>Affects Versions: 1.0
>Reporter: Aaron Mulder
> Fix For: 2.0.4
>
>


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

[jira] Updated: (GERONIMO-2210) Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2210:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
> ---
>
> Key: GERONIMO-2210
> URL: https://issues.apache.org/jira/browse/GERONIMO-2210
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: connector
>Affects Versions: 1.2
>Reporter: Jason Dillon
>Assignee: Anita Kulshreshtha
> Fix For: 2.0.4
>
>
> A few tests failed in non-obvious ways when run under the m2 build.  Need 
> someone who knows these tests better to inspect, resolve and enable the test 
> (remove the test exclusions in the pom).
> The test fails with (on the console):
> {noformat}
> Ignoring connectiondefinition-instance/config-setting ServerUrl (no matching 
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting UserName (no matching 
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting Password (no matching 
> config-property in J2EE DD)
> Geronimo connector deployment plan has admin object with interface 
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the 
> ra.xml does not have a matching adminobject declared.  Deleting this 
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface 
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the 
> ra.xml does not have a matching adminobject declared.  Deleting this 
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface 
> 'javax.jms.Topic' and class 'org.activemq.message.ActiveMQTopic' but the 
> ra.xml does not have a matching adminobject declared.  Deleting this 
> adminobject from the Geronimo plan.
> {noformat}
> And in the surefire report:
> {noformat}
> ---
> Test set: org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest
> ---
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 1.488 sec <<< 
> FAILURE!
> testCreateDatabase(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
>   Time elapsed: 0.66 sec  <<< ERROR!
> java.lang.NullPointerException
>   at 
> org.apache.geronimo.connector.deployment.jsr88.ConnectionDefinition.configure(ConnectionDefinition.java:64)
>   at 
> org.apache.geronimo.connector.deployment.jsr88.ResourceAdapter.setConnectionDefinition(ResourceAdapter.java:111)
>   at 
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateDatabase(Connector15DCBTest.java:114)
> testWriteWithNulls(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
>   Time elapsed: 0.046 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.failNotEquals(Assert.java:282)
>   at junit.framework.Assert.assertEquals(Assert.java:64)
>   at junit.framework.Assert.assertEquals(Assert.java:201)
>   at junit.framework.Assert.assertEquals(Assert.java:207)
>   at 
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testWriteWithNulls(Connector15DCBTest.java:205)
> testCreateJMSResource(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
>   Time elapsed: 0.382 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.failNotEquals(Assert.java:282)
>   at junit.framework.Assert.assertEquals(Assert.java:64)
>   at junit.framework.Assert.assertEquals(Assert.java:201)
>   at junit.framework.Assert.assertEquals(Assert.java:207)
>   at 
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateJMSResource(Connector15DCBTest.java:355)
> testLoadJMSResources(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
>   Time elapsed: 0.38 sec  <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
>   at junit.framework.Assert.fail(Assert.java:47)
>   at junit.framework.Assert.failNotEquals(Assert.java:282)
>   at junit.framework.Assert.assertEquals(Assert.java:64)
>   at junit.framework.Assert.assertEquals(Assert.java:201)
>   at junit.framework.Assert.assertEquals(Assert.java:207)
>   at 
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testLoadJMSResources(Connector15DCBTest.java:479)

[jira] Updated: (GERONIMO-2127) Expose the ability to use Select for Update on CMP entity beans

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2127:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Expose the ability to use Select for Update on CMP entity beans
> ---
>
> Key: GERONIMO-2127
> URL: https://issues.apache.org/jira/browse/GERONIMO-2127
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
> Environment: All
>Reporter: Matt Hogstrom
> Fix For: 2.0.4
>
>
> Currently TranQL supports the generation sql to execute a select for update.  
> Unfortunately, OpenEJB does not expose the ability in the current XSD to 
> support this.  As a result the CMP implementation we have does pass CTS but 
> lacks the ability to deploy an application that is performant and provides 
> for data consistency.
> This improvement will add an attribute into the XSD for OpenEJB so a new 
> attribute will be added  that is an indicator to use a 
> select for update on a query so database locking can be employed.
> Changes will be made to TranQL (Syntax Factories) to create the correct SQL 
> as well as OpenEJB's CMP builders to honor the request.

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

[jira] Updated: (GERONIMO-2990) Axis2: Supports OASIS XML Catalogs 1.1 specification to be used to resolve web service description document (wsdl/xsd)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2990:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Axis2:  Supports OASIS XML Catalogs 1.1 specification to be used to resolve 
> web service description document (wsdl/xsd)
> ---
>
> Key: GERONIMO-2990
> URL: https://issues.apache.org/jira/browse/GERONIMO-2990
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: webservices
>Affects Versions: 2.0-M7
>Reporter: Lin Sun
> Fix For: 2.0.4
>
>
> Per JSR 109, Supports OASIS XML Catalogs 1.1 specification to be used to 
> resolve web service description document (wsdl/xsd) (p47)
> This work is for Axis2 only as CXF already supports it.

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

[jira] Updated: (GERONIMO-3316) warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where.

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-3316:


Fix Version/s: (was: 2.0.3)
   2.0.4

> warn but don't prevent deployment if an ear's manifest cps are messed up, and 
> provide more info on where.
> -
>
> Key: GERONIMO-3316
> URL: https://issues.apache.org/jira/browse/GERONIMO-3316
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M6, 2.0-M7, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 
> 2.1.2, 2.1.3, 2.1.4, 2.2
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 2.0.4, 2.1.4, 2.2
>
>
> DeploymentContext.getCompleteManifestClassPath figures out the whole set of 
> jars in an ear in a modules classpath.  If somethings missing it throws an 
> exception and prevents deployment.  We need a switch to be more lenient, and 
> we need to provide more info when there's a problem on which jar has the 
> problem and how we found it.
> Thanks to David Harbige on the user list for pointing out that this is a big 
> usability problem.

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

[jira] Updated: (GERONIMO-2288) Abstract/Maven repositories install modules incorrectly

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2288:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Abstract/Maven repositories install modules incorrectly
> ---
>
> Key: GERONIMO-2288
> URL: https://issues.apache.org/jira/browse/GERONIMO-2288
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: kernel, Plugins
>Affects Versions: 1.1, 1.1.1, 1.2, 2.0-M6
>Reporter: Aaron Mulder
>Assignee: Aaron Mulder
> Fix For: 2.0.4
>
>
> The repository unpacks a JAR when it installs it only if the Artifact type is 
> "car".  That is incorrect -- it should unpack any module with 
> META-INF/config.ser (which is the logic that we use in other places, such as 
> RepositoryConfigurationStore).  This breaks plugins that don't have the type 
> "car" (such as copying a database pool from server to server).
> The currently handling attempts to be generic by associating a behavior with 
> each file type, though in practice this is only used for type=car.  In the 
> 1.1 branch, I am going to put in a workaround to look up the "car" handler 
> any time we find a META-INF/config.ser (a pretty minimal workaround).
> In trunk, I think we should remove the behavior/type association and instead 
> have a boolean for whether configurations should be unpacked, or an 
> "ArtifactTypeHandler" property specifically for configurations and another 
> one for non-configurations.  I don't see any reason to distinguish based on 
> module type.  Input would be appreciated for the 1.2 resolution.

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

[jira] Updated: (GERONIMO-2290) Percent complete goes over 100% when installing configurations

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2290:


Fix Version/s: (was: 2.0.3)
   2.0.4

> Percent complete goes over 100% when installing configurations
> --
>
> Key: GERONIMO-2290
> URL: https://issues.apache.org/jira/browse/GERONIMO-2290
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, core
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Priority: Critical
> Fix For: 2.0.4
>
>
> Looks like the UnpackArtifactTypeHandler counts the "uncompressed" bytes, 
> whereas the % is based on the content size returned by the server for the 
> download (the "compressed" byte count).
> Probably should use an InputStream between the download stream and the ZIP 
> stream that performs the count on read(byte[],int,int) and them use that 
> count instead of the uncompressed count.

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

[jira] Updated: (GERONIMO-2128) Allow user to specify the Isolation Level for a CMP bean's SQL access

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2128:


Fix Version/s: (was: 2.0.3)
   (was: 1.x)
   2.0.4

> Allow user to specify the Isolation Level for a CMP bean's SQL access
> -
>
> Key: GERONIMO-2128
> URL: https://issues.apache.org/jira/browse/GERONIMO-2128
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Matt Hogstrom
> Fix For: 2.0.4
>
>
> Currently CMP beans all execute in the default isolation level of the 
> datasource.  This means that in many situations higher level locks are 
> required for the database access than are required.  This improvement will 
> allow the user to specify a new attribute on a CMP entity bean 
>  that will be the isolation level used for database access 
> on this entity bean.  This will require updates to OpenEJB and TranQL.

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

[jira] Updated: (GERONIMO-2424) Add config.xml support for ConfigurationAwareReference

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2424:


Fix Version/s: (was: 2.0.3)
   (was: 1.x)
   2.0.4

> Add config.xml support for ConfigurationAwareReference
> --
>
> Key: GERONIMO-2424
> URL: https://issues.apache.org/jira/browse/GERONIMO-2424
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: common, kernel, naming
>Affects Versions: 1.1.1
>Reporter: Aaron Mulder
> Fix For: 2.0.4
>
>
> It would be nice if a GBean property of type ConfigurationAwareReference 
> could be overridden in config.xml.  This seems reasonable in that a 
> ConfigurationAwareReference essentially holds an Artifact and a set of 
> AbstractNameQueries, both of which are independently representable as 
> Strings.  Presently it looks like there's a PropertyEditor for 
> AbstractNameQuery but not for Artifact or ConfigurationAwareReference.  Not 
> sure what XML editors might be available.
> (This is because some plugin gbeans use properties of type 
> ConfigurationAwareReference to refer to e.g. a database connection pool, 
> where the pool name was configured in some XML file processed by the plugin's 
> deployer component.)

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

[jira] Resolved: (GERONIMO-1354) The var/config.xml file is always re-written even if no attribute changes are made by the user

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-1354.
-

Resolution: Won't Fix
  Assignee: Jay D. McHugh

There has been no movement on this for some time.

And, it would appear that either everyone has resigned themselves
to the fact that you cannot simply edit the config.xml - or - few people
feel that there is a good reason to do so.

If there is sufficient interest, a new JIRA should be opened on a more
current/active branch.

> The var/config.xml file is always re-written even if no attribute changes are 
> made by the user
> --
>
> Key: GERONIMO-1354
> URL: https://issues.apache.org/jira/browse/GERONIMO-1354
> Project: Geronimo
>  Issue Type: Wish
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown, usability
>Affects Versions: 1.0
>Reporter: John Sisson
>Assignee: Jay D. McHugh
> Fix For: 2.0.3
>
>
> This means the user can never edit the config.xml file while Geronimo is 
> running.  The user has to shut down Geronimo and then make their changes and 
> therefore the amount of time to implement a change is longer than needed.
> For 1.0 I will add some extra text to the warning in the top of the 
> config.xml file ( see 
> org.apache.geronimo.system.configuration.ServerOverride) that tells the user 
> not to edit the file whilst Geronimo is running.  

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

[jira] Closed: (GERONIMO-1354) The var/config.xml file is always re-written even if no attribute changes are made by the user

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-1354.
---


> The var/config.xml file is always re-written even if no attribute changes are 
> made by the user
> --
>
> Key: GERONIMO-1354
> URL: https://issues.apache.org/jira/browse/GERONIMO-1354
> Project: Geronimo
>  Issue Type: Wish
>  Security Level: public(Regular issues) 
>  Components: startup/shutdown, usability
>Affects Versions: 1.0
>Reporter: John Sisson
>Assignee: Jay D. McHugh
> Fix For: 2.0.3
>
>
> This means the user can never edit the config.xml file while Geronimo is 
> running.  The user has to shut down Geronimo and then make their changes and 
> therefore the amount of time to implement a change is longer than needed.
> For 1.0 I will add some extra text to the warning in the top of the 
> config.xml file ( see 
> org.apache.geronimo.system.configuration.ServerOverride) that tells the user 
> not to edit the file whilst Geronimo is running.  

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

[jira] Resolved: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-1907.
-

Resolution: Won't Fix
  Assignee: Jay D. McHugh  (was: Rakesh Midha)

When an app is undeployed (as part of a redeploy) any other apps that depend on 
it are stopped.

Trying to track down all apps that depend on the current app so that they can 
be automatically restarted is too much effort to expend in the 2.0.x branch.

If there is sufficient interest - a new JIRA should be opened in a more 
current/active branch.

> Deploy command should redeploy if the app is already deployed
> -
>
> Key: GERONIMO-1907
> URL: https://issues.apache.org/jira/browse/GERONIMO-1907
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment, usability
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: Jay D. McHugh
>Priority: Critical
> Fix For: 2.0.3
>
> Attachments: redeploy.patch
>
>
> Attached patch, and changing fix version to 1.2. Also unassigning so that 
> committers can review and update.

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

[jira] Closed: (GERONIMO-1907) Deploy command should redeploy if the app is already deployed

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-1907.
---


> Deploy command should redeploy if the app is already deployed
> -
>
> Key: GERONIMO-1907
> URL: https://issues.apache.org/jira/browse/GERONIMO-1907
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: deployment, usability
>Affects Versions: 1.1
>Reporter: Aaron Mulder
>Assignee: Jay D. McHugh
>Priority: Critical
> Fix For: 2.0.3
>
> Attachments: redeploy.patch
>
>
> Attached patch, and changing fix version to 1.2. Also unassigning so that 
> committers can review and update.

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

[jira] Commented: (GERONIMO-4368) OpenJPA can't find org.postgresql.Driver

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641431#action_12641431
 ] 

Jay D. McHugh commented on GERONIMO-4368:
-

I believe that what Donald meant when he said to copy the newer OpenJPA files 
"over top" the old ones was to replace them - change the new file names so that 
they overwrite the old ones.

Not to remove the 1.0.3 version and install a 1.2.0 version.

There are other areas within Geronimo that will still be looking for the old 
version.

> OpenJPA can't find org.postgresql.Driver
> 
>
> Key: GERONIMO-4368
> URL: https://issues.apache.org/jira/browse/GERONIMO-4368
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1.3
> Environment: Linux gentoo, JDK IBM 1.6, 
>Reporter: Michał Kudła
>Priority: Blocker
>
> Tutorial from 
> http://www.jaceklaskowski.pl/wiki/Aplikacja_Java_EE_5_z_MDB_z_JPA_w_trybie_JTA_i_PostgreSQL_w_Apache_Geronimo_2
> http://www.jaceklaskowski.pl/aplikacje/mdb-jpa-jta-postgresql-geronimo.zip
> works fine under geronimo 2.1 but not work under 2.1.3.
> [EMAIL PROTECTED] ~/Programy/geronimo-tomcat6-javaee5-2.1.3/bin $ 
> ./geronimo.sh run -vv
> Using GERONIMO_BASE:   /home/m1k0/Programy/geronimo-tomcat6-javaee5-2.1.3 
>
> Using GERONIMO_HOME:   /home/m1k0/Programy/geronimo-tomcat6-javaee5-2.1.3 
>
> Using GERONIMO_TMPDIR: var/temp   
>
> Using JRE_HOME:/opt/ibm-jdk-bin-1.6.0.2/jre   
>
> 13:24:43,096 DEBUG [BasicKernel] Starting boot
>
> 
> 13:30:06,159 INFO  [DirectoryHotDeployer] Deploying TicketServiceEAR.ear
> 13:30:06,687 INFO  [config] Configuring Service(id=Default Stateless 
> Container, type=Container, provider-id=Default Stateless Container)
> 13:30:06,688 INFO  [config] Configuring Service(id=Default Stateful 
> Container, type=Container, provider-id=Default Stateful Container)  
> 13:30:06,691 INFO  [config] Configuring Service(id=Default BMP Container, 
> type=Container, provider-id=Default BMP Container)
> 13:30:06,691 INFO  [config] Configuring Service(id=Default CMP Container, 
> type=Container, provider-id=Default CMP Container)
> 13:30:06,692 INFO  [config] Configuring app: 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear  
>  
> 13:30:06,778 INFO  [OpenEJB] Auto-deploying ejb TicketServiceBean: 
> EjbDeployment(deployment-id=TicketServiceMDB.jar/TicketServiceBean)  
> 13:30:06,783 INFO  [config] Loaded Module: 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear  
>
> 13:30:08,259 INFO  [config] Configuring 
> Service(id=jms-resources.jms-resources-javax.jms.MessageListener, 
> type=Container, provider-id=Default MDB Container)
> 13:30:08,260 INFO  [service] Creating 
> Container(id=jms-resources.jms-resources-javax.jms.MessageListener)   
> 
> 13:30:08,312 INFO  [KernelContextGBean] bound gbean 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAConnectionFactory=TicketConnectionFactory,JCAResource=jms-resources,ResourceAdapter=jms-resources,ResourceAdapterModule=jms-resources,j2eeType=JCAManagedConnectionFactory,name=TicketConnectionFactory
>  at name 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAManagedConnectionFactory/TicketConnectionFactory
>
> 13:30:08,317 INFO  [KernelContextGBean] bound gbean 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAResource=jms-resources,ResourceAdapter=jms-resources,ResourceAdapterModule=jms-resources,j2eeType=JCAAdminObject,name=TicketQueue
>  at name 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAAdminObject/TicketQueue   
>   
>  
> 13:30:08,414 INFO  [KernelContextGBean] bound gbean 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear?J2EEApplication=pl.jaceklaskowski.ticketservice/TicketServiceEAR/1.0/ear,JCAConnectionFactory=jdbc/postgres,JCAResource=postgresql,ResourceAdapter=postgresql,ResourceAdapterModule=postgresql,j2eeType=JCAManagedConnectionFactory,name=jdbc/postgres
>  at name 
> pl.jaceklaskowski.ticketservice/TicketServiceEAR/JCAManagedConnectionFactory/jdbc/postgres
>   
> 13:30:08,416 INFO  [startup] Assembling app: 
> /home/m1k0/Programy/geron

[jira] Closed: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3921.
---


Jetty was not an issue.

They did not have the same check for apps deployed to the root context.

> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.3, 2.1.1, 2.2
>
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Commented: (GERONIMO-4150) Tutorials - Developing a JAX-WS POJO Web Service

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-4150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609972#action_12609972
 ] 

Jay D. McHugh commented on GERONIMO-4150:
-

I went through the tutorial (up through the web client) and everything went 
fine.

The one problem I saw was that the screen shots showed different conversion
methods than the ones discussed in the tutorial (the screenshots showed 
temperature conversions).

Otherwise, an easy to follow working tutorial.  Thanks for putting it together.

> Tutorials - Developing a JAX-WS POJO Web Service
> 
>
> Key: GERONIMO-4150
> URL: https://issues.apache.org/jira/browse/GERONIMO-4150
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: documentation
>Affects Versions: 2.1, 2.1.1
>Reporter: Sainath Chowdary
>Assignee: Shiva Kumar H R
>
> Geronimo v2.1 documentation, Tutorials section.
> Develop a tutorial for "Building a JAX-WS POJO Web Service" addressing the 
> following common topics (use this list as the initial guideline). This 
> document should also match the styling used in the existing tutorials.
> *  Setting up Eclipse for Application development
> * Sample application overview
>   identify the different components
> * Prerequisites
>   external resources (i.e. databases, connection pools, JMS queues, etc)
> * Sample app creation
>   breakdown into multiple bullets
> * Deploy and Test the application
> See http://cwiki.apache.org/GMOxDOC21/tutorials.html

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

[jira] Resolved: (GERONIMO-4108) Upgrade Dojo to version 1.1.1

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-4108.
-

   Resolution: Fixed
Fix Version/s: 2.2

Only changed over in trunk.

Geronimo 2.1.x is still using Dojo 1.0.2 - Is there anyone who thinks we need 
to upgrade it as well?


> Upgrade Dojo to version 1.1.1
> -
>
> Key: GERONIMO-4108
> URL: https://issues.apache.org/jira/browse/GERONIMO-4108
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.2
>
>
> Dojo version 1.1.1 has been released.
> It is completely backwards compatible with the current 1.1.0 version Geronimo 
> is currently using.

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

[jira] Created: (GERONIMO-4108) Upgrade Dojo to version 1.1.1

[Jay D. McHugh (JIRA)]

Upgrade Dojo to version 1.1.1
-

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


Dojo version 1.1.1 has been released.

It is completely backwards compatible with the current 1.1.0 version Geronimo 
is currently using.

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

[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602734#action_12602734
 ] 

Jay D. McHugh commented on GERONIMO-3921:
-

Has anyone checked to confirm that this works in Jetty?

If not, I'll check in the next few days and close this issue.

> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1.1, 2.2
>
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Resolved: (GERONIMO-3460) EAR will not display properly at the "/" context root (tomcat only)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3460.
-

Resolution: Duplicate

Duplicate of Geronimo-3921.

I missed this JIRA when I created the other one.

> EAR will not display properly at the "/" context root (tomcat only)
> ---
>
> Key: GERONIMO-3460
> URL: https://issues.apache.org/jira/browse/GERONIMO-3460
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, Tomcat
>Affects Versions: 2.0.1
> Environment: G v 2.0.1 (tomcat), windows xp
>Reporter: Viet Hung Nguyen
>Assignee: Jay D. McHugh
>Priority: Critical
> Fix For: 2.0.x
>
> Attachments: college_fest.ear
>
>
> When an EAR is deployed at the "/" context root (using tomcat) there are 
> problems viewing the webapp. These problems exists under these conditions:
> 1. EAR never works on the initial deploy
> 2. EAR never works on server startup
> The only way I have gotten these EARs to work is to:
> 1. change the context-root to something not "/" (but I shouldn't have to do 
> this)
> 2. redeploy the EAR
> 3. restart the EAR
> 4. undeploy, then deploy the EAR
> To reproduce the problem, use the attached EAR, uninstall any WAR that is 
> using  "/" as its context-root, deploy the EAR and visit 
> http://localhost:8080/
> Note: When the WAR inside the EAR is deployed, everything works fine. 

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

[jira] Closed: (GERONIMO-3460) EAR will not display properly at the "/" context root (tomcat only)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3460.
---


> EAR will not display properly at the "/" context root (tomcat only)
> ---
>
> Key: GERONIMO-3460
> URL: https://issues.apache.org/jira/browse/GERONIMO-3460
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, Tomcat
>Affects Versions: 2.0.1
> Environment: G v 2.0.1 (tomcat), windows xp
>Reporter: Viet Hung Nguyen
>Assignee: Jay D. McHugh
>Priority: Critical
> Fix For: 2.0.x
>
> Attachments: college_fest.ear
>
>
> When an EAR is deployed at the "/" context root (using tomcat) there are 
> problems viewing the webapp. These problems exists under these conditions:
> 1. EAR never works on the initial deploy
> 2. EAR never works on server startup
> The only way I have gotten these EARs to work is to:
> 1. change the context-root to something not "/" (but I shouldn't have to do 
> this)
> 2. redeploy the EAR
> 3. restart the EAR
> 4. undeploy, then deploy the EAR
> To reproduce the problem, use the attached EAR, uninstall any WAR that is 
> using  "/" as its context-root, deploy the EAR and visit 
> http://localhost:8080/
> Note: When the WAR inside the EAR is deployed, everything works fine. 

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

[jira] Assigned: (GERONIMO-3460) EAR will not display properly at the "/" context root (tomcat only)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh reassigned GERONIMO-3460:
---

Assignee: Jay D. McHugh

> EAR will not display properly at the "/" context root (tomcat only)
> ---
>
> Key: GERONIMO-3460
> URL: https://issues.apache.org/jira/browse/GERONIMO-3460
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment, Tomcat
>Affects Versions: 2.0.1
> Environment: G v 2.0.1 (tomcat), windows xp
>Reporter: Viet Hung Nguyen
>Assignee: Jay D. McHugh
>Priority: Critical
> Fix For: 2.0.x
>
> Attachments: college_fest.ear
>
>
> When an EAR is deployed at the "/" context root (using tomcat) there are 
> problems viewing the webapp. These problems exists under these conditions:
> 1. EAR never works on the initial deploy
> 2. EAR never works on server startup
> The only way I have gotten these EARs to work is to:
> 1. change the context-root to something not "/" (but I shouldn't have to do 
> this)
> 2. redeploy the EAR
> 3. restart the EAR
> 4. undeploy, then deploy the EAR
> To reproduce the problem, use the attached EAR, uninstall any WAR that is 
> using  "/" as its context-root, deploy the EAR and visit 
> http://localhost:8080/
> Note: When the WAR inside the EAR is deployed, everything works fine. 

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

[jira] Closed: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3931.
---


> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>Assignee: Jay D. McHugh
> Fix For: 2.1.2, 2.1.x, 2.2
>
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Resolved: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3931.
-

   Resolution: Fixed
Fix Version/s: 2.2
   2.1.x
   2.1.2

No one updated the JIRA with any new information.

This appears to have already been fixed.

> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>Assignee: Jay D. McHugh
> Fix For: 2.1.2, 2.1.x, 2.2
>
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590612#action_12590612
 ] 

Jay D. McHugh commented on GERONIMO-3931:
-

Also working in branches/2.1.1.

If someone can show that this is a problem, please update the JIRA.

Otherwise, I'll close it on 4/21 at about 5:00 PM CDT.

> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Assigned: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh reassigned GERONIMO-3931:
---

Assignee: Jay D. McHugh

> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>Assignee: Jay D. McHugh
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590587#action_12590587
 ] 

Jay D. McHugh commented on GERONIMO-3931:
-

It also works in branches/2.1 (2.1.2-Snapshot) which probably means that it 
works in 2.1.1

I will check branches/2.1.1 just to make sure.

> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Commented: (GERONIMO-3931) Unable to delete a datasource from administrative console

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590274#action_12590274
 ] 

Jay D. McHugh commented on GERONIMO-3931:
-

This appears to be fixed in trunk.

I will check to see if it is corrected in 2.1.1 tomorrow (or possibly later 
tonight).

> Unable to delete a datasource from administrative console
> -
>
> Key: GERONIMO-3931
> URL: https://issues.apache.org/jira/browse/GERONIMO-3931
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.1
> Environment: Windows XP, AG2.1
>Reporter: Ashish Jain
>
> While trying to delete a datasource from Administrative console I get the 
> following error in the command prompt 
> 13:01:47,000 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
>  In geronimo.log I get the following error
> 13:02:09,343 ERROR [DatabasePoolPortlet] Undeployment unsuccessful!
> 13:02:10,359 INFO  [SupportedModesServiceImpl] Portlet mode 'edit' not found 
> for portletId: '/system-database.DBWizard!1134683811|0'
> Steps to recreate the issue
> 1) Create a DerbyEmbedded database pool.
> 2) Delete the pool
>  
> Workaround is to manually remove the entries from config.xml  and repository.

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

[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579991#action_12579991
 ] 

Jay D. McHugh commented on GERONIMO-3921:
-

Jarek,

I just checked the Jetty 'wrapper' around the getContext method and it does not 
have the same
check for the first character not being a '/'.

So it _should_ be functioning correctly.

> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578907#action_12578907
 ] 

Jay D. McHugh commented on GERONIMO-3921:
-

Fixed it too fast.
Forgot the parens on the length function to the fix on trunk (branches/2.1 was 
correct).

Sending
plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java
Transmitting file data .
Committed revision 637232.


> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578906#action_12578906
 ] 

Jay D. McHugh commented on GERONIMO-3921:
-

Fix committed to branches/2.1

Sending
plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java
Transmitting file data .
Committed revision 637227.

> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Commented: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578903#action_12578903
 ] 

Jay D. McHugh commented on GERONIMO-3921:
-

Fix committed to trunk.

Sending
plugins/tomcat/geronimo-tomcat6-builder/src/main/java/org/apache/geronimo/tomcat/deployment/TomcatModuleBuilder.java
Transmitting file data .
Committed revision 637223.


> getContextRoot() returns forward slash rather than empty string for apps 
> deployed to root context
> -
>
> Key: GERONIMO-3921
> URL: https://issues.apache.org/jira/browse/GERONIMO-3921
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1, 2.1.1, 2.2
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> An app deployed to the root context should have "" returned by 
> getContextRoot() - On Tomcat, we are returning "/".
> dcherk wrote:
> > I am deploying my war file into the root context with the following
> > deployment plan:
> > --
> > http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> > xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> > xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> > xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
> >   ...
> >   
> >   ...
> > 
> > --
> > 
> > The application starts up properly, and responds on http://localhost, as
> > expected.
> > 
> > However, when I examine request.getContextPath(), I get a forward slash:
> > "/".
> > 
> > This is incorrect, as far as I can tell.  According to the API
> > (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> > --
> > For servlets in the default (root) context, this method
> > [HttpServletRequest.html.getContextPath()] returns "".
> > --
> > 

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

[jira] Created: (GERONIMO-3921) getContextRoot() returns forward slash rather than empty string for apps deployed to root context

[Jay D. McHugh (JIRA)]

getContextRoot() returns forward slash rather than empty string for apps 
deployed to root context
-

 Key: GERONIMO-3921
 URL: https://issues.apache.org/jira/browse/GERONIMO-3921
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Tomcat
Affects Versions: 2.1, 2.0.2, 2.0.1, 2.0, 2.0.x, 2.1.1, 2.2
Reporter: Jay D. McHugh
Assignee: Jay D. McHugh


An app deployed to the root context should have "" returned by getContextRoot() 
- On Tomcat, we are returning "/".

dcherk wrote:
> I am deploying my war file into the root context with the following
> deployment plan:
> --
> http://geronimo.apache.org/xml/ns/j2ee/web-2.0";
> xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";
> xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.2";
> xmlns:security="http://geronimo.apache.org/xml/ns/security-1.2";>
>   ...
>   
>   ...
> 
> --
> 
> The application starts up properly, and responds on http://localhost, as
> expected.
> 
> However, when I examine request.getContextPath(), I get a forward slash:
> "/".
> 
> This is incorrect, as far as I can tell.  According to the API
> (http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getContextPath()):
> --
> For servlets in the default (root) context, this method
> [HttpServletRequest.html.getContextPath()] returns "".
> --
> 

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

[jira] Closed: (GERONIMO-3855) PortletSecurityException in Plugins portlet

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3855.
---

   Resolution: Fixed
Fix Version/s: 2.2
   2.1.1
   2.1

Committed to both branches/2.1 and trunk (2.0 still uses Pluto 1.0).

Everywhere that I checked has worked, but please take a second to test.

> PortletSecurityException in Plugins portlet
> ---
>
> Key: GERONIMO-3855
> URL: https://issues.apache.org/jira/browse/GERONIMO-3855
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Paul McMahan
>Assignee: Jay D. McHugh
> Fix For: 2.1, 2.1.1, 2.2
>
>
> Cannot take any actions in the Plugins portlet.
> Recreate:
> Go to the Plugins portlet in the admin console
> Click any action-- "Update Repository List" or "Add Repository" or "Export a 
> Plugin" or "Assemble a Server"
> Note the exception:
> javax.servlet.ServletException: javax.portlet.PortletSecurityException: No 
> Supported
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> root cause
> javax.portlet.PortletSecurityException: No Supported
>   
> org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67)
>   
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261)
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

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

[jira] Commented: (GERONIMO-3855) PortletSecurityException in Plugins portlet

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570540#action_12570540
 ] 

Jay D. McHugh commented on GERONIMO-3855:
-

Committed to branches/2.1
Sendingpom.xml
Deleting   repository/org/apache/pluto/1.2.0-G601060.README.TXT
Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT
Adding repository/org/apache/pluto/geronimo-3855.patch
Deleting   repository/org/apache/pluto/pluto-container/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-container/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-container/1.2.0-G601061/pluto-container-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar
Deleting   
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060
Deleting   repository/org/apache/pluto/pluto-taglib/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar
Transmitting file data 
Committed revision 629312.


> PortletSecurityException in Plugins portlet
> ---
>
> Key: GERONIMO-3855
> URL: https://issues.apache.org/jira/browse/GERONIMO-3855
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Paul McMahan
>Assignee: Jay D. McHugh
>
> Cannot take any actions in the Plugins portlet.
> Recreate:
> Go to the Plugins portlet in the admin console
> Click any action-- "Update Repository List" or "Add Repository" or "Export a 
> Plugin" or "Assemble a Server"
> Note the exception:
> javax.servlet.ServletException: javax.portlet.PortletSecurityException: No 
> Supported
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> root cause
> javax.portlet.PortletSecurityException: No Supported
>   
> org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67)
>   
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261)
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

-- 
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: (GERONIMO-3855) PortletSecurityException in Plugins portlet

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570527#action_12570527
 ] 

jaydm edited comment on GERONIMO-3855 at 2/19/08 5:24 PM:
--

It appears that Pluto is not currently performing any special handling of 
multipage portlets over https.

So, based on some posts on the Pluto mailing lists these changes simply block 
the exception that was
being thrown in the setSecure() method.

Committed on trunk:
Sendingpom.xml
Deleting   repository/org/apache/pluto/1.2.0-G601060.README.TXT
Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT
Adding repository/org/apache/pluto/geronimo-3855.patch
Deleting   repository/org/apache/pluto/pluto-container/1.2.0-G601060
Deleting   repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar
Deleting   
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060
Adding 
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-taglib/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar
Transmitting file data 
Committed revision 629300.


  was (Author: jaydm):
It appears that Pluto is not currently performing any special handling of 
multipage portlets over https.

So, based on some posts on the Pluto mailing lists these changes simply block 
the exception that was
being thrown in the setSecure() method.

Sendingpom.xml
Deleting   repository/org/apache/pluto/1.2.0-G601060.README.TXT
Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT
Adding repository/org/apache/pluto/geronimo-3855.patch
Deleting   repository/org/apache/pluto/pluto-container/1.2.0-G601060
Deleting   repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar
Deleting   
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060
Adding 
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-taglib/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar
Transmitting file data 
Committed revision 629300.

  
> PortletSecurityException in Plugins portlet
> ---
>
> Key: GERONIMO-3855
> URL: https://issues.apache.org/jira/browse/GERONIMO-3855
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Paul McMahan
>Assignee: Jay D. McHugh
>
> Cannot take any actions in the Plugins portlet.
> Recreate:
> Go to the Plugins portlet in the admin console
> Click any action-- "Update Repository List" or "Add Repository" or "Export a 
> Plugin" or "Assemble a Server"
> Note the exception:
> javax.servlet.ServletExcep

[jira] Commented: (GERONIMO-3855) PortletSecurityException in Plugins portlet

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570527#action_12570527
 ] 

Jay D. McHugh commented on GERONIMO-3855:
-

It appears that Pluto is not currently performing any special handling of 
multipage portlets over https.

So, based on some posts on the Pluto mailing lists these changes simply block 
the exception that was
being thrown in the setSecure() method.

Sendingpom.xml
Deleting   repository/org/apache/pluto/1.2.0-G601060.README.TXT
Adding repository/org/apache/pluto/1.2.0-G601061.README.TXT
Adding repository/org/apache/pluto/geronimo-3855.patch
Deleting   repository/org/apache/pluto/pluto-container/1.2.0-G601060
Deleting   repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-api/1.2.0-G601061/pluto-descriptor-api-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-descriptor-impl/1.2.0-G601061/pluto-descriptor-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver/1.2.0-G601061/pluto-portal-driver-1.2.0-G601061.jar
Deleting   
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601060
Adding 
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-portal-driver-impl/1.2.0-G601061/pluto-portal-driver-impl-1.2.0-G601061.jar
Deleting   repository/org/apache/pluto/pluto-taglib/1.2.0-G601060
Adding repository/org/apache/pluto/pluto-taglib/1.2.0-G601061
Adding  (bin)  
repository/org/apache/pluto/pluto-taglib/1.2.0-G601061/pluto-taglib-1.2.0-G601061.jar
Transmitting file data 
Committed revision 629300.


> PortletSecurityException in Plugins portlet
> ---
>
> Key: GERONIMO-3855
> URL: https://issues.apache.org/jira/browse/GERONIMO-3855
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Paul McMahan
>Assignee: Jay D. McHugh
>
> Cannot take any actions in the Plugins portlet.
> Recreate:
> Go to the Plugins portlet in the admin console
> Click any action-- "Update Repository List" or "Add Repository" or "Export a 
> Plugin" or "Assemble a Server"
> Note the exception:
> javax.servlet.ServletException: javax.portlet.PortletSecurityException: No 
> Supported
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> root cause
> javax.portlet.PortletSecurityException: No Supported
>   
> org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67)
>   
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261)
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

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

[jira] Assigned: (GERONIMO-3855) PortletSecurityException in Plugins portlet

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh reassigned GERONIMO-3855:
---

Assignee: Jay D. McHugh

> PortletSecurityException in Plugins portlet
> ---
>
> Key: GERONIMO-3855
> URL: https://issues.apache.org/jira/browse/GERONIMO-3855
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Paul McMahan
>Assignee: Jay D. McHugh
>
> Cannot take any actions in the Plugins portlet.
> Recreate:
> Go to the Plugins portlet in the admin console
> Click any action-- "Update Repository List" or "Add Repository" or "Export a 
> Plugin" or "Assemble a Server"
> Note the exception:
> javax.servlet.ServletException: javax.portlet.PortletSecurityException: No 
> Supported
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:116)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> root cause
> javax.portlet.PortletSecurityException: No Supported
>   
> org.apache.pluto.driver.services.container.PortletURLProviderImpl.setSecure(PortletURLProviderImpl.java:67)
>   
> org.apache.pluto.core.PortletContainerImpl.doAction(PortletContainerImpl.java:261)
>   
> org.apache.pluto.driver.PortalDriverServlet.doGet(PortalDriverServlet.java:112)
>   
> org.apache.pluto.driver.PortalDriverServlet.doPost(PortalDriverServlet.java:158)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
>   javax.servlet.http.HttpServlet.service(HttpServlet.java:806)

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

[jira] Commented: (GERONIMO-3596) Unintuitive workings of the MySQL DBPool deployment wizard

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562347#action_12562347
 ] 

Jay D. McHugh commented on GERONIMO-3596:
-

Committed a version change for the tranql wrappers in 2.0.3+.

Sendingpom.xml
Transmitting file data .
Committed revision 615101.

Tested the creation of a mysql database pool - the 'url' prompt is gone now.


> Unintuitive workings of the MySQL DBPool deployment wizard
> --
>
> Key: GERONIMO-3596
> URL: https://issues.apache.org/jira/browse/GERONIMO-3596
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector, databases, deployment
>Affects Versions: 2.0.2
> Environment: ogre% uname -a
> FreeBSD ogre 7.0-BETA2 FreeBSD 7.0-BETA2 #4: Sat Nov 10 15:29:36 CET 2007 
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OGRE  amd64
> ogre% java -version
> java version "1.6.0_02-p2"
> Java(TM) SE Runtime Environment (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 1.6.0_02-p2-root_04_nov_2007_14_03-b00, mixed mode)
> Nothing else. I don't think it matters at all for this bug report anyway.
>Reporter: Jesper Louis Andersen
>Assignee: David Jencks
> Fix For: 2.1
>
> Attachments: tranql-connector-mysql-local-1.2-SNAPSHOT.rar
>
>
> There is an unintuitive gotcha hidden in the DBPool wizard for the MySQL (and 
> probably also the MySQL-XA) driver. It manifests itself
> with a NullPointerException when trying to connect to a database. See for 
> instance the following mail:
> http://spteam-lists.blogspot.com/2007/11/re-apache-geronimo-202-and-mysql-data.html
> The reason is that if you DON'T fill out the URL field, you get the following 
> deployment plan:
> 
> 
> http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";>
>  xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>
> 
> console.dbpool
> cxnet
> 1.0
> rar
> 
> 
> 
> mysql
> mysql-connector-java
> 5.1.5
> jar
> 
> 
> 
> 
> 
> 
> 
> javax.sql.DataSource
> 
> cxnet
>  name="DatabaseName">foo
>  name="Password">foo
>  name="UserName">foo
> 
> 
> 
> 
> 10
> 0
> 
> 
> 
> 
> 
> 
> 
> 
> +
> Notice the Empty URL parameter. Quick workaround: Supply the URL parameter or 
> use the 'show plan' feature and add the URL in
> the plan.
> Steps to reproduce:
> 1. Add a mysql-connector-java JAR to the library section. I used 5.1.5 as a 
> version, but it also fails with 5.0.8 and 3.1.14.
> 2. Click Database Pools -> Wizard -> choose 'foo' and MySQL as driver
> 3. Enter the fields: pool name, database driver, port number, user name, 
> server name, database name, password and confirm password 
> take care NOT to enter the URL. 
> 4. Now click 'show plan'. It this point it should be obvious that we are 
> trying to deploy a plan without an URL.
> The idea for a fix:
> 1. Gather fields from input.
> 2. If URL is empty, stitch together one from the other parameters.
> 3. Use the constructed URL.
> And do take care to report this back to the guy in the linked mail above ;)

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

[jira] Closed: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3450.
---


> Unable to Run Pluto 1.1 on Geronimo 2.0
> ---
>
> Key: GERONIMO-3450
> URL: https://issues.apache.org/jira/browse/GERONIMO-3450
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M2
> Environment: Operating System : Windows 2k3
> Pluto Version: 1.1.0
> Geronimo with Jetty Version   2.0.1 
>Reporter: Ramesh B
> Fix For: 2.0.x, 2.1
>
> Attachments: geronimo-web.xml, geronimo.log
>
>
> Hi,
> I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on 
> geronimo with jetty 2.0.1.
> For this I have done the following steps:
> 1) I've added the following additional jars to common libs before deployment:
> *  pluto-container-1.1.0.jar
> * pluto-descriptor-api-1.1.0.jar
> * pluto-descriptor-impl-1.1.0.jar
> * pluto-taglib-1.1.0.jar
> * xalan 2.6.0
> 2) I've modified the castor.properties for pluto/web-inf/classes and set all 
> parameters to false.
> 3) i've added a geronimo-web.xml to the /web-inf folder.
> I created a war of the pluto folder. however while deploying it it gives the 
> following error:
> 3582: 11:02:34,501 ERROR [log] Nested in 
> org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected 
> exception parsing XML document from ServletContext resource 
> [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is 
> java.lang.IllegalArgumentException: Class 
> [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
> NamespaceHandler interface:
> After throwing this error on the console it shows as successfully deployed 
> and successfully running.
> However when i'm trying to access the pluto portal, it says service 
> unavailable.
> Please help me with this problem.

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

[jira] Resolved: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3450.
-

Resolution: Invalid

See Ramesh's comment.

> Unable to Run Pluto 1.1 on Geronimo 2.0
> ---
>
> Key: GERONIMO-3450
> URL: https://issues.apache.org/jira/browse/GERONIMO-3450
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 2.0-M2
> Environment: Operating System : Windows 2k3
> Pluto Version: 1.1.0
> Geronimo with Jetty Version   2.0.1 
>Reporter: Ramesh B
> Fix For: 2.0.x, 2.1
>
> Attachments: geronimo-web.xml, geronimo.log
>
>
> Hi,
> I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on 
> geronimo with jetty 2.0.1.
> For this I have done the following steps:
> 1) I've added the following additional jars to common libs before deployment:
> *  pluto-container-1.1.0.jar
> * pluto-descriptor-api-1.1.0.jar
> * pluto-descriptor-impl-1.1.0.jar
> * pluto-taglib-1.1.0.jar
> * xalan 2.6.0
> 2) I've modified the castor.properties for pluto/web-inf/classes and set all 
> parameters to false.
> 3) i've added a geronimo-web.xml to the /web-inf folder.
> I created a war of the pluto folder. however while deploying it it gives the 
> following error:
> 3582: 11:02:34,501 ERROR [log] Nested in 
> org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected 
> exception parsing XML document from ServletContext resource 
> [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is 
> java.lang.IllegalArgumentException: Class 
> [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the 
> NamespaceHandler interface:
> After throwing this error on the console it shows as successfully deployed 
> and successfully running.
> However when i'm trying to access the pluto portal, it says service 
> unavailable.
> Please help me with this problem.

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

[jira] Closed: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3549.
---


> Potential vulnerability in Apache Tomcat Webdav servlet
> ---
>
> Key: GERONIMO-3549
> URL: https://issues.apache.org/jira/browse/GERONIMO-3549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> Subject:  [SECURITY] Potential vulnerability in Apache Tomcat Webdav 
> servlet
> Date: Thu, 18 Oct 2007 13:40:24 -0400
> From: Kevan Miller <[EMAIL PROTECTED]>
> Reply-To: dev@geronimo.apache.org
> To:   Geronimo Dev 
> The Geronimo project has learned of a security vulnerability in the 
> Apache Tomcat Webdav Servlet implementation. If you use a Tomcat 
> configuration of Geronimo and configure a write-enabled Webdav servlet, 
> you may be affected by this vulnerability. If you do not configure the 
> Webdav servlet or configure read-only Webdav servlets, you are not 
> impacted by this vulnerability. Jetty configurations of Geronimo are not 
> affected by this vulnerability. 
> This vulnerability impacts all Geronimo releases. Up to and including 
> Geronimo 2.0.2.
> For specific information regarding the Tomcat issue, see 
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL 
> PROTECTED]
> By default, Geronimo releases do not use the Webdav servlet. However, it 
> is possible for the Webdav Servlet to be configured or referenced by a 
> user-written application. 
> The Webdav Servlet could be explicitly configured in a web.xml 
>  deployment descriptor as follows:
>  ...
> 
> webdav
> 
> org.apache.catalina.servlets.WebdavServlet
> 
>   readonly
>   false
> 
> 
> Alternatively, a user's application could extend the WebdavServlet, for 
> example:
> import org.apache.catalina.servlets.WebdavServlet;
> public class MyServlet extends WebdavServlet {
>...
>
> If you configure a write-enabled Webdav servlet, we recommend that you:
>   - Disable write access to the Webdav Servlet until this problem has 
> been fixed, or
>   - Limit access to the Webdav servlet to only trusted users.
> This vulnerability will be fixed in the next release of Geronimo (2.0.3 
> and/or 2.1). 
> --kevan

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

[jira] Resolved: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3549.
-

Resolution: Fixed

Commits for Geronimo-3451 ('restricted listeners') also include necessary 
security fixes for this issue.

> Potential vulnerability in Apache Tomcat Webdav servlet
> ---
>
> Key: GERONIMO-3549
> URL: https://issues.apache.org/jira/browse/GERONIMO-3549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> Subject:  [SECURITY] Potential vulnerability in Apache Tomcat Webdav 
> servlet
> Date: Thu, 18 Oct 2007 13:40:24 -0400
> From: Kevan Miller <[EMAIL PROTECTED]>
> Reply-To: dev@geronimo.apache.org
> To:   Geronimo Dev 
> The Geronimo project has learned of a security vulnerability in the 
> Apache Tomcat Webdav Servlet implementation. If you use a Tomcat 
> configuration of Geronimo and configure a write-enabled Webdav servlet, 
> you may be affected by this vulnerability. If you do not configure the 
> Webdav servlet or configure read-only Webdav servlets, you are not 
> impacted by this vulnerability. Jetty configurations of Geronimo are not 
> affected by this vulnerability. 
> This vulnerability impacts all Geronimo releases. Up to and including 
> Geronimo 2.0.2.
> For specific information regarding the Tomcat issue, see 
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL 
> PROTECTED]
> By default, Geronimo releases do not use the Webdav servlet. However, it 
> is possible for the Webdav Servlet to be configured or referenced by a 
> user-written application. 
> The Webdav Servlet could be explicitly configured in a web.xml 
>  deployment descriptor as follows:
>  ...
> 
> webdav
> 
> org.apache.catalina.servlets.WebdavServlet
> 
>   readonly
>   false
> 
> 
> Alternatively, a user's application could extend the WebdavServlet, for 
> example:
> import org.apache.catalina.servlets.WebdavServlet;
> public class MyServlet extends WebdavServlet {
>...
>
> If you configure a write-enabled Webdav servlet, we recommend that you:
>   - Disable write access to the Webdav Servlet until this problem has 
> been fixed, or
>   - Limit access to the Webdav servlet to only trusted users.
> This vulnerability will be fixed in the next release of Geronimo (2.0.3 
> and/or 2.1). 
> --kevan

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

[jira] Assigned: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh reassigned GERONIMO-3549:
---

Assignee: Jay D. McHugh

> Potential vulnerability in Apache Tomcat Webdav servlet
> ---
>
> Key: GERONIMO-3549
> URL: https://issues.apache.org/jira/browse/GERONIMO-3549
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
>Reporter: Donald Woods
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> Subject:  [SECURITY] Potential vulnerability in Apache Tomcat Webdav 
> servlet
> Date: Thu, 18 Oct 2007 13:40:24 -0400
> From: Kevan Miller <[EMAIL PROTECTED]>
> Reply-To: dev@geronimo.apache.org
> To:   Geronimo Dev 
> The Geronimo project has learned of a security vulnerability in the 
> Apache Tomcat Webdav Servlet implementation. If you use a Tomcat 
> configuration of Geronimo and configure a write-enabled Webdav servlet, 
> you may be affected by this vulnerability. If you do not configure the 
> Webdav servlet or configure read-only Webdav servlets, you are not 
> impacted by this vulnerability. Jetty configurations of Geronimo are not 
> affected by this vulnerability. 
> This vulnerability impacts all Geronimo releases. Up to and including 
> Geronimo 2.0.2.
> For specific information regarding the Tomcat issue, see 
> http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL 
> PROTECTED]
> By default, Geronimo releases do not use the Webdav servlet. However, it 
> is possible for the Webdav Servlet to be configured or referenced by a 
> user-written application. 
> The Webdav Servlet could be explicitly configured in a web.xml 
>  deployment descriptor as follows:
>  ...
> 
> webdav
> 
> org.apache.catalina.servlets.WebdavServlet
> 
>   readonly
>   false
> 
> 
> Alternatively, a user's application could extend the WebdavServlet, for 
> example:
> import org.apache.catalina.servlets.WebdavServlet;
> public class MyServlet extends WebdavServlet {
>...
>
> If you configure a write-enabled Webdav servlet, we recommend that you:
>   - Disable write access to the Webdav Servlet until this problem has 
> been fixed, or
>   - Limit access to the Webdav servlet to only trusted users.
> This vulnerability will be fixed in the next release of Geronimo (2.0.3 
> and/or 2.1). 
> --kevan

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

[jira] Closed: (GERONIMO-3451) "Restricted listeners property file not found" error logged during Tomcat server startup

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3451.
---


> "Restricted listeners property file not found" error logged during Tomcat 
> server startup
> 
>
> Key: GERONIMO-3451
> URL: https://issues.apache.org/jira/browse/GERONIMO-3451
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.x
>Reporter: Kevan Miller
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> During Tomcat server startup, the following log error is displayed on the 
> console:
> 12:57:32,559 ERROR [[/]] "Restricted listeners property file not found
> Althgough the log message can be ignored, users assume that something is 
> broken...

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

[jira] Commented: (GERONIMO-3451) "Restricted listeners property file not found" error logged during Tomcat server startup

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561895#action_12561895
 ] 

Jay D. McHugh commented on GERONIMO-3451:
-

Checked into branches/2.0 also:

Sendingpom.xml
Adding repository/org/apache/tomcat/catalina/6.0.14-G614585
Adding  (bin)  
repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar
Adding repository/org/apache/tomcat/jasper/6.0.14-G614585
Adding  (bin)  
repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar
Transmitting file data ...
Committed revision 614758.


> "Restricted listeners property file not found" error logged during Tomcat 
> server startup
> 
>
> Key: GERONIMO-3451
> URL: https://issues.apache.org/jira/browse/GERONIMO-3451
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.x
>Reporter: Kevan Miller
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> During Tomcat server startup, the following log error is displayed on the 
> console:
> 12:57:32,559 ERROR [[/]] "Restricted listeners property file not found
> Althgough the log message can be ignored, users assume that something is 
> broken...

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

[jira] Resolved: (GERONIMO-3451) "Restricted listeners property file not found" error logged during Tomcat server startup

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3451.
-

   Resolution: Fixed
Fix Version/s: 2.1

> "Restricted listeners property file not found" error logged during Tomcat 
> server startup
> 
>
> Key: GERONIMO-3451
> URL: https://issues.apache.org/jira/browse/GERONIMO-3451
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.x
>Reporter: Kevan Miller
>Assignee: Jay D. McHugh
> Fix For: 2.0.x, 2.1
>
>
> During Tomcat server startup, the following log error is displayed on the 
> console:
> 12:57:32,559 ERROR [[/]] "Restricted listeners property file not found
> Althgough the log message can be ignored, users assume that something is 
> broken...

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

[jira] Commented: (GERONIMO-3451) "Restricted listeners property file not found" error logged during Tomcat server startup

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561891#action_12561891
 ] 

Jay D. McHugh commented on GERONIMO-3451:
-

Resolved this issue on trunk with a new version of tomcat private snapshot 
including the latest security patch and djencks patch for the restricted 
listener fix.

Sendingpom.xml
Adding repository/org/apache/tomcat/6.0.14-G614585.README.TXT
Adding repository/org/apache/tomcat/catalina/6.0.14-G614585
Adding  (bin)  
repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar
Adding repository/org/apache/tomcat/jasper/6.0.14-G614585
Adding  (bin)  
repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar
Transmitting file data 
Committed revision 614754.

> "Restricted listeners property file not found" error logged during Tomcat 
> server startup
> 
>
> Key: GERONIMO-3451
> URL: https://issues.apache.org/jira/browse/GERONIMO-3451
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.x
>Reporter: Kevan Miller
>Assignee: Jay D. McHugh
> Fix For: 2.0.x
>
>
> During Tomcat server startup, the following log error is displayed on the 
> console:
> 12:57:32,559 ERROR [[/]] "Restricted listeners property file not found
> Althgough the log message can be ignored, users assume that something is 
> broken...

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

[jira] Assigned: (GERONIMO-3451) "Restricted listeners property file not found" error logged during Tomcat server startup

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh reassigned GERONIMO-3451:
---

Assignee: Jay D. McHugh

> "Restricted listeners property file not found" error logged during Tomcat 
> server startup
> 
>
> Key: GERONIMO-3451
> URL: https://issues.apache.org/jira/browse/GERONIMO-3451
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 2.0, 2.0.x
>Reporter: Kevan Miller
>Assignee: Jay D. McHugh
> Fix For: 2.0.x
>
>
> During Tomcat server startup, the following log error is displayed on the 
> console:
> 12:57:32,559 ERROR [[/]] "Restricted listeners property file not found
> Althgough the log message can be ignored, users assume that something is 
> broken...

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-1265.
---


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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-1265.
-

   Resolution: Fixed
Fix Version/s: 2.1

No one has commented that they wanted the additional functionality that I had 
been holding this issue open for.

So I am closing it.  We can create a new JIRA or reopen this one later if 
anyone decides that we want that (or some other) comment functionality later.

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

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

[jira] Closed: (GERONIMO-3069) Rework AJAX style console screens to work on Safari

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3069.
---


> Rework AJAX style console screens to work on Safari
> ---
>
> Key: GERONIMO-3069
> URL: https://issues.apache.org/jira/browse/GERONIMO-3069
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M7
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.0.2, 2.1
>
> Attachments: geronimo-3069-jmx-1.patch
>
>
> Some of the newer console screens do not work properly in Safari.
> Try to rewrite the javascript code so that it works on safari.

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

[jira] Resolved: (GERONIMO-3069) Rework AJAX style console screens to work on Safari

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3069.
-

   Resolution: Fixed
Fix Version/s: 2.0.2
   2.1

Either Dojo or Safari (or both) made changes that resolved the display problems.

> Rework AJAX style console screens to work on Safari
> ---
>
> Key: GERONIMO-3069
> URL: https://issues.apache.org/jira/browse/GERONIMO-3069
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M7
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: 2.1, 2.0.2
>
> Attachments: geronimo-3069-jmx-1.patch
>
>
> Some of the newer console screens do not work properly in Safari.
> Try to rewrite the javascript code so that it works on safari.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-1265:
-

After considering this some more - I don't think it is necessary for us to be 
able to do either of the 'todo' items above (especially not #1).

Comments are retained for each level of the config.xml file.

And if they are added to the pom.xml's in source (in the '' 
section) then they are carried into the generated config.xml for the server.

Is there anyone who specifically wants to be able to do either of the 'todo' 
items above?

If not, then I am going to go ahead and close this issue.

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

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

[jira] Commented: (GERONIMO-3069) Rework AJAX style console screens to work on Safari

[Jay D. McHugh (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559171#action_12559171
 ] 

Jay D. McHugh commented on GERONIMO-3069:
-

Would someone on a Mac test this issue please.

I haven't changed anything, but the Windows version of Safari seems to be 
rendering correctly on both 2.0.2 and trunk.

Thanks

> Rework AJAX style console screens to work on Safari
> ---
>
> Key: GERONIMO-3069
> URL: https://issues.apache.org/jira/browse/GERONIMO-3069
> Project: Geronimo
>  Issue Type: Sub-task
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.0-M7
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Attachments: geronimo-3069-jmx-1.patch
>
>
> Some of the newer console screens do not work properly in Safari.
> Try to rewrite the javascript code so that it works on safari.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3300:
-

By the way Erik,

Dojo 1.0.2 just came out Sunday - So 1.0.1 is already out of date.

If it would be easier for you - you could just nuke what I had out there.

Jay

> Upgrade Dojo to 1.0
> ---
>
> Key: GERONIMO-3300
> URL: https://issues.apache.org/jira/browse/GERONIMO-3300
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> Dojo 1.0 is now available.
> But, to upgrade we will either need to rewrite all of the plugins that use 
> Dojo widgets to use the new (backward incompatible) versions -or- include 
> both the 0.4.3 and 1.0.0 versions of Dojo.
> Having both versions would make it possible to transition over to the newer 
> version of Dojo in a more leisurely fashion but would introduce a fairly 
> significant amount of bloat.
> I would prefer that we would just replace the old version and rewrite 
> whatever needs to be rewritten but that would depend on how soon we are 
> trying to get G2.1 out the door.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3300:
-

Erik,

If you can get it working that would be great.  I am in the middle of 
rebuilding my computer and right now I can't build anything.

Jay

> Upgrade Dojo to 1.0
> ---
>
> Key: GERONIMO-3300
> URL: https://issues.apache.org/jira/browse/GERONIMO-3300
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> Dojo 1.0 is now available.
> But, to upgrade we will either need to rewrite all of the plugins that use 
> Dojo widgets to use the new (backward incompatible) versions -or- include 
> both the 0.4.3 and 1.0.0 versions of Dojo.
> Having both versions would make it possible to transition over to the newer 
> version of Dojo in a more leisurely fashion but would introduce a fairly 
> significant amount of bloat.
> I would prefer that we would just replace the old version and rewrite 
> whatever needs to be rewritten but that would depend on how soon we are 
> trying to get G2.1 out the door.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3300:
-

I have tried to create a plugin for dojo-1.0.1 under /plugins.

But, it does not work the way I expected it to.  So, any help on getting that 
to act like a real plugin would be great.

Jay

> Upgrade Dojo to 1.0
> ---
>
> Key: GERONIMO-3300
> URL: https://issues.apache.org/jira/browse/GERONIMO-3300
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> Dojo 1.0 is now available.
> But, to upgrade we will either need to rewrite all of the plugins that use 
> Dojo widgets to use the new (backward incompatible) versions -or- include 
> both the 0.4.3 and 1.0.0 versions of Dojo.
> Having both versions would make it possible to transition over to the newer 
> version of Dojo in a more leisurely fashion but would introduce a fairly 
> significant amount of bloat.
> I would prefer that we would just replace the old version and rewrite 
> whatever needs to be rewritten but that would depend on how soon we are 
> trying to get G2.1 out the door.

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

[jira] Commented: (GERONIMO-3596) Unintuitive workings of the MySQL DBPool deployment wizard

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3596:
-

The new adapters are still working for me, but has anyone else had a chance to 
try these?

It would be nice to be able to stop manually copying these into my server each 
time I rebuild.

> Unintuitive workings of the MySQL DBPool deployment wizard
> --
>
> Key: GERONIMO-3596
> URL: https://issues.apache.org/jira/browse/GERONIMO-3596
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: connector, databases, deployment
>Affects Versions: 2.0.2
> Environment: ogre% uname -a
> FreeBSD ogre 7.0-BETA2 FreeBSD 7.0-BETA2 #4: Sat Nov 10 15:29:36 CET 2007 
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/OGRE  amd64
> ogre% java -version
> java version "1.6.0_02-p2"
> Java(TM) SE Runtime Environment (build 1.6.0_02-p2-root_04_nov_2007_14_03-b00)
> Java HotSpot(TM) 64-Bit Server VM (build 
> 1.6.0_02-p2-root_04_nov_2007_14_03-b00, mixed mode)
> Nothing else. I don't think it matters at all for this bug report anyway.
>Reporter: Jesper Louis Andersen
> Attachments: tranql-connector-mysql-local-1.2-SNAPSHOT.rar
>
>
> There is an unintuitive gotcha hidden in the DBPool wizard for the MySQL (and 
> probably also the MySQL-XA) driver. It manifests itself
> with a NullPointerException when trying to connect to a database. See for 
> instance the following mail:
> http://spteam-lists.blogspot.com/2007/11/re-apache-geronimo-202-and-mysql-data.html
> The reason is that if you DON'T fill out the URL field, you get the following 
> deployment plan:
> 
> 
> http://geronimo.apache.org/xml/ns/j2ee/connector-1.2";>
>  xmlns:dep="http://geronimo.apache.org/xml/ns/deployment-1.2";>
> 
> console.dbpool
> cxnet
> 1.0
> rar
> 
> 
> 
> mysql
> mysql-connector-java
> 5.1.5
> jar
> 
> 
> 
> 
> 
> 
> 
> javax.sql.DataSource
> 
> cxnet
>  name="DatabaseName">foo
>  name="Password">foo
>  name="UserName">foo
> 
> 
> 
> 
> 10
> 0
> 
> 
> 
> 
> 
> 
> 
> 
> +
> Notice the Empty URL parameter. Quick workaround: Supply the URL parameter or 
> use the 'show plan' feature and add the URL in
> the plan.
> Steps to reproduce:
> 1. Add a mysql-connector-java JAR to the library section. I used 5.1.5 as a 
> version, but it also fails with 5.0.8 and 3.1.14.
> 2. Click Database Pools -> Wizard -> choose 'foo' and MySQL as driver
> 3. Enter the fields: pool name, database driver, port number, user name, 
> server name, database name, password and confirm password 
> take care NOT to enter the URL. 
> 4. Now click 'show plan'. It this point it should be obvious that we are 
> trying to deploy a plan without an URL.
> The idea for a fix:
> 1. Gather fields from input.
> 2. If URL is empty, stitch together one from the other parameters.
> 3. Use the constructed URL.
> And do take care to report this back to the guy in the linked mail above ;)

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

[jira] Closed: (GERONIMO-3122) Unable to create a (MySQL) database pool

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-3122.
---


> Unable to create a (MySQL) database pool
> 
>
> Key: GERONIMO-3122
> URL: https://issues.apache.org/jira/browse/GERONIMO-3122
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0-M3
> Environment: mysql/mysql-connector-java/3.1.12/jar 
> MySQL 5.0.27
> Win-Xp
> Java 1.6
>Reporter: nrkkalyan
>
> I tried to create new database pool using 
> 1. Database Pool Wizard
> 2. Importing from Jboss 4.
> That time I got the following exception.
>  EXCEPTION WHILE CREATING 
> DATABASE POOL USING THE GERONIMO DATABASE POOL WIZARD  ///
> Geronimo Application Server started
> 22:44:35,401 ERROR [DatabasePoolPortlet] Unable to save connection pool
> javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer 
> for module type: rar registered
> at 
> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
> at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
> at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> at java.lang.Thread.run(Thread.java:619)
> 

[jira] Resolved: (GERONIMO-3122) Unable to create a (MySQL) database pool

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3122.
-

Resolution: Duplicate

Accidental clone of 2368

> Unable to create a (MySQL) database pool
> 
>
> Key: GERONIMO-3122
> URL: https://issues.apache.org/jira/browse/GERONIMO-3122
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: databases
>Affects Versions: 2.0-M3
> Environment: mysql/mysql-connector-java/3.1.12/jar 
> MySQL 5.0.27
> Win-Xp
> Java 1.6
>Reporter: nrkkalyan
>
> I tried to create new database pool using 
> 1. Database Pool Wizard
> 2. Importing from Jboss 4.
> That time I got the following exception.
>  EXCEPTION WHILE CREATING 
> DATABASE POOL USING THE GERONIMO DATABASE POOL WIZARD  ///
> Geronimo Application Server started
> 22:44:35,401 ERROR [DatabasePoolPortlet] Unable to save connection pool
> javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer 
> for module type: rar registered
> at 
> org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880)
> at 
> org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
> at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
> at 
> org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
> at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
> at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
> at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
> at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
> at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
> at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
> at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
> at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
> at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
> at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
> at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)
> at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
> at 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at 
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at 
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
> at 
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
> at 
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> at 
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
> at 
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
> at java.lang.Thread.run(Thr

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3638:
-

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

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

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

Anyone else have a comment or suggestion?

> should allow URL encoding with custom encoding charset other than the default
> -
>
> Key: GERONIMO-3638
> URL: https://issues.apache.org/jira/browse/GERONIMO-3638
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
> query string.  However, applications may want to use a different encoding 
> than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
> specify an encoding that AHC should use to encode the query string.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3638:
-

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


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


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

> should allow URL encoding with custom encoding charset other than the default
> -
>
> Key: GERONIMO-3638
> URL: https://issues.apache.org/jira/browse/GERONIMO-3638
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: AsyncHttpClient
>Affects Versions: 1.x
>Reporter: Sangjin Lee
> Attachments: patch.zip
>
>
> Currently AsyncHttpClient uses Chartset.defaultCharset() when it encodes the 
> query string.  However, applications may want to use a different encoding 
> than the machine default charset; e.g. UTF-8.  It needs to provide a way to 
> specify an encoding that AHC should use to encode the query string.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-3300:


  Description: 
Dojo 1.0 is now available.

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

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

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

  was:
The new Dojo 0.9 Beta was just released.

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

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

> Upgrade Dojo to 1.0
> ---
>
> Key: GERONIMO-3300
> URL: https://issues.apache.org/jira/browse/GERONIMO-3300
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>  Components: console
>Affects Versions: 2.1
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
>
> Dojo 1.0 is now available.
> But, to upgrade we will either need to rewrite all of the plugins that use 
> Dojo widgets to use the new (backward incompatible) versions -or- include 
> both the 0.4.3 and 1.0.0 versions of Dojo.
> Having both versions would make it possible to transition over to the newer 
> version of Dojo in a more leisurely fashion but would introduce a fairly 
> significant amount of bloat.
> I would prefer that we would just replace the old version and rewrite 
> whatever needs to be rewritten but that would depend on how soon we are 
> trying to get G2.1 out the door.

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3271.
-

   Resolution: Fixed
Fix Version/s: 2.1

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

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


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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-3266.
-

   Resolution: Fixed
Fix Version/s: 2.1

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

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

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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-1265:
-

Committed revision 596403.

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

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

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

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

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

[jira] Issue Comment Edited: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Jay D. McHugh (JIRA)]

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

jaydm edited comment on GERONIMO-2567 at 9/6/07 4:19 PM:
-

Fixed in Revision: 568302/568304

Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the 
server) with its external ip address.

And the /var/config/config.xml file needs to have the 
gbean-deployer module
updated to point to the external address (of the server).

ie:


http://172.16.1.2:${HTTPPortPrimary + 
PortOffset}




  was (Author: jaydm):
Fixed in Revision: 568302

Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the 
server) with its external ip address.

And the /var/config/config.xml file needs to have the 
gbean-deployer module
updated to point to the external address (of the server).

ie:


http://172.16.1.2:${HTTPPortPrimary + 
PortOffset}



  
> Remote admin of server using deployer.jar fails to connect
> --
>
> Key: GERONIMO-2567
> URL: https://issues.apache.org/jira/browse/GERONIMO-2567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2, 2.0, 2.0.x
> Environment: Linux
> Java 1.5
>Reporter: Jay D. McHugh
>Assignee: Kevan Miller
> Fix For: 2.0.x, 2.1
>
>
> Trying to remote deploy a WAR file resulted in a failed connection.
> This happened regardless of whether the port was specified.
> $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 
> redeploy ~/PaLM.war
> Error: Unable to connect to server at
> deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
> 127.0.0.1; nested exception is:
> java.net.ConnectException: Connection refused

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

[jira] Closed: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh closed GERONIMO-2567.
---


Fixed in Revision: 568302

Linux notes:
The hostname of the server needs to appear in the /etc/hosts file (on the 
server) with its external ip address.

And the /var/config/config.xml file needs to have the 
gbean-deployer module
updated to point to the external address (of the server).

ie:


http://172.16.1.2:${HTTPPortPrimary + 
PortOffset}




> Remote admin of server using deployer.jar fails to connect
> --
>
> Key: GERONIMO-2567
> URL: https://issues.apache.org/jira/browse/GERONIMO-2567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2, 2.0, 2.0.x
> Environment: Linux
> Java 1.5
>Reporter: Jay D. McHugh
>Assignee: Kevan Miller
> Fix For: 2.0.x, 2.1
>
>
> Trying to remote deploy a WAR file resulted in a failed connection.
> This happened regardless of whether the port was specified.
> $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 
> redeploy ~/PaLM.war
> Error: Unable to connect to server at
> deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
> 127.0.0.1; nested exception is:
> java.net.ConnectException: Connection refused

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

[jira] Resolved: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh resolved GERONIMO-2567.
-

Resolution: Invalid
  Assignee: Jay D. McHugh

Kevan,

You are correct - It was an IPv6 issue (I hadn't realized that I had IPv6 
enabled locally).

So, taking that into account (specifying the remote server address using the 
IPv4 version
surrounded by "[ ]") and setting the remoteDeployAddress in the server's 
config.xml
(server address in IPv4 surrounded by "[ ]" with the port set to ) allowed 
me to connect
and list my modules.

Rather than a bug, this looks like it would be better addressed in the 
documentation.

> Remote admin of server using deployer.jar fails to connect
> --
>
> Key: GERONIMO-2567
> URL: https://issues.apache.org/jira/browse/GERONIMO-2567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2, 2.0, 2.0.x
> Environment: Linux
> Java 1.5
>Reporter: Jay D. McHugh
>Assignee: Jay D. McHugh
> Fix For: Verification Required
>
>
> Trying to remote deploy a WAR file resulted in a failed connection.
> This happened regardless of whether the port was specified.
> $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 
> redeploy ~/PaLM.war
> Error: Unable to connect to server at
> deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
> 127.0.0.1; nested exception is:
> java.net.ConnectException: Connection refused

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

[jira] Commented: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-2567:
-

I'll see if I can figure out why I can't get a connection.

I need two questions answered to make sure that I am at least set up properly:
1) Do I need to have a server running locally to administer a remote server (I 
would tend to think not)
2) Which address should remoteDeployAddress point to? The remote server's 
external address or the local system's address?

Other than those, I'll try to eliminate all other variables by statically 
addressing everything.

I won't be able to look at this until either this evening or tomorrow though.

> Remote admin of server using deployer.jar fails to connect
> --
>
> Key: GERONIMO-2567
> URL: https://issues.apache.org/jira/browse/GERONIMO-2567
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: deployment
>Affects Versions: 1.2, 2.0, 2.0.x
> Environment: Linux
> Java 1.5
>Reporter: Jay D. McHugh
> Fix For: Verification Required
>
>
> Trying to remote deploy a WAR file resulted in a failed connection.
> This happened regardless of whether the port was specified.
> $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 
> redeploy ~/PaLM.war
> Error: Unable to connect to server at
> deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
> 127.0.0.1; nested exception is:
> java.net.ConnectException: Connection refused

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

[jira] Updated: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-2567:


Affects Version/s: 2.0.x
   2.0
  Summary: Remote admin of server using deployer.jar fails to 
connect  (was: Remote deploy of apps fails)

I am still having a problem.

Perhaps the problem is that I am trying to use the deployer incorrectly
(I usually just use the web console to administer remote servers).

Please let me know if I am trying to use the tool incorrectly
(It would be nice to be able to script my redeploys).

Configuration: 
Local system - Linux with Sun JDK 1.5.0_12
Remote system - Linux with Sun JDK 1.5.0_8 (IP Address 172.16.1.41)
No running firewall on either system and the web admin console works.

When I try to list the modules running on a remote server here is the command I 
use
and the resulting output:

(with a server running locally also)
java -jar deployer.jar --user system --password manager --host 172.16.1.41 
list-modules
Error: Unable to connect to server at
deployer:geronimo:jmx://172.16.1.41 -- no such object in table
javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: no 
such object in table
at 
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:167)
at 
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:131)
at 
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111)
at 
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:181)
at 
org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:93)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.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: java.rmi.NoSuchObjectException: no such object in table
at 
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at 
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown 
Source)
at 
javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2239)
at 
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:271)
at 
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248)
at 
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:159)
... 8 more


(without a server running locally)
java -jar deployer.jar --user system --password manager --host 172.16.1.41 
list-modules
Error: Unable to connect to server at
deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host:
127.0.0.1; nested exception is:

java.net.ConnectException: Connection refused
javax.enterprise.deploy.spi.exceptions.DeploymentManagerCreationException: 
Connection refused to host: 127.0.0.1; nested exception is:
java.net.ConnectException: Connection refused
at 
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.newRemoteDeploymentManager(BaseDeploymentFactory.java:167)
at 
org.apache.geronimo.deployment.plugin.factories.BaseDeploymentFactory.getDeploymentManager(BaseDeploymentFactory.java:131)
at 
javax.enterprise.deploy.shared.factories.DeploymentFactoryManager.getDeploymentManager(DeploymentFactoryManager.java:111)
at 
org.apache.geronimo.deployment.cli.ServerConnection.tryToConnect(ServerConnection.java:181)
at 
org.apache.geronimo.deployment.cli.ServerConnection.(ServerConnection.java:93)
at 
org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158)
at 
org.apache.geronimo.kernel.util.MainConfigurationBootstrapper.main(MainConfigurationBootstrapper.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: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; 
nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:574)
at 
sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:185)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.jav

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh edited comment on GERONIMO-3266 at 8/1/07 4:37 PM:
-

Committed second attempt on schema file

revision 561971 (trunk)
revision 561990 (branches/2.0)

Second revision of schema
- Corrected the attributes level comment
- Corrected the gbean level comment


 was:
Committed second attempt on schema file

revision 561971

Second revision of schema
- Corrected the attributes level comment
- Corrected the gbean level comment

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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-1265:


 Assignee: Jay D. McHugh
Affects Version/s: (was: 1.2)
   (was: 2.0-M7)
   2.1

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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-3266:


Affects Version/s: (was: 2.0-M7)
   2.1
   2.0

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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-1265:
-

Committed revision 561989

- Added new schema (see 3266)
- Added support for module level comments

Changes inspired by Don Hill's patch - Thanks Don!

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

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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh updated GERONIMO-3271:


Affects Version/s: (was: 2.0-M7)
   2.1

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


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

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

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh commented on GERONIMO-3271:
-

Committed - Revision 561988

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


-- 
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: (GERONIMO-3266) Enhance attributes schema (relates to config.xml)

[Jay D. McHugh (JIRA)]

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

Jay D. McHugh edited comment on GERONIMO-3266 at 8/1/07 3:08 PM:
-

Committed second attempt on schema file

revision 561971

Second revision of schema
- Corrected the attributes level comment
- Corrected the gbean level comment


 was:
Committed second attempt on schema file

revision 561971

GERONIMO-3266 - Second revision of schema
- Corrected the attributes level comment
- Corrected the gbean level comment

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

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