[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-1585: -- Attachment: g1585.war Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-1585: -- Attachment: g1585-nologin.war Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462468
]
Vamsavardhana Reddy commented on GERONIMO-1585:
---
Here is what I observed using sample applications g1585.war and
g1585-nologin.war:
1. Pages configured with form-login-page and form-error-page always have
unrestricted access.
2. Adding a security-constraint on /login/* witn NO auth-constraint element
makes all /login/* resources accessible unrestrictedly. The tag in
geronimo-web.xml will look like the following:
{code}
security-constraint
display-namelogin/display-name
web-resource-collection
web-resource-namelogin/web-resource-name
url-pattern/login/*/url-pattern
/web-resource-collection
!-- Notice that there is no auth-constraint tag --
/security-constraint
{code}
3. Works properly on G Jetty distribution
Web app security on /* causes deployment exception
--
Key: GERONIMO-1585
URL: https://issues.apache.org/jira/browse/GERONIMO-1585
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, web
Affects Versions: 1.1
Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.1.x
Attachments: g1585-nologin.war, g1585.war, security.patch
Deploying a web app with the following security block causes a deployment
error:
security-constraint
web-resource-collection
web-resource-nameAll Pages/web-resource-name
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-nameUser/role-name
/auth-constraint
/security-constraint
Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet
2.4 spec).
The error is:
org.apache.geronimo.common.DeploymentException: Unable to initialize
webapp GBean
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
...
Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the
URLPatternSpec cannot match the first URLPattern
at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
at
javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
... 70 more
Changing the url-pattern to / fixes the problem, but it seems to me that /*
ought to work too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[
https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462469
]
Vamsavardhana Reddy commented on GERONIMO-1585:
---
Using g1585-nologin.war:
Step 0: Undeploy jira/G1585/1.0/war if it exists already
Step 1: Deploy g1585-nologin.war
Step 2: Access http://localhost:8080/G1585 . You will be redirected to a
login page with a broken image.
Step 3: Login using uid/pwd = system/manager and welcome page will display
Using g1585.war:
Step 0: Undeploy jira/G1585/1.0/war if it exists already
Step 1: Deploy g1585.war
Step 2: Access http://localhost:8080/G1585 . You will be redirected to a
login page with my image :o)
Step 3: Login using uid/pwd = system/manager and welcome page will display
The only difference between g1585.war and g1585-nologin.war is that
geronimo-web.xml in g1585.war has the following security-constraint element.
{code}
security-constraint
display-namelogin/display-name
web-resource-collection
web-resource-namelogin/web-resource-name
url-pattern/login/*/url-pattern
/web-resource-collection
!-- Notice that there is no auth-constraint tag --
/security-constraint
{code}
Web app security on /* causes deployment exception
--
Key: GERONIMO-1585
URL: https://issues.apache.org/jira/browse/GERONIMO-1585
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, web
Affects Versions: 1.1
Environment: Geronimo 1.0 with Jetty and tomcat
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.1.x
Attachments: g1585-nologin.war, g1585.war, security.patch
Deploying a web app with the following security block causes a deployment
error:
security-constraint
web-resource-collection
web-resource-nameAll Pages/web-resource-name
url-pattern/*/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
http-methodPUT/http-method
/web-resource-collection
auth-constraint
role-nameUser/role-name
/auth-constraint
/security-constraint
Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet
2.4 spec).
The error is:
org.apache.geronimo.common.DeploymentException: Unable to initialize
webapp GBean
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842)
...
Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the
URLPatternSpec cannot match the first URLPattern
at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54)
at
javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215)
at
org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821)
... 70 more
Changing the url-pattern to / fixes the problem, but it seems to me that /*
ought to work too.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462472 ] Vamsavardhana Reddy commented on GERONIMO-1585: --- Forgot to mention... 1. g1585.war and g1585-nologin.war DO NOT USE security-constraint with url-pattern /*, but, USE / 2. Sample applications are to be used with G1.1.x Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
[ https://issues.apache.org/jira/browse/GERONIMO-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462473 ] Vamsavardhana Reddy commented on GERONIMO-2339: --- I think Tomcat has problem processing security-constraints with empty auth-constraint (FORBIDDEN access) and no auth-constraint (UNRESTRICTED access). Empty auth-constraint tag in web app security-constraint does not prevent access to resource Key: GERONIMO-2339 URL: https://issues.apache.org/jira/browse/GERONIMO-2339 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, Tomcat Affects Versions: 1.1.1 Environment: Geronimo Tomcat 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Vamsavardhana Reddy Fix For: 1.1.2, 1.2, 2.0 Attachments: g2339.war I have the following security constraint in web.xml security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint This means /forbidden/* is not accessible by any user. The permission woks fine if the application is deployed in Geronimo Jetty distribution. If the application is deployed in Geronimo Tomcat distribution, URLs /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462478 ] Anita Kulshreshtha commented on GERONIMO-1585: -- This problem as described by Aaron is about url-pattern/*/url-pattern. The default pattern, i.e. / works fine. Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462481 ] Vamsavardhana Reddy commented on GERONIMO-1585: --- Anitha, I understand that this JIRA is about url-pattern/*/url-pattern. My comments and sample apps were more toward Jérôme's concern on EveryBody role. Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462484 ] Anita Kulshreshtha commented on GERONIMO-1585: -- Vamsi, Jérôme's observations are based on the results after applying the security.patch. Are you saying that your observations are also taken after the patch? Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r492633 - /geronimo/specs/trunk/pom.xml
G2692 was to fix the fact that specs/trunk would not build as it existed today. There was a long email discussion about tagging and releasing the specs, which I didn't contribute to as I'm not a committer I agree, that this whole specs directory layout and handling is a pain for any people/groups outside of the core Geronimo developers to follow. -Donald Jason Dillon wrote: Why were these deleted? This is soo retarded IMO... If we are going to be using the specs/trunk as a some transient place for specs to live, then it should be completely removed, and each spec should get its own trunk/branches/tags and be treated like a normal project. Moving stuff in and out of trunk on some ethereal whim is a horrible plan. --jason On Jan 4, 2007, at 8:51 AM, [EMAIL PROTECTED] wrote: Author: adc Date: Thu Jan 4 08:51:02 2007 New Revision: 492633 URL: http://svn.apache.org/viewvc?view=revrev=492633 Log: GERONIMO-2692 Removed missing modules Modified: geronimo/specs/trunk/pom.xml Modified: geronimo/specs/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/pom.xml?view=diffrev=492633r1=492632r2=492633 == --- geronimo/specs/trunk/pom.xml (original) +++ geronimo/specs/trunk/pom.xml Thu Jan 4 08:51:02 2007 @@ -120,13 +120,10 @@ /activation modules -modulegeronimo-annotation_1.0_spec/module modulegeronimo-ejb_3.0_spec/module modulegeronimo-el_1.0_spec/module -modulegeronimo-interceptor_3.0_spec/module modulegeronimo-j2ee-management_1.1_spec/module modulegeronimo-jacc_1.1_spec/module -modulegeronimo-jpa_3.0_spec/module modulegeronimo-jsp_2.1_spec/module modulegeronimo-ws-metadata_2.0_spec/module /modules smime.p7s Description: S/MIME Cryptographic Signature
Questions about geronimo 2.0 plugin repository
How do we update the contents of the http://geronimo.apache.org/plugins/geronimo-2.0/repository/ directory? Everything except the /repository directory is in svn under http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/ which currently contains 1.2-SNAPSHOT and 2.0-M1-SNAPSHOT binaries Can we update the build/release process on gbuild to automatically remove the existing release directory (currently 2.0-SNAPSHOT) and push the latest org.apache.geronimo build artifacts over at least once a week? -Donald Paul McMahan (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2670. -- Resolution: Fixed Update geronimo plugin repository version - Key: GERONIMO-2670 URL: https://issues.apache.org/jira/browse/GERONIMO-2670 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M1, 2.0 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 2.0-M1, 2.0 Update the geronimo plugin repository version number in geronimo-plugin.xml files. Also update assemblies to point at new repository list. smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-2696) SQL Exception: Failed to start database
SQL Exception: Failed to start database --- Key: GERONIMO-2696 URL: https://issues.apache.org/jira/browse/GERONIMO-2696 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console, databases Affects Versions: 2.0-M1, 2.0 Environment: Tested on Tomcat distribution Revision: 492305 Reporter: Hernan Cunico Several issues when accessing the embedded Derby DB. DB Viewer portlet fails to display db tables After creating a DB and adding some tables and content the portlet fails to browse that DB tables. The same error occours when browsing the DB from any application. So far this error occours randomly and very often, restarting Geronimo SOMETIMES help (initially). After subsequent errors and restarting the DB is no longer accessible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1118) dangling thread after shutdown broker with a managed transport
dangling thread after shutdown broker with a managed transport -- Key: AMQ-1118 URL: https://issues.apache.org/activemq/browse/AMQ-1118 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2, 4.0.1, 4.0 Environment: Windows XP, demand forwarding, failover == true Reporter: Chris Hofstaedter I ran into a problem in which I end up with an orphaned thread every time I bounce a broker with a managed transport. I realize this may not be a big deal in many scenarios, but we may end up bouncing our broker everytime a user changes some configuration settings in our application and we need the app to run indefinitely. So orphaned threads are a concern to me. I traced it down to BrokerService.startTransportConnector(). In this function, if isUseJmx() returns true, the connector is decorated/replaced through a call to connector.asManagedConnector(). Turns out the broker never stores the reference to the newly created managed connector anywhere. I added transportConnectors.add(connector) to add the new managed connector to the broker's container of connectors and it seems to work in that all threads are shutdown cleanly even when the transport connector is managed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1119) Deadlock in MutexTransport on shutdown with high volume of messages
Deadlock in MutexTransport on shutdown with high volume of messages
---
Key: AMQ-1119
URL: https://issues.apache.org/activemq/browse/AMQ-1119
Project: ActiveMQ
Issue Type: Bug
Components: Transport
Affects Versions: 4.0.2, 4.0.1, 4.0
Environment: Windows XP, demand forwarding, failover == true
Reporter: Chris Hofstaedter
I ran into a deadlock in the MutextTransport.oneway(Command command) function
when processing very high message volume (100% cpu utilization) at the time of
a shutdown. I'm running 4.0.2 on WinXP and within a demand forwarding
environment with failover = true.
I did trap this deadlock in the debugger and it looks like two commands are
crossing paths in opposite directions through the MutexTransport. One of the
commands is a MessageDispatch and the other is a ShutdownInfo. Now, when the
ShutdownInfo gets through the MutexTransport first, it tries to shutdown the
background thread of the TcpTransport. However, this thread is currently
servicing the MessageDispatch and is blocked on the MutexTransport. Deadlock.
So, my patch was simply to avoid entering the synchronized(writeMutex) block in
the oneway(Command command) function of MutexTransport if
command.isShutdownInfo() returns true:
if (command.isShutdownInfo())
next.oneway(command);
else
synchronized(writeMutex) {
next.oneway(command);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2697) OpenEJB schemas missing in Geronimo 1.2 distribution
OpenEJB schemas missing in Geronimo 1.2 distribution Key: GERONIMO-2697 URL: https://issues.apache.org/jira/browse/GERONIMO-2697 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: general, OpenEJB Affects Versions: 1.2 Reporter: Sachin Patel Fix For: 1.2 The openejb schemas are not being packaged in the schema's directory of the 1.2 distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1120) Race Condition can result in hang on remoteBrokerNameKnownLatch
Race Condition can result in hang on remoteBrokerNameKnownLatch --- Key: AMQ-1120 URL: https://issues.apache.org/activemq/browse/AMQ-1120 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0.2, 4.0.1, 4.0 Environment: Windows XP, demand forwarding, failover == true Reporter: Chris Hofstaedter My environment is comprised of Windows XP, AMQ v4.0.2, demand forwarding, failover = true, client and broker are all within the same VM. Typically, my client and broker would not be within the same VM, but this issue was encountered while executing my junit tests - not in a typical deployment environment. Basically, DemandForwardingBridgeSupport.startLocalBridge() hangs on remoteBrokerNameKnownLatch.await(); It looks like the broker name becomes known prior to the call to await. I think the response is coming in after the triggerLocalStartBridge thread is spawned and the synchronized block in DemandForwardingBridgeSupport.startRemoteBridge() is exited but before the await call in triggerLocalStartBridge. Like I said, I've only run into this when running demand forwarding with client and broker in the same VM along with a high volume of messages sent immediately after the connection is established, which for me, is an artifact of junit testing. I have a relatively small number of clients that should connect fairly infrequently, so I just put a bandaid of a 100ms wait into TcpTransportServer.run right before getAcceptListener().onAccept() which allows my tests to complete successfully and has no appreciable impact on the performance I care about but it's obviously not a valid fix for the race condition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2696) SQL Exception: Failed to start database
[ https://issues.apache.org/jira/browse/GERONIMO-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hernan Cunico updated GERONIMO-2696: Attachment: geronimo.log SQL Exception: Failed to start database --- Key: GERONIMO-2696 URL: https://issues.apache.org/jira/browse/GERONIMO-2696 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M1, 2.0 Environment: Tested on Tomcat distribution Revision: 492305 Reporter: Hernan Cunico Attachments: geronimo.log Several issues when accessing the embedded Derby DB. DB Viewer portlet fails to display db tables After creating a DB and adding some tables and content the portlet fails to browse that DB tables. The same error occours when browsing the DB from any application. So far this error occours randomly and very often, restarting Geronimo SOMETIMES help (initially). After subsequent errors and restarting the DB is no longer accessible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
ClassLoader, JNDI and Dependency views in console
Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gifto get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gifto get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gifto get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gifthis is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin
Re: ClassLoader, JNDI and Dependency views in console
I like the pictures, but haven't had time to look at the implementations. I think some of the dependency viewer info is already available somewhere else where we show the parents and children of each configuration. Am I misled on this? Would it make any sense to think about combining the views somehow? I think these views would be very useful. Lets put them in and if someone finds implementation problems we'll fix them (note I haven't had time to look at how this was done :-) thanks david jencks On Jan 5, 2007, at 10:06 AM, Rakesh Midha wrote: Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https:// issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif to get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https:// issues.apache.org/jira/secure/attachment/ 12348333/12348333_classloader.gif to get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/ attachment/12348336/12348336_dependency.gif to get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/ attachment/12348329/12348329_navigation.gif this is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin
Re: ClassLoader, JNDI and Dependency views in console
p.s. I didn't see the openejb remote jndi implementation shown in the jndi viewer, although I might have just missed it. Would it be possible to add it as well? It's possible that openejb3 may be doing this differently, so it might be a good idea to ask about that. thanks david jencks On Jan 5, 2007, at 10:20 AM, David Jencks wrote: I like the pictures, but haven't had time to look at the implementations. I think some of the dependency viewer info is already available somewhere else where we show the parents and children of each configuration. Am I misled on this? Would it make any sense to think about combining the views somehow? I think these views would be very useful. Lets put them in and if someone finds implementation problems we'll fix them (note I haven't had time to look at how this was done :-) thanks david jencks On Jan 5, 2007, at 10:06 AM, Rakesh Midha wrote: Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https:// issues.apache.org/jira/secure/attachment/ 12348327/12348327_jndi.gif to get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https://issues.apache.org/jira/secure/attachment/ 12348333/12348333_classloader.gif to get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/ attachment/12348336/12348336_dependency.gif to get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/ attachment/12348329/12348329_navigation.gif this is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin
Re: ClassLoader, JNDI and Dependency views in console
Nice screenshots! One thought would be to have a filter field, which could be used to dynamically hide certain packages from view, or to search for certain items. On Jan 5, 2007, at 10:06 AM, Rakesh Midha wrote: Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https:// issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif to get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https:// issues.apache.org/jira/secure/attachment/ 12348333/12348333_classloader.gif to get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/ attachment/12348336/12348336_dependency.gif to get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/ attachment/12348329/12348329_navigation.gif this is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin -sachin
Re: ClassLoader, JNDI and Dependency views in console
Ignore my comment, I overlooked the search field in the image. :) On 1/5/07, Sachin Patel [EMAIL PROTECTED] wrote: Nice screenshots! One thought would be to have a filter field, which could be used to dynamically hide certain packages from view, or to search for certain items. On Jan 5, 2007, at 10:06 AM, Rakesh Midha wrote: Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gifto get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gifto get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gifto get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif this is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, Erin Mulder [EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.pnghttp://people.apache.org/%7Eammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin -sachin
[jira] Commented: (GERONIMO-2697) OpenEJB schemas missing in Geronimo 1.2 distribution
[ https://issues.apache.org/jira/browse/GERONIMO-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462522 ] Anita Kulshreshtha commented on GERONIMO-2697: -- The schemas are not being packaged with the following jars. I do not follow openejb list... I do not know why they have been dropped lately. openejb-builder openejb-pkgen-builder openejb-corba-builder once they are available in these jars, we can add them to the assemblies. OpenEJB schemas missing in Geronimo 1.2 distribution Key: GERONIMO-2697 URL: https://issues.apache.org/jira/browse/GERONIMO-2697 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: general, OpenEJB Affects Versions: 1.2 Reporter: Sachin Patel Fix For: 1.2 The openejb schemas are not being packaged in the schema's directory of the 1.2 distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[ https://issues.apache.org/jira/browse/GERONIMO-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462529 ] Jeff Genender commented on GERONIMO-1585: - Can we please split up this JIRA? I agree with Anita as the JIRA changed it's scope. Lets keep this JIRA on track. The problem Vamsi is talking about is being dealt with in GERONIMO-2695 and we now have a dup in GERONIMMO-2339. Lets deal with this problem in GERONIMO-2695 please. Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: https://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, web Affects Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.x Attachments: g1585-nologin.war, g1585.war, security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ClassLoader, JNDI and Dependency views in console
Comments inline Cheers Prasad On 1/5/07, David Jencks [EMAIL PROTECTED] wrote: I like the pictures, but haven't had time to look at the implementations. Ditto I think some of the dependency viewer info is already available somewhere else where we show the parents and children of each configuration. Am I misled on this? Would it make any sense to think about combining the views somehow? The only other place I can think of another dependency viewer is in the generated site documentation of a module at build time. Example: http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html Are you thinking of a different one in the server too ? I think these views would be very useful. Lets put them in and if someone finds implementation problems we'll fix them (note I haven't had time to look at how this was done :-) thanks david jencks
[jira] Created: (GERONIMO-2698) DirectoryGBean not referenceable as a GBean
DirectoryGBean not referenceable as a GBean
---
Key: GERONIMO-2698
URL: https://issues.apache.org/jira/browse/GERONIMO-2698
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 1.1.1
Reporter: Chris Curtis
Priority: Minor
Specifying a reference to DirectoryGBean.class fails because DirectoryGBean
doesn't have a no-arg constructor. Example:
{{...}}
{{infoFactory.addReference(DirectoryGBean, DirectoryGBean.class);}}
{{...}}
At load time, this throws:
{{java.lang.IllegalArgumentException: Cannot find matching method/constructor}}
{{at
org.apache.geronimo.directory.DirectoryGBean$$EnhancerByCGLIB$$f37d2ade$$FastClassByCGLIB$$dc9cb3c5.newInstance(generated)}}
The cleanest way to resolve this seems like it would be to pull up the relevant
attributes/operations to an interface, which would be usable as a reference
classspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ClassLoader, JNDI and Dependency views in console
Prasad Kashyap wrote: Comments inline Cheers Prasad On 1/5/07, David Jencks [EMAIL PROTECTED] wrote: I like the pictures, but haven't had time to look at the implementations. Ditto I think some of the dependency viewer info is already available somewhere else where we show the parents and children of each configuration. Am I misled on this? Would it make any sense to think about combining the views somehow? The only other place I can think of another dependency viewer is in the generated site documentation of a module at build time. Example: http://geronimo.apache.org/maven/server/modules/geronimo-webservices-builder/dependencies.html Are you thinking of a different one in the server too ? Actually, I think David is thinking of the dependencies that are listed in the configuration views (such as WARs, EARs, etc...) where the dependencies are listed to communicate the potential ramifications if a configuration is removed. I think these views would be very useful. Lets put them in and if someone finds implementation problems we'll fix them (note I haven't had time to look at how this was done :-) thanks david jencks
Re: Questions about geronimo 2.0 plugin repository
On 1/5/07, Donald Woods [EMAIL PROTECTED] wrote: How do we update the contents of the http://geronimo.apache.org/plugins/geronimo-2.0/repository/ directory? Everything except the /repository directory is in svn under http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/ which currently contains 1.2-SNAPSHOT and 2.0-M1-SNAPSHOT binaries site/trunk/docs/plugins/geronimo-2.0/.htaccess contains this rewrite rule: RewriteRule ^repository/(.*) http://people.apache.org/maven-snapshot-repository/$1 This rule makes requests to the URL you mentioned above get redirected to the maven snapshot repository. Publishing a Geronimo snapshot updates the content of that repository. When 2.0 is released then we will update that rewrite rule to redirect to the permanent (non-snapshot) repository location. Can we update the build/release process on gbuild to automatically remove the existing release directory (currently 2.0-SNAPSHOT) and push the latest org.apache.geronimo build artifacts over at least once a week? I think that would be a great idea because it would ensure that any changes made to the plugin metadata under server/trunk/configs is available from the plugins in the snapshot repository on a more predictable schedule. Eventually I think that we'll also need to automate creation of the repository catalogs. I do that by hand right now (good old vim) and have been meaning to write a perl script to automate it. Maybe that could be hooked into gbuild. BTW, in case you're looking at this plugin stuff right now you should be aware that after making the changes below I found that the 2.0-M1-SNAPSHOT plugins published in the maven snapshot repo don't work with 2.0-SNAPSHOT because of the serialVersionUID change made to GOperationInfo.java. Grr. So far we don't have a good track record for maintaining plugin compatibility across Geronimo releases, which is the reason why there's basically a catalog for every release. I'm hoping to cut down on the number of catalogs by enhancing the plugin schema to allow multiple download locations per plugin, based on the geronimo version. (I'll start a discuss thread on that before making any changes) Best wishes, Paul Paul McMahan (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-2670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul McMahan closed GERONIMO-2670. -- Resolution: Fixed Update geronimo plugin repository version - Key: GERONIMO-2670 URL: https://issues.apache.org/jira/browse/GERONIMO-2670 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: Plugins Affects Versions: 2.0-M1, 2.0 Reporter: Paul McMahan Assigned To: Paul McMahan Fix For: 2.0-M1, 2.0 Update the geronimo plugin repository version number in geronimo-plugin.xml files. Also update assemblies to point at new repository list.
Re: ClassLoader, JNDI and Dependency views in console
Hi Rakesh, Thanks for the patches. I haven't looked at the source too but the pix looks good. It would be nice if you can create a combined patch for the 3 jiras so people who wanted to check out the new debug views can use this as another option. Best wishes, chris Rakesh Midha wrote: Hello First of all I am sorry for being missing from the list for last few days, actually I have been trying to get this work item done. I kinda liked the idea of having ClassLoader, JNDI and Dependency views in console. We have discussed this before in dev list, please read the discussion below. I got this thing working, so I created three JIRA's, Please have a look at https://issues.apache.org/jira/browse/GERONIMO-2689 https://issues.apache.org/jira/browse/GERONIMO-2690 https://issues.apache.org/jira/browse/GERONIMO-2691 These three JIRA's adds 3 view in console which shows 1. JNDIView This view shows all the JNDI names binded in various componet contexts as well as Global context. Have a look at https://issues.apache.org/jira/secure/attachment/12348327/12348327_jndi.gif to get idea of what it will show. As we can see it shows JNDI names for which are available at each component context level. For details of how this is implemented please have a look at comments of this JIRA. 2. ClassloaderView This view shows all the classloaders and classes/interfaces loaded by that classloader in heirarchical fashion. Have a look at https://issues.apache.org/jira/secure/attachment/12348333/12348333_classloader.gif to get idea of what it will show. As we can see it shows classes and interfaces for all the classloaders and its child classloaders. For details of how this is implemented please have a look at comments of this JIRA. 3. DependencyView This view shows all the components and repository items and its dependencies in hierarchical fashion in which they are loaded. To facilitate locating of items of interest the tree view can be searched.. Have a look at https://issues.apache.org/jira/secure/attachment/12348336/12348336_dependency.gif to get idea of what it will show. As we can see it shows dependencies for each component. For details of how this is implemented please have a look at comments of this JIRA. This is a request that please try these patches and let me know your comments on it. I think I liked it and these views will definatly be useful for debugging purpose, and from my expierance I can tell that all these views are trying to facilitate solving of problems which are difficult to tackle otherwise. Also notice that we may like to add another section in navigation for debug views as shown in https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif https://issues.apache.org/jira/secure/attachment/12348329/12348329_navigation.gif this is not implemented for now but we may do it once we agree to put the above views in console. Thanks in advance, please do have a look and comment. Rakesh On 7/20/06, *Erin Mulder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Aaron Mulder wrote: http://people.apache.org/~ammulder/classloaders.png http://people.apache.org/%7Eammulder/classloaders.png However, I'm not sure how useful it will be -- it'll show you dependencies at the class loader level, but it won't tell you which class loaders hold a particular class or which class loader you're actually getting at some point when an error is uncovered. Also, it still needs arrows. :) Right now, the code for that graph produces SVG. It would be great to make it interactive so that you could drag the nodes around, click on a node to load a div that shows which classes are loaded in it, and maybe even collapse certain branches. At JavaOne, I got a few simple JavaScript behaviors working with the graph prototype, but I'm not sure how complex it would be to add full-out drag and drop. Perhaps you can throw the code into the sandbox so other people can check it out and build on it? If I recall correctly, I was careful to make sure that all of its dependencies have Apache-compatible licenses, (which was actually quite difficult). Alternatively, someone could create and share a non-ASF-hosted plugin that makes use of one of the many LGPL graph libraries out there. Cheers, Erin
[jira] Created: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-128: - Attachment: 1.gif Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-128: - Attachment: 3.gif 2.gif Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-128: - Attachment: 5.gif 4.gif Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-129: - Attachment: 3.gif 2.gif 1.gif Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-129: - Attachment: 6.gif 5.gif 4.gif Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2685) database pool type emty in pool creation wizard - Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2685. -- Resolution: Fixed Fix Version/s: 2.0-M2 Assignee: David Jencks fixed in rev 493149 database pool type emty in pool creation wizard - Jetty --- Key: GERONIMO-2685 URL: https://issues.apache.org/jira/browse/GERONIMO-2685 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console, databases Affects Versions: 2.0-M1 Environment: Jetty distribution Reporter: Hernan Cunico Assigned To: David Jencks Fix For: 2.0-M2 Using the database pool wizard from the console to create a new pool will not show any database type. This is an issue in the Jetty distribution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Concurrency issues with SLSBs in Geronimo 1.2?
All, I think there may be some issues with SLSBs in Geronimo 1.2 and was wondering if anyone had experienced anything similar or if this is already a known issue. - Built Geronimo from geronimo/sever/branches/1.2 (01/04/2007) - Deployed Daytrader (built from geronimo/daytrader/branches/1.2) - Stressed EJB and Session to JDBC mode with multiple clients using load driver Both tests resulted in the following exception when more than 1 client was driven. NOTE: I went back and double checked on Geronimo 1.1.1 and this does not occur. java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:860) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator.exit (ConnectionTrackingCoordinator.java:92) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTrackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke( FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke( GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke( RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTracker$$EnhancerByCGLIB$$8f3374f8.exit (generated) at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke( NoConnectionEnlistingInterceptor.java:70) at org.apache.openejb.SystemExceptionInterceptor.invoke( SystemExceptionInterceptor.java:35) at org.apache.openejb.security.DefaultSubjectInterceptor.invoke( DefaultSubjectInterceptor.java:49) at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke( DefaultStatelessEjbContainer.java:178) at org.apache.openejb.slsb.DefaultStatelessEjbContainer$$FastClassByCGLIB$$7ad7a562.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke( FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke( GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke( GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke( RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB$$34d791e3.invoke (generated) at org.apache.openejb.AbstractEjbDeployment.invoke( AbstractEjbDeployment.java:195) at org.apache.openejb.proxy.EJBMethodInterceptor.intercept( EJBMethodInterceptor.java:145) at org.apache.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3eb3ed90.getQuote (generated) at org.apache.geronimo.samples.daytrader.TradeAction.getQuote( TradeAction.java:331) at org.apache.jsp.displayQuote_jsp._jspService( org.apache.jsp.displayQuote_jsp:71) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java :97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter( ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke( ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.doInclude( ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include( ApplicationDispatcher.java:499) at org.apache.jasper.runtime.JspRuntimeLibrary.include( JspRuntimeLibrary.java:966) at org.apache.jsp.quote_jsp._jspService(org.apache.jsp.quote_jsp:212 ) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java :97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:314) at
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-127: - Attachment: 4.gif 3.gif 2.gif Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462584
]
Aman Nanner commented on GERONIMO-2695:
---
Yep and this is my point. I believe your web.xml is wrong. Here is the changes
to the web.xml you put in your example and it works absolutely fine for me:
Hi,
I just tried the test case again with the modification to web.xml by adding:
---
auth-constraint
role-name*/role-name
/auth-constraint
---
and it in fact restricts access to the index.html. I think what you saw
instead was the login.html page, which has the same red background as
index.html, except that it says Login Page at the top. So this authorization
constraint is in fact restricting access to the resource to all authenticated
roles, and denying access to authenticated requests by redirecting to the login
page.
So this is not simulating the same behaviour as the absence of the
auth-constraint tag.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-127: - Attachment: 7.gif 6.gif 5.gif Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-127: - Attachment: 10.gif 9.gif 8.gif Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Help needed on http methods and regular expressions
It looks to me like the regex in the schema file does not quite match
the HTTP spec. First, the regex in the schema file does not allow
numbers (the HTTP spec does), and second it also allows for
non-english characters (the HTTP spec does not). The regex basically
allows Unicode letters only (see all L* categories on
http://www.fileformat.info/info/unicode/category/index.htm).
I think that regex should be something like:
[\u0021-\u007E-[\(\)\{\}@,:;\[\]\?\\/]]+
Jarek
On 1/4/07, David Jencks [EMAIL PROTECTED] wrote:
Chris Cardona has been trying to test the jacc 1.1 extended http-
method support by deploying slide (GERONIMO-1747) and I don't know
enough about regular expressions to see where the problem is.
The http 1.1 spec says:
(5.1.1) extension-method = token
(2.2)
token = 1*any CHAR except CTLs or separators
separators = ( | ) | | | @
| , | ; | : | \ |
| / | [ | ] | ? | =
| { | } | SP | HT
CHAR = any US-ASCII character (octets 0 - 127)
CTL= any US-ASCII control character
(octets 0 - 31) and DEL (127)
I think this means a hyphen is allowed in an extension-method.
The web-app 2.5 schema says:
xsd:simpleType name=http-methodType
xsd:annotation
xsd:documentation
A HTTP method type as defined in HTTP 1.1 section 2.2.
/xsd:documentation
/xsd:annotation
xsd:restriction base=xsd:token
xsd:pattern value=[\p{L}-[\p{Cc}\p{Z}]]+/
/xsd:restriction
/xsd:simpleType
I have roughly no clue what that means.
Xmlbeans is complaining:
cvc-datatype-valid.1.1: string value 'VERSION-CONTROL' does not match
patter
n for http-methodType in namespace http://java.sun.com/xml/ns/javaee,
error: cvc
-datatype-valid.1.1: string value 'BASELINE-CONTROL' does not match
pattern for
http-methodType in namespace http://java.sun.com/xml/ns/javaee]
I see 3 possiblilites:
1. I'm wrong and http 1.1 spec does not allow hyphens in extension
methods
2. sun is wrong and the regexp in http-methodType means something
other than the definition in the http 1.1 spec
3. xmlbeans is wrong and is not interpreting the regexp in the schema
correctly.
Anyone have a clue?
Help!
thanks
david jencks
[jira] Updated: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-129: - Attachment: webplans_editor cumulative-118-120-122-123-124-127-128-129.patch Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, webplans_editor cumulative-118-120-122-123-124-127-128-129.patch Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Trunk build failure: NoClassDefFoundError: javax/xml/stream/XMLStreamException
I ran into this last night and changing versions of the xmlbeans
plugin had no effect for me.
After some study I believe but can't yet prove that after the maven
folks telling me it was absolutely impossible to fix the xmlbeans
2.0.0 pom so it was correct, it got changed to a new and differently
broken form. I don't think this has anything to do with snapshots,
but rather instability of the allegedly permanent non-snapshot maven
repo.
Does anyone know if there is a changelog for the central repo?
thanks
david jencks
On Dec 27, 2006, at 5:18 PM, Jason Dillon wrote:
Thanks Kevan for looking into this.
This is one of the big issues I have with mvn and SNAPSHOT
artifacts... other peoples projects can break your projects build
with out any notice, no change log, and in many cases hours of
someone debugging a build to figure it out.
Perhaps we should simply not use *any* SNAPSHOT artifacts anymore?
And only use timestamp-build artifacts when non-released (snapshot
deployed) artifacts need to be consumed. The chances of those
*just changing* and breaking things are slimmer... though the
chance of them disappearing from a repo are much higher.
We could always fix that by finally setting up our own repo in svn,
maybe here for now:
https://svn.apache.org/repos/asf/geronimo/repository
Might hold anywhere from 50-100 megs of artifacts to support a
Geronimo Server build. And we could probably just start out with
some of the more risky artifacts, like this timestamp-build
artifact (and move over the local repos that are in the server/
trunk build).
Though eventually it would be nice to simply be able to prime the
local repo and build offline:
svn co https://svn.apache.org/repos/asf/geronimo/repository
cp -r repository/* ~/.m2/repository
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn -o
Though I'm not sure if the current ASF httpd config for
svn.apache.org will handle this well. I know that its possible to
setup httpd+svn to behave optimally for this, just not sure that
the ASF config asis will or not.
--jason
On Dec 27, 2006, at 9:33 AM, Kevan Miller wrote:
On Dec 26, 2006, at 6:55 PM, Jason Dillon wrote:
I've run the server/trunk build twice on JDK 1.5 twice from a
clean repo, both times it fails here:
snip
[INFO]
[INFO] Building Geronimo :: Service :: Builder
[INFO]task-segment: [install]
[INFO]
[INFO] snapshot org.codehaus.mojo:xmlbeans-maven-plugin:2.0.1-
SNAPSHOT: checking for updates from apache-snapshots
[INFO] snapshot org.codehaus.mojo:xmlbeans-maven-plugin:2.0.1-
SNAPSHOT: checking for updates from codehaus-snapshots
[INFO] snapshot org.codehaus.mojo:xmlbeans-maven-plugin:2.0.1-
SNAPSHOT: checking for updates from apache.snapshots
Downloading: http://snapshots.repository.codehaus.org/org/
codehaus/mojo/xmlbeans-maven-plugin/2.0.1-SNAPSHOT/xmlbeans-maven-
plugin-2.0.1-20061223.141616-9.pom
5K downloaded
Downloading: http://repository.codehaus.org/org/codehaus/mojo/
mojo/11/mojo-11.pom
7K downloaded
Downloading: http://snapshots.repository.codehaus.org/org/
codehaus/mojo/xmlbeans-maven-plugin/2.0.1-SNAPSHOT/xmlbeans-maven-
plugin-2.0.1-20061223.141616-9.jar
30K downloaded
[INFO] [tools:require-java-version {execution: validate-java-
version}]
[INFO] [xmlbeans:xmlbeans {execution: default}]
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] javax/xml/stream/XMLStreamException
[INFO]
[INFO] Trace
java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2395)
at java.lang.Class.getMethod0(Class.java:2642)
at java.lang.Class.getMethod(Class.java:1579)
at org.apache.xmlbeans.XmlBeans.buildMethod(XmlBeans.java:174)
at org.apache.xmlbeans.XmlBeans.buildNodeMethod(XmlBeans.java:195)
at org.apache.xmlbeans.XmlBeans.buildNodeToCursorMethod
(XmlBeans.java:232)
at org.apache.xmlbeans.XmlBeans.(XmlBeans.java:131)
at org.apache.xmlbeans.impl.schema.SchemaTypeLoaderBase.
(SchemaTypeLoaderBase.java:64)
at org.apache.xmlbeans.impl.tool.SchemaCompiler.compile
(SchemaCompiler.java:1063)
at org.codehaus.mojo.xmlbeans.AbstractXmlBeansPlugin.execute
(AbstractXmlBeansPlugin.java:270)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(DefaultLifecycleExecutor.java:534)
at
[jira] Updated: (GERONIMODEVTOOLS-129) Enhanced Editor Support for specifying GBeans in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-129: - Assignee: Sachin Patel (was: Shiva Kumar H R) Enhanced Editor Support for specifying GBeans in geronimo-web.xml - Key: GERONIMODEVTOOLS-129 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-129 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, webplans_editor cumulative-118-120-122-123-124-127-128-129.patch Enhancements to GBeans wizard: The wizard that comes up when Add or Edit button in GBeans section is clicked, is updated to provide enhanced support for adding/editing of sys:gbeanType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-123) Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462595 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-123: -- Please use the new cumulative patch available in GERONIMODEVTOOLS-129. Complete Editor Support for specifying EJB References, EJB Local References, Resource References Resource Environment References in geronimo-web.xml -- Key: GERONIMODEVTOOLS-123 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-123 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Fix For: 1.x Attachments: 1a.gif, 1b.gif, 1c.gif, 1d.gif, 1e.gif, 2a.gif, 2b.gif, 3a.gif, 3b.gif, 4a.gif, 4b.gif, GERONIMODEVTOOLS-118-120-122-123-124-consolidated.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462596 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-128: -- Please use the cumulative patch available in GERONIMODEVTOOLS-129 Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-128) Complete Editor Support for specifying Web Service References in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-128: - Assignee: Sachin Patel (was: Shiva Kumar H R) Complete Editor Support for specifying Web Service References in geronimo-web.xml - Key: GERONIMODEVTOOLS-128 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-128 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Fix For: 1.x Attachments: 1.gif, 2.gif, 3.gif, 4.gif, 5.gif Enhancements to Web Service References wizard: The wizard that comes up when Add or Edit button in Service Refs section is clicked, is updated to provide full support for adding/editing of gernaming:service-refType elements. Snapshots attached demonstrate this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462597 ] David Jencks commented on GERONIMO-2686: Most of a fix is in geronimo rev 493181 for trunk. I have to find the correct version of openejb and patch it, and also backport to g. 1.2. database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 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:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 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:325) 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:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462598
]
Jeff Genender commented on GERONIMO-2695:
-
I have a fix...and am testing now...
The problem is the TomcatGeronimoRealm need access to the defaultPrincipal and
it doesn't have it. I have made some updates and it looks like its working.
After a bit more testing I will commit.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work
[jira] Commented: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462603 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-127: -- Snapshot 1.gif shows the overall layout of the Security page. Snasphot 2.gif (or 3.gif) shows the wizard that pops up when Edit hyper link next to Default Principal label in General section is clicked. Snasphot 4.gif shows the wizard that pops up when Add/Edit buttons next to Named Credentials table in Default Principal wizard is clicked. Snasphot 5.gif shows the wizard that pops up when a security-role in Security Roles section is clicked. Snasphot 6.gif shows the wizard that pops up when editing a principal in Security Role wizard. Snasphots 7.gif 8.gif show the wizards that pop up when adding a principal in Security Role wizard. Snasphot 9.gif shows the wizard that pops up when Add/Edit buttons next to Distinguished Names table in Security Role wizard is clicked. Snapshot 10.gif shows the wizard-generated code. Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462604 ] Shiva Kumar H R commented on GERONIMODEVTOOLS-127: -- Please use the cumulative patch available in GERONIMODEVTOOLS-129 Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Shiva Kumar H R Fix For: 1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-127: - Assignee: Sachin Patel (was: Shiva Kumar H R) Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Fix For: 1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMODEVTOOLS-127) Complete Editor Support for specifying Security Configuration in geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-127: - Patch Info: [Patch Available] Complete Editor Support for specifying Security Configuration in geronimo-web.xml - Key: GERONIMODEVTOOLS-127 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-127 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Assigned To: Sachin Patel Fix For: 1.x Attachments: 1.gif, 10.gif, 2.gif, 3.gif, 4.gif, 5.gif, 6.gif, 7.gif, 8.gif, 9.gif The Security page of Geronimo Deployment Plan Editor is now enhanced and supports adding/editing of complete Security Configuration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2686. -- Resolution: Fixed openejb 2.3 fixed rev 493187. database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 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:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 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:325) 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:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks reopened GERONIMO-2686: ooops, still need to fix in 1.2 database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 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:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 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:325) 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:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Daytrader 1.2 release???
Happy New Year everyone... is it just me or are there several others out there having a hard time re-adjusting to a normal work schedule after the holidays? Anyway, to get the new year rolling, I was hoping to close out a number open issues with Daytrader and push out a 1.2 release by January 19th. I just sorted through the list of JIRAs and put together the following summary of items we can close out in the 1.2 release. - DAYTRADER-17: Dojo based interface (need to revamp current patch to use Dojo libraries provided by Geronimo) - DAYTRADER-22: Expose publishQuotePriceChange flag on config page - DAYTRADER-24: Clean up plan files (re-opened to remove old plans and add yoko dependency) - DAYTRADER-25: Update database schemas and impose ceiling on quote price updates - DAYTRADER-27: Remove unnecessary methods in TradeJDBC interface - DAYTRADER-29: Remove Async 1-phase mode In addition to these items, I would also like to take a stab at the following: - Update README - Revamp Config pages Thoughts/comments/suggestions? Thanks... Chris -- I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may. - Tyler Durden
Problems with web-app_2_5.xsd in specs/tags/geronimo-servlet_2.5_spec-1.1-M1/src/main/schema/??
I recall a flurry of activity to replace the sun schemas found in the earlier servlet spec jars with ones we wrote. However it looks to me as if this did not extend to the web-app_2_5.xsd schema which looks to me as if it has all of the sun annotations in it. It also appears to have the license before the xml declaration, making it invalid xml, and I see weird characters near the http- methodType: xsd:simpleType name=â㾀栀琀琀瀀ⴀ洀攀琀栀漀搀吀 礀瀀攀耀? xsd:annotation xsd:documentation A HTTP method type as defined in HTTP 1.1 section 2.2. /xsd:documentation /xsd:annotation xsd:restriction base=â㾀砀猀搀㨀琀漀欀攀渀 耀? xsd:pattern value=â㾀嬀尀瀀笀䰀紀ⴀ嬀尀瀀 笀䌀挀紀尀瀀笀娀紀崀崀⬀耀? / /xsd:restriction /xsd:simpleType This doesn't really make it harder for me to interpret the regexp, but it is more confusing. Any ideas on what if anything we should do? thanks david jencks
trunk build failure
Building trunk fails for me with: c:\development\geronimo\modules\geronimo-jetty6\src\main\java\org\apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[142,12] cannot find symbol symbol : constructor Session(java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session Jarek
Re: trunk build failure
Hi, I am fixing this problem right now. Should be fixed in about 10 minutes. Sorry for this problem. Thanks, Gianny On 06/01/2007, at 8:19 AM, Jarek Gawor wrote: Building trunk fails for me with: c:\development\geronimo\modules\geronimo-jetty6\src\main\java\org \apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[142,12] cannot find symbol symbol : constructor Session(java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session Jarek
Re: trunk build failure
On Jan 5, 2007, at 1:19 PM, Jarek Gawor wrote: Building trunk fails for me with: c:\development\geronimo\modules\geronimo-jetty6\src\main\java\org \apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[142,12] cannot find symbol symbol : constructor Session(java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session Jetty just changed their signature. I fixed our code. Regards, Alan
Re: Concurrency issues with ConnectionTracking in Geronimo 1.2?
That is a problem with the Geronimo Connector ConnectionTracking code not SLSB. Please file a JIRA. -dain On Jan 5, 2007, at 11:45 AM, Christopher Blythe wrote: All, I think there may be some issues with SLSBs in Geronimo 1.2 and was wondering if anyone had experienced anything similar or if this is already a known issue. - Built Geronimo from geronimo/sever/branches/1.2 (01/04/2007) - Deployed Daytrader (built from geronimo/daytrader/branches/1.2) - Stressed EJB and Session to JDBC mode with multiple clients using load driver Both tests resulted in the following exception when more than 1 client was driven. NOTE: I went back and double checked on Geronimo 1.1.1 and this does not occur. java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:860) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr ackingCoordinator.exit(ConnectionTrackingCoordinator.java:92) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr ackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke (generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.geronimo.connector.outbound.connectiontracking.ConnectionTr acker$$EnhancerByCGLIB$$8f3374f8.exit (generated) at org.apache.openejb.NoConnectionEnlistingInterceptor.invoke (NoConnectionEnlistingInterceptor.java:70) at org.apache.openejb.SystemExceptionInterceptor.invoke (SystemExceptionInterceptor.java :35) at org.apache.openejb.security.DefaultSubjectInterceptor.invoke (DefaultSubjectInterceptor.java:49) at org.apache.openejb.slsb.DefaultStatelessEjbContainer.invoke (DefaultStatelessEjbContainer.java :178) at org.apache.openejb.slsb.DefaultStatelessEjbContainer$ $FastClassByCGLIB$$7ad7a562.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance.java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke (RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (ProxyMethodInterceptor.java:96) at org.apache.openejb.StatelessEjbContainer$$EnhancerByCGLIB $$34d791e3.invoke(generated) at org.apache.openejb.AbstractEjbDeployment.invoke (AbstractEjbDeployment.java :195) at org.apache.openejb.proxy.EJBMethodInterceptor.intercept (EJBMethodInterceptor.java:145) at org.apache.openejb.proxy.SessionEJBObject$ $EnhancerByCGLIB$$3eb3ed90.getQuote(generated) at org.apache.geronimo.samples.daytrader.TradeAction.getQuote (TradeAction.java:331) at org.apache.jsp.displayQuote_jsp._jspService (org.apache.jsp.displayQuote_jsp:71) at org.apache.jasper.runtime.HttpJspBase.service (HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 690) at org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:332) at org.apache.jasper.servlet.JspServlet.serviceJspFile (JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service (JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java: 690) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter (ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke (ApplicationDispatcher.java :672) at org.apache.catalina.core.ApplicationDispatcher.doInclude (ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include (ApplicationDispatcher.java:499) at org.apache.jasper.runtime.JspRuntimeLibrary.include (JspRuntimeLibrary.java:966) at org.apache.jsp.quote_jsp._jspService (org.apache.jsp.quote_jsp:212) at org.apache.jasper.runtime.HttpJspBase.service ( HttpJspBase.java:97)
Re: trunk build failure
Builds fine now. Thanks! On 1/5/07, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Jan 5, 2007, at 1:19 PM, Jarek Gawor wrote: Building trunk fails for me with: c:\development\geronimo\modules\geronimo-jetty6\src\main\java\org \apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[142,12] cannot find symbol symbol : constructor Session(java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session Jetty just changed their signature. I fixed our code. Regards, Alan
Re: trunk build failure
Hello Alan, Thanks for fixing the build so quickly. I had some local changes that I was not able to commit before these Jetty6 API changes. Hopefully, I believe that the new API is now pretty stable as session migration, replication, fail-over, redistribution of session states when a JettyWebAppContext is stopped and sticky load-balancing is working OK. Thanks, Gianny On 06/01/2007, at 8:27 AM, Alan D. Cabrera wrote: On Jan 5, 2007, at 1:19 PM, Jarek Gawor wrote: Building trunk fails for me with: c:\development\geronimo\modules\geronimo-jetty6\src\main\java\org \apache\geronimo\jetty6\cluster\ClusteredSessionManager.java:[142,12] cannot find symbol symbol : constructor Session(java.lang.String) location: class org.mortbay.jetty.servlet.AbstractSessionManager.Session Jetty just changed their signature. I fixed our code. Regards, Alan
[jira] Commented: (GERONIMO-2695) Requests using Non-secure HTTP connections cannot access unsecured web resources
[
https://issues.apache.org/jira/browse/GERONIMO-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462617
]
Jeff Genender commented on GERONIMO-2695:
-
Ok I fixed it in 1.2 BRANCH and in 2.0 Trunk. Please try it and let me know if
its fixed (unfortunately you need to build Geronimo). I recommend trying 1.2
since 2.0 is in a state of flux at the moment.
Requests using Non-secure HTTP connections cannot access unsecured web
resources
Key: GERONIMO-2695
URL: https://issues.apache.org/jira/browse/GERONIMO-2695
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: security, Tomcat, web
Affects Versions: 1.1.1
Environment: Geronimo running on Windows XP
Reporter: Aman Nanner
Assigned To: Jeff Genender
Attachments: test.war
Consider the following fragment of my web.xml in my WAR:
security-constraint
display-nameUnsecure Constraint/display-name
web-resource-collection
web-resource-nameUnsecure Resource Collection/web-resource-name
url-pattern/common/error/*/url-pattern
url-pattern/common/includes/*/url-pattern
url-pattern/common/Message.jsp/url-pattern
url-pattern/common/resources/*/url-pattern
url-pattern/common/security/login.jsp/url-pattern
url-pattern/common/security/logout.jsp/url-pattern
url-pattern/servlet/branding/*/url-pattern
url-pattern/servlet/image/*/url-pattern
url-pattern/servlet/login/*/url-pattern
url-pattern/servlet/definecookie/url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
security-constraint
display-nameSecure Constraint/display-name
web-resource-collection
web-resource-nameSecure Resource Collection/web-resource-name
url-pattern//url-pattern
http-methodGET/http-method
http-methodPOST/http-method
/web-resource-collection
auth-constraint
role-nameMXSYSTEM/role-name
/auth-constraint
user-data-constraint
transport-guaranteeNONE/transport-guarantee
/user-data-constraint
/security-constraint
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/common/security/PreLogin.jsp/form-login-page
form-error-page/common/security/error.jsp/form-error-page
/form-login-config
/login-config
security-role
descriptionApplication System Role/description
role-nameMXSYSTEM/role-name
/security-role
There are two sets of web resources defined: a secured web resource
collection, and an unsecured web resource collection. The secured web
collection is by default everything that matches the / pattern. In the
unsecured web collection, we use specific URL patterns so that certain
resources can be accessed prior to login. Note that there is no security
role defined for the unsecured web resource collection, as these resources
should be available to every request.
The problem is that access is denied to to the unsecured web resource
collection, even though they are defined as unsecured. A blank HTML page is
returned instead of the appropriate resource. After some debugging, I
discovered what seems to be a bug in the
org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm class. Consider the
following code fragment in the hasResourceCollection(...) method:
// Which user principal have we already authenticated?
Principal principal = request.getUserPrincipal();
//If we have no principal, then we should use the default.
if (principal == null) {
return request.isSecure();
} else {
Subject currentCaller = ((JAASTomcatPrincipal)
principal).getSubject();
ContextManager.setCallers(currentCaller, currentCaller);
}
When I make an HTTP connection to an unsecure web resource, I am
unauthenticated before I can login. Thus, the principal in this case is
null. In the case of a null principal, the code seems to base its
authorization on whether or not the request is secure! This seems very
strange to me, as it should be able to accept normal, unauthenticated, HTTP
connections to unsecure web resources.
I tried accessing the unsecured web resources over HTTPS, and sure enough, I
was able to access them because of the secure connection. I'm not sure why
this works only over HTTPS...it should work in both cases.
--
This
[jira] Closed: (GERONIMO-2653) Inconsistencies between jetty6-builder and tomcat6-builder plan.xml files
[
https://issues.apache.org/jira/browse/GERONIMO-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor closed GERONIMO-2653.
-
Resolution: Fixed
Fix Version/s: 2.0
The patch in http://issues.apache.org/jira/browse/GERONIMO-2671 resolved the
inconsistencies mentioned in this bug.
Inconsistencies between jetty6-builder and tomcat6-builder plan.xml files
-
Key: GERONIMO-2653
URL: https://issues.apache.org/jira/browse/GERONIMO-2653
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment
Affects Versions: 2.0
Reporter: Jarek Gawor
Fix For: 2.0
1) One of the plans has an extra dependency on the j2ee-server module while
the other does not (enough though both tomcat6/pom.xml and jetty6/pom.xml
have dependency on j2ee-server module):
tomcat6-deployer/src/plan/plan.xml contains:
dependencies
dependency
groupId${pom.groupId}/groupId
artifactIdj2ee-server/artifactId
typecar/type
/dependency
dependency
groupId${pom.groupId}/groupId
artifactIdtomcat6/artifactId
typecar/type
/dependency
/dependencies
while jetty6-deployer/src/plan/plan.xml contains:
dependencies
dependency
groupId${pom.groupId}/groupId
artifactIdjetty6/artifactId
typecar/type
/dependency
/dependencies
2) Also, jetty6-deployer specifies CXFBuilder:
references name=WebServiceBuilder
pattern
nameCXFBuilder/name
/pattern
pattern
nameWebServiceBuilder/name
/pattern
pattern
nameUnavailableWebServiceBuilder/name
/pattern
/references
while tomcat6-deployer does not:
references name=WebServiceBuilder
pattern
nameWebServiceBuilder/name
/pattern
pattern
nameUnavailableWebServiceBuilder/name
/pattern
/references
It seems to me like these things should be consistent (unless of course there
is a good reason for it).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
[ https://issues.apache.org/jira/browse/GERONIMO-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender reopened GERONIMO-2339: - Assignee: Jeff Genender (was: Vamsavardhana Reddy) Empty auth-constraint tag in web app security-constraint does not prevent access to resource Key: GERONIMO-2339 URL: https://issues.apache.org/jira/browse/GERONIMO-2339 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, Tomcat Affects Versions: 1.1.1 Environment: Geronimo Tomcat 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Jeff Genender Fix For: 1.1.2, 1.2, 2.0 Attachments: g2339.war I have the following security constraint in web.xml security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint This means /forbidden/* is not accessible by any user. The permission woks fine if the application is deployed in Geronimo Jetty distribution. If the application is deployed in Geronimo Tomcat distribution, URLs /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
[ https://issues.apache.org/jira/browse/GERONIMO-2339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender closed GERONIMO-2339. --- Resolution: Duplicate Empty auth-constraint tag in web app security-constraint does not prevent access to resource Key: GERONIMO-2339 URL: https://issues.apache.org/jira/browse/GERONIMO-2339 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security, Tomcat Affects Versions: 1.1.1 Environment: Geronimo Tomcat 1.1.1 Reporter: Vamsavardhana Reddy Assigned To: Jeff Genender Fix For: 1.1.2, 1.2, 2.0 Attachments: g2339.war I have the following security constraint in web.xml security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint This means /forbidden/* is not accessible by any user. The permission woks fine if the application is deployed in Geronimo Jetty distribution. If the application is deployed in Geronimo Tomcat distribution, URLs /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2677) HttpSession Relocation - Sticky load-balancing via HTTP Cookie
[ https://issues.apache.org/jira/browse/GERONIMO-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gianny Damour closed GERONIMO-2677. --- Resolution: Fixed Fix Version/s: 2.0-M2 Sticky load-balancing is now working fine. HttpSession Relocation - Sticky load-balancing via HTTP Cookie -- Key: GERONIMO-2677 URL: https://issues.apache.org/jira/browse/GERONIMO-2677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: Clustering Reporter: Gianny Damour Assigned To: Gianny Damour Fix For: 2.0-M2 Attachments: GERONIMO-2677.patch, JETTY-2677.patch When an HttpSession is migrated from one node to another: * its id must be updated (the worker name suffix is to be set to the name of the node owning the HttpSession); and * the session cookie must be updated accordingly. The worker name suffix, which can be retrieved from the session cookie, can be leverage to configure sticky load-balancing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SM-804) Documentation for XPath Router is missing examples
Documentation for XPath Router is missing examples -- Key: SM-804 URL: https://issues.apache.org/activemq/browse/SM-804 Project: ServiceMix Issue Type: Bug Reporter: Robert H. Pollack Priority: Trivial The page that documents the XPath Router has blank areas where the examples should be. See the page at http://www.servicemix.org/site/xpath-router.html, which includes sentences such as The following is an example routing and transformation template, followed by a couple of blank lines. Based on a similar CodeHaus page (http://servicemix.codehaus.org/XPath+Router), which also fails to show the examples, but which displays error messages, I believe the problem is due to bad server-side includes. The files which are intended to be included on the page seem to be the following (all of which are distributed with the ServiceMix release): src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router-example.xml src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router.xsl src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/split.xsl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-804) Documentation for XPath Router is missing examples
[ https://issues.apache.org/activemq/browse/SM-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SM-804. Resolution: Fixed Fix Version/s: 3.1 Assignee: Guillaume Nodet Fixed Documentation for XPath Router is missing examples -- Key: SM-804 URL: https://issues.apache.org/activemq/browse/SM-804 Project: ServiceMix Issue Type: Bug Reporter: Robert H. Pollack Assigned To: Guillaume Nodet Priority: Trivial Fix For: 3.1 The page that documents the XPath Router has blank areas where the examples should be. See the page at http://www.servicemix.org/site/xpath-router.html, which includes sentences such as The following is an example routing and transformation template, followed by a couple of blank lines. Based on a similar CodeHaus page (http://servicemix.codehaus.org/XPath+Router), which also fails to show the examples, but which displays error messages, I believe the problem is due to bad server-side includes. The files which are intended to be included on the page seem to be the following (all of which are distributed with the ServiceMix release): src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router-example.xml src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router.xsl src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/split.xsl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-804) Documentation for XPath Router is missing examples
[ https://issues.apache.org/activemq/browse/SM-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37819 ] Robert H. Pollack commented on SM-804: -- Wow! I couldn't ask for faster service than that! Thanks. Documentation for XPath Router is missing examples -- Key: SM-804 URL: https://issues.apache.org/activemq/browse/SM-804 Project: ServiceMix Issue Type: Bug Reporter: Robert H. Pollack Assigned To: Guillaume Nodet Priority: Trivial Fix For: 3.1 The page that documents the XPath Router has blank areas where the examples should be. See the page at http://www.servicemix.org/site/xpath-router.html, which includes sentences such as The following is an example routing and transformation template, followed by a couple of blank lines. Based on a similar CodeHaus page (http://servicemix.codehaus.org/XPath+Router), which also fails to show the examples, but which displays error messages, I believe the problem is due to bad server-side includes. The files which are intended to be included on the page seem to be the following (all of which are distributed with the ServiceMix release): src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router-example.xml src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/router.xsl src/servicemix-components/src/test/resources/org/apache/servicemix/components/xslt/split.xsl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462652 ] David Jencks commented on GERONIMO-2686: I missed changes in configs in previous commit in trunk. rev 493249. database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 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:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 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:325) 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:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1086) Can't use SQL Server 2005 for persistence
[ https://issues.apache.org/activemq/browse/AMQ-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baskar Duraikannu updated AMQ-1086: --- Attachment: MSSql2005.zip Can't use SQL Server 2005 for persistence - Key: AMQ-1086 URL: https://issues.apache.org/activemq/browse/AMQ-1086 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1.0 Reporter: Tony Voss Attachments: MSSql2005.zip When using SQL Server 2005 for persistence the following exception is thrown: java.sql.SQLException: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR. at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365) at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781) at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224) at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:628) at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:525) at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:487) at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.execute(JtdsPreparedStatement.java:475) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.start(DefaultDatabaseLocker.java:59) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:175) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:223) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1251) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1209) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:508) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:394) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:47) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1062) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1029) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:420) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:245) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:242) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:290) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:348) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:161) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:51) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:41) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:57) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:82) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:63) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:65) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.activemq.console.Main.runTaskClass(Main.java:159) at org.apache.activemq.console.Main.main(Main.java:91) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (AMQ-1086) Can't use SQL Server 2005 for persistence
[ https://issues.apache.org/activemq/browse/AMQ-1086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_37820 ] Baskar Duraikannu commented on AMQ-1086: I was learning Persistence using SQL 2005 and I got the same error mentioned. Please see MSSql2005.zip file attached. It seemed to have resolved the issue. Can't use SQL Server 2005 for persistence - Key: AMQ-1086 URL: https://issues.apache.org/activemq/browse/AMQ-1086 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1.0 Reporter: Tony Voss Attachments: MSSql2005.zip When using SQL Server 2005 for persistence the following exception is thrown: java.sql.SQLException: Line 1: FOR UPDATE clause allowed only for DECLARE CURSOR. at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:365) at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2781) at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2224) at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:628) at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:525) at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:487) at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.execute(JtdsPreparedStatement.java:475) at org.apache.activemq.store.jdbc.DefaultDatabaseLocker.start(DefaultDatabaseLocker.java:59) at org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.start(JDBCPersistenceAdapter.java:175) at org.apache.activemq.store.journal.JournalPersistenceAdapter.start(JournalPersistenceAdapter.java:223) at org.apache.activemq.broker.BrokerService.createRegionBroker(BrokerService.java:1251) at org.apache.activemq.broker.BrokerService.createBroker(BrokerService.java:1209) at org.apache.activemq.broker.BrokerService.getBroker(BrokerService.java:508) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:394) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBeanBrokerService.java:47) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1062) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1029) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:420) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:245) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:141) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:242) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:156) at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:290) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:348) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:161) at org.apache.xbean.spring.context.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:51) at org.apache.activemq.xbean.XBeanBrokerFactory.createBroker(XBeanBrokerFactory.java:41) at org.apache.activemq.broker.BrokerFactory.createBroker(BrokerFactory.java:57) at org.apache.activemq.console.command.StartCommand.startBroker(StartCommand.java:82) at org.apache.activemq.console.command.StartCommand.runTask(StartCommand.java:63) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.runTask(ShellCommand.java:65) at org.apache.activemq.console.command.AbstractCommand.execute(AbstractCommand.java:50) at org.apache.activemq.console.command.ShellCommand.main(ShellCommand.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.activemq.console.Main.runTaskClass(Main.java:159) at
[jira] Closed: (GERONIMO-2686) database creation pool wizzard fails to deploy
[ https://issues.apache.org/jira/browse/GERONIMO-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2686. -- Resolution: Fixed Relevant stuff ported to 1.2 in rev 493252. I can't find out what if any openejb2 version is supposed to go with g 1.2 so if the correct version is not 2.3 openejb2 may not build. database creation pool wizzard fails to deploy -- Key: GERONIMO-2686 URL: https://issues.apache.org/jira/browse/GERONIMO-2686 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2, 2.0-M1 Environment: Tomcat distribution Reporter: Hernan Cunico Assigned To: David Jencks Priority: Critical Fix For: 1.2, 2.0-M2 From the console, the database creation pool wizzard does not create a plan and fails to deploy it with no warnings on the Administration Console. The terminal shows the following error: ERROR [DatabasePoolPortlet] Unable to save connection pooljavax.enterprise.deploy.spi.exceptions.InvalidModuleException: Not supported at org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:297) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:341) 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:683) at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:585) 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:325) 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:542) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:818) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
possible 1.2 problem
I fixed GERONIMO-2686 in 1.2 but have not been able to figure out what if any openejb2 version is supposed to go with it. If the openejb2 version exists and is not 2.3 (trunk) the changes may have broken the openejb2 build. See rev 493187 in openejb2 thanks david jencks
Re: possible 1.2 problem
On Jan 5, 2007, at 4:31 PM, David Jencks wrote: I fixed GERONIMO-2686 in 1.2 but have not been able to figure out what if any openejb2 version is supposed to go with it. If the openejb2 version exists and is not 2.3 (trunk) the changes may have broken the openejb2 build. See rev 493187 in openejb2 Hopefully this will refresh your memory. Dec 14 15:18:21 dblevins you can do anything you want to the interfaces as long as you keep them compatible in 1.2 and 2.0m2 Dec 14 15:18:34 dblevins 1.2 isn't frozen Dec 14 15:18:48 dblevins it's just been released as a beta Dec 14 15:20:29 djencks ok Dec 14 15:20:37 dblevins so to reiterate, you can make any change you want to 2.3 as long is you make it work in 1.2 and 2.0-m1 Dec 14 15:20:42 dblevins err m2 Dec 14 15:20:47 djencks ok Dec 14 15:20:52 dblevins and this is only temporary Dec 14 15:20:54 djencks I think I can live with that Dec 14 15:20:59 dblevins like 2-3 weeks tops Dec 14 15:21:05 djencks we hope :-) Dec 14 15:21:12 dblevins :) Dec 14 15:21:18 djencks OK, thanks Dec 14 15:21:27 dblevins thanks david! http://www.uwyn.com/drone/log/bevinbot/geronimo/20061214 -David
[jira] Commented: (GERONIMO-2607) GoperationInfo should include the return type for the operation
[ https://issues.apache.org/jira/browse/GERONIMO-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12462669 ] Anita Kulshreshtha commented on GERONIMO-2607: -- From a discussion on the mailing list: http://www.nabble.com/Re%3A-svn-commit%3A-r485321---in--geronimo-server-trunk-modules%3A-geronimo-kernel-src-main-java-org-apache-geronimo-gbean--geronimo-kernel-src-main-java-org-apache-geronimo-gbean-runtime--geronimo-kernel-src-test-java-org-apache-geronimo-gbean--geronimo-k-p7857544.html The kernel.diff patch: 1. deprecates addOperation(..) methods from GBeanInfoBuilder. These are redundant because the operations added by these methods were already being added by addInterface(..). A side effect of this is that non-existent or inconsistent operations can not be added. 2. Makes the new addOpearation methods (added in rev 485321) private 3. updates GBeanInfoTest These changes are sufficient to provide a return type for operations to JMX tools. GoperationInfo should include the return type for the operation --- Key: GERONIMO-2607 URL: https://issues.apache.org/jira/browse/GERONIMO-2607 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Attachments: kernel.diff, modules.diff, operations.jpg When the operations are viewed by jconsole the return type is not avaialble. GOpeartionInfo should keep the retrunType information. This will break backward compatibility of GBeanInfo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2607) GoperationInfo should include the return type for the operation
[ https://issues.apache.org/jira/browse/GERONIMO-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anita Kulshreshtha updated GERONIMO-2607: - Attachment: kernel.diff GoperationInfo should include the return type for the operation --- Key: GERONIMO-2607 URL: https://issues.apache.org/jira/browse/GERONIMO-2607 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: kernel Affects Versions: 2.0 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Attachments: kernel.diff, kernel.diff, modules.diff, operations.jpg When the operations are viewed by jconsole the return type is not avaialble. GOpeartionInfo should keep the retrunType information. This will break backward compatibility of GBeanInfo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Trunk build failure: NoClassDefFoundError: javax/xml/stream/XMLStreamException
On Jan 5, 2007, at 3:27 PM, David Jencks wrote: I ran into this last night and changing versions of the xmlbeans plugin had no effect for me. After some study I believe but can't yet prove that after the maven folks telling me it was absolutely impossible to fix the xmlbeans 2.0.0 pom so it was correct, it got changed to a new and differently broken form. I don't think this has anything to do with snapshots, but rather instability of the allegedly permanent non-snapshot maven repo. Does anyone know if there is a changelog for the central repo? Works for me, if i remove 2.0.1-SNAPSHOT from my local repo (i.e. rm - rf ~/.m2/repository/org/codehaus/mojo/xmlbeans-maven-plugin/2.0.1- SNAPSHOT). Well, you can use the date of the snapshot as a rough estimate of when a change was introduced. So, what do the maven folks say we are supposed to do about this? --kevan
[jira] Created: (AMQ-1121) Kaha DB hangs on restart
Kaha DB hangs on restart Key: AMQ-1121 URL: https://issues.apache.org/activemq/browse/AMQ-1121 Project: ActiveMQ Issue Type: Bug Components: Message Store Affects Versions: 4.1.0 Environment: Windows XP, NetApp Reporter: Vadim Pesochinskiy Priority: Blocker Fix For: 4.1.0 I run a bunch or messages through AMQ, then restarted AMQ and it hangs. Following are the last messages that I see. AMQ is not listening on the configured port. 2007-01-06 01:35:29,723 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 810, file = 1, size = 219 2007-01-06 01:35:29,754 [JMX connector ] INFO ManagementContext - JMX consoles can connect to service:jmx:rmi:///jndi/rmi://localhost:11099/jmxrmi 2007-01-06 01:35:32,660 [main ] DEBUG DataManager - End of data file reached at (header was invalid): offset = 88244949, file = 5, size = 100856 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: possible 1.2 problem
On Jan 5, 2007, at 7:31 PM, David Jencks wrote: I fixed GERONIMO-2686 in 1.2 but have not been able to figure out what if any openejb2 version is supposed to go with it. If the openejb2 version exists and is not 2.3 (trunk) the changes may have broken the openejb2 build. See rev 493187 in openejb2 I've updated server/trunk/pom.xml and server/branches/1.2/pom.xml to specify the OpenEJB version as '2.3-incubating-SNAPSHOT' -- the version of OpenEJB built by openejb/trunk/openejb2 I tested the JMS console wizard and it works for me... --kevan
