RE: Question regard to org.activemq.network.jms package
Thanks Rob -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 08, 2006 10:27 AM To: activemq-dev@geronimo.apache.org Subject: Re: Question regard to org.activemq.network.jms package Hi Li, your requested changes are in SVN head cheers, Rob On 8 Feb 2006, at 17:31, Li, Fan wrote: Hi: I am wondering if it is possible to have a couple small changes made to the classes in the org.activemq.network.jms package. Right now the TopicBridge class has a protected JmsTopicConnector, which implements the method createReplyToTopicBridge. This means if I have another JmsConnector that needs to use TopicBridge; it has to inherit from JmsTopicConnector. And it is also a problem if my reply to bridge is not a TopicBridge. So I am wondering if it is okay to include a more general abstract method createReplyToBridge in the JmsConnector class and have all the subclasses to it implement this method, and make TopicBridge have a protected JmsConnector instead of JmsTopicConnector, so other subclass of JmsConnecor can also use TopicBridge. (The same goes for QueueBridge.) Thanks Fan Li -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: Friday, February 03, 2006 10:40 AM To: activemq-dev@geronimo.apache.org Subject: Re: Question regard to org.activemq.network.jms package Yes, And make sure that they use the Apache Copyright headers on them. Regards, Hiram On Feb 3, 2006, at 1:19 PM, Li, Fan wrote: Hi Hiram: What do I need to include in this patch? Just the source code for my classes? Thanks Fan Li -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: Friday, February 03, 2006 10:12 AM To: activemq-dev@geronimo.apache.org Subject: Re: Question regard to org.activemq.network.jms package Hi Fan, If you submit a patch, we would be glad to add them to the next release. Regards, Hiram On Feb 3, 2006, at 1:07 PM, Li, Fan wrote: Hi: I am currently working on a project that would create a bridge that enables the communication of applications written using our messaging system to those applications written using ActiveMQ. The ActiveMQ package org.activemq.network.jms provides most of the functionalities I needed in my project. However, I believe that ActiveMQ only provide foreign Topic to ActiveMQ Topic and foreign Queue to ActiveMQ Queue bridges, but my project has the need for Queue to Topic and Topic to Queue bridges. I am going to write my own classes for these, but I am wondering if ActiveMQ would provide these functionalities in the future. Thanks Fan Li
Re: Maven 2 Repository for Geronimo
Okay... though I think it should be relatively simple... I had been chatting with some Atlassian developers about potentially using the maven2 repo for plugin discover/download for confluence and jira. From chatting with some maven2 peeps looks like it might be relatively simple to get something basic functional. I think it would be positive direction for Geronimo... as if it works, then G would be able to pull artifacts from multiple local and remote repositories. If I can get it to work, and objections to potentially including this? --jason On Feb 7, 2006, at 12:27 PM, Dain Sundstrom wrote: Cuz, I think that is will be too much work to get in and tested. We're trying to get this done in the next few days, so it is just easier to write one that can read the m2 layout. -dain On Feb 7, 2006, at 1:39 PM, Jason Dillon wrote: Why not reuse the Maven2 code to handle repository access/ aggregation/etc ? --jason On Feb 6, 2006, at 9:00 PM, Dain Sundstrom wrote: I have added a repository that can read a repo using the maven 2 layout. This required a few changes to the Repository interface, so please take a look at it. The code is the configId branch that David Jencks and I are working on for the quick 1.1 release (old 1.0.1). Specifically, Aaron can you take a look at this? It will impact the console code and I don't want to create a mess for you to deal with. http://svn.apache.org/viewcvs.cgi/geronimo/branches/configid/ modules/system/src/java/org/apache/geronimo/system/repository/ Maven2Repository.java Thanks, -dain
[jira] Created: (GERONIMO-1601) NPE upon transaction recovery - HOWLLog does not defined an Xid Factory
NPE upon transaction recovery - HOWLLog does not defined an Xid Factory --- Key: GERONIMO-1601 URL: http://issues.apache.org/jira/browse/GERONIMO-1601 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Gianny Damour Assigned to: Gianny Damour Problem reported by Jason Dillon: I'm not sure how I got G into this state, but its barfing on boot with: snip Booting Geronimo Kernel (in Java 1.4.2_09)... Started configuration 1/16 0s geronimo/rmi-naming/1.0/car 18:57:25,971 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.NullPointerException at org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362) at org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220) /snip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in module javamail-transport
Hi, In this situation, I think that you should try: maven -U clean install -U means that newer versions of plugins should be checked from the plugin repositories. Thanks, Gianny Vamsavardhana Reddy wrote: Got the following error trying to build geronimo-spec-javamail. Help C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamailc:\maven-2.0.2\bi \mvn clean install [INFO] Scanning for projects... [INFO] --- [INFO] Building Java Mail [INFO]task-segment: [clean, install] [INFO] --- [INFO] [clean:clean] [INFO] --- [ERROR] BUILD ERROR [INFO] --- [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not ex st or no valid version could be found [INFO] --- [INFO] For more information, run Maven with the -e switch [INFO] --- [INFO] Total time: 2 seconds [INFO] Finished at: Wed Feb 08 16:11:36 IST 2006 [INFO] Final Memory: 2M/4M [INFO] --- On 2/7/06, *Bruce Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo ( http://geronimo.apache.org/) Castor (http://castor.org/)
Re: Compilation errors in module javamail-transport
Thanks Gianny. That worked!! -VamsiOn 2/8/06, Gianny Damour [EMAIL PROTECTED] wrote: Hi,In this situation, I think that you should try:maven -U clean install-U means that newer versions of plugins should be checked from theplugin repositories.Thanks,GiannyVamsavardhana Reddy wrote: Got the following error trying to build geronimo-spec-javamail.Help C:\GeronimoSource\geronimo\specs\trunk\geronimo-spec-javamailc:\maven-2.0.2\bi \mvn clean install [INFO] Scanning for projects... [INFO] --- [INFO] Building Java Mail [INFO]task-segment: [clean, install] [INFO] --- [INFO] [clean:clean] [INFO] --- [ERROR] BUILD ERROR [INFO] --- [INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin ' does not ex st or no valid version could be found [INFO] --- [INFO] For more information, run Maven with the -e switch [INFO] --- [INFO] Total time: 2 seconds [INFO] Finished at: Wed Feb 08 16:11:36 IST 2006 [INFO] Final Memory: 2M/4M [INFO] --- On 2/7/06, *Bruce Snyder* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec- 1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo ( http://geronimo.apache.org/) Castor (http://castor.org/)
[jira] Updated: (GERONIMO-1602) Switching from Tomcat causes error in JAAS module: Unable to instantiate login module
[ http://issues.apache.org/jira/browse/GERONIMO-1602?page=all ]
Karsten Voges updated GERONIMO-1602:
Attachment: geronimo-JAAS-login-error.txt
Switching from Tomcat causes error in JAAS module: Unable to instantiate
login module
---
Key: GERONIMO-1602
URL: http://issues.apache.org/jira/browse/GERONIMO-1602
Project: Geronimo
Type: Bug
Components: security, Tomcat
Versions: 1.0
Environment: Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat, .zip)
Reporter: Karsten Voges
Attachments: geronimo-JAAS-login-error.txt
I have a problem with porting a Tomcat application to Geronimo. The error
stacktrace is attached.
I deployed the war without any deployment plan and the app seams to be
working (JSPs work and the startup-servlet works as well)
But the JAASLoginModule was missing, so I could not log in. - so far no
Problem!
Afterwards I configured a security realm with the console and after a restart
my app does not complain about a missing LoginModule but throws the attached
error stacktrace.
For Tomcat I do the following:
in catalina.properties I set
###JAAS
java.security.auth.login.config=${catalina.base}/conf/login.config
and the login.config looks like this:
MyApp {
de.jato.security.auth.module.JatoServletLoginModule Sufficient
loginServlet=/login/login.jsp;
};
I tried to use a special geronimo-web.xml where I set the
context-priority-classloadertrue/context-priority-classloader
But I still get the same error:
javax.security.auth.login.LoginException:
org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate
login module
Caused by: java.lang.ClassNotFoundException:
de.jato.security.auth.module.JatoServletLoginModule
Am I doing something wrong? The class is in the war I deployed, and
everything works fine in Tomcat.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1601) NPE upon transaction recovery - HOWLLog does not defined an Xid Factory
[ http://issues.apache.org/jira/browse/GERONIMO-1601?page=all ] David Jencks closed GERONIMO-1601: -- Resolution: Duplicate Assign To: David Jencks (was: Gianny Damour) Duplicate of GERONIMO-1599 NPE upon transaction recovery - HOWLLog does not defined an Xid Factory --- Key: GERONIMO-1601 URL: http://issues.apache.org/jira/browse/GERONIMO-1601 Project: Geronimo Type: Bug Versions: 1.0 Reporter: Gianny Damour Assignee: David Jencks Problem reported by Jason Dillon: I'm not sure how I got G into this state, but its barfing on boot with: snip Booting Geronimo Kernel (in Java 1.4.2_09)... Started configuration 1/16 0s geronimo/rmi-naming/1.0/car 18:57:25,971 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-server/1.0/car,J2EEServer=geronimo,j2eeType=TransactionLog,name=HOWLTransactionLog java.lang.NullPointerException at org.apache.geronimo.transaction.log.HOWLLog$GeronimoReplayListener.onRecord(HOWLLog.java:362) at org.objectweb.howl.log.xa.XALogger.replayActiveTx(XALogger.java:1059) at org.apache.geronimo.transaction.log.HOWLLog.doStart(HOWLLog.java:220) /snip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1600) Non-standard artifact in repository cause Common Libraries portlet to fail
[ http://issues.apache.org/jira/browse/GERONIMO-1600?page=all ]
Aaron Mulder closed GERONIMO-1600:
--
Fix Version: 1.0.1
Resolution: Duplicate
Assign To: Aaron Mulder
This should already be fixed in 1.0 branch and HEAD
Non-standard artifact in repository cause Common Libraries portlet to fail
--
Key: GERONIMO-1600
URL: http://issues.apache.org/jira/browse/GERONIMO-1600
Project: Geronimo
Type: Bug
Components: console
Versions: 1.0
Reporter: Jason Dillon
Assignee: Aaron Mulder
Priority: Critical
Fix For: 1.0.1
I've notice that if there is a non-standard artifact in the repository/ that
the Common Libraries portlet chokes.
For example:
{code}
touch geronimo-1.0/repository/foo
{code}
Then hit the Common Libraries porlet, and it will puke with something like:
{noformat}
22:18:43,823 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error
while dispatching portlet.
javax.portlet.PortletException
at
org.apache.geronimo.console.repository.RepositoryViewPortlet.doView(RepositoryViewPortlet.java:206)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
at
org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
at
org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
at
org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
at
org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
at
org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
at
org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp:65)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
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:688)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428)
at
org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830)
at
org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:170)
at
org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471)
at org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:283)
at org.mortbay.jetty.servlet.Dispatcher.include(Dispatcher.java:163)
at
org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
at
org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp:64)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
at
[jira] Commented: (GERONIMO-1602) Switching from Tomcat causes error in JAAS module: Unable to instantiate login module
[
http://issues.apache.org/jira/browse/GERONIMO-1602?page=comments#action_12365557
]
David Jencks commented on GERONIMO-1602:
This is a known problem, that gbeans in a web plan cannot use the classes in
the war, and in fact the war classes are not in the configuration classloader.
The only solution at the moment is to move or copy the classes to a jar outside
the war and use a dependency element to that jar in the plan that contains the
login gbeans.
We might be able to solve this problem in the 1.1 release but the code is not
yet written.
See GERONIMO-289
Switching from Tomcat causes error in JAAS module: Unable to instantiate
login module
---
Key: GERONIMO-1602
URL: http://issues.apache.org/jira/browse/GERONIMO-1602
Project: Geronimo
Type: Bug
Components: security, Tomcat
Versions: 1.0
Environment: Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat, .zip)
Reporter: Karsten Voges
Attachments: geronimo-JAAS-login-error.txt
I have a problem with porting a Tomcat application to Geronimo. The error
stacktrace is attached.
I deployed the war without any deployment plan and the app seams to be
working (JSPs work and the startup-servlet works as well)
But the JAASLoginModule was missing, so I could not log in. - so far no
Problem!
Afterwards I configured a security realm with the console and after a restart
my app does not complain about a missing LoginModule but throws the attached
error stacktrace.
For Tomcat I do the following:
in catalina.properties I set
###JAAS
java.security.auth.login.config=${catalina.base}/conf/login.config
and the login.config looks like this:
MyApp {
de.jato.security.auth.module.JatoServletLoginModule Sufficient
loginServlet=/login/login.jsp;
};
I tried to use a special geronimo-web.xml where I set the
context-priority-classloadertrue/context-priority-classloader
But I still get the same error:
javax.security.auth.login.LoginException:
org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate
login module
Caused by: java.lang.ClassNotFoundException:
de.jato.security.auth.module.JatoServletLoginModule
Am I doing something wrong? The class is in the war I deployed, and
everything works fine in Tomcat.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1602) Switching from Tomcat causes error in JAAS module: Unable to instantiate login module
[
http://issues.apache.org/jira/browse/GERONIMO-1602?page=comments#action_12365559
]
Karsten Voges commented on GERONIMO-1602:
-
thanks for clarifying and providing a workaround. Still, I am looking forward
to a general solution.
Switching from Tomcat causes error in JAAS module: Unable to instantiate
login module
---
Key: GERONIMO-1602
URL: http://issues.apache.org/jira/browse/GERONIMO-1602
Project: Geronimo
Type: Bug
Components: security, Tomcat
Versions: 1.0
Environment: Windows XP Prof, JDK 1.5.0_06, Geronimo 1.0 (Tomcat, .zip)
Reporter: Karsten Voges
Attachments: geronimo-JAAS-login-error.txt
I have a problem with porting a Tomcat application to Geronimo. The error
stacktrace is attached.
I deployed the war without any deployment plan and the app seams to be
working (JSPs work and the startup-servlet works as well)
But the JAASLoginModule was missing, so I could not log in. - so far no
Problem!
Afterwards I configured a security realm with the console and after a restart
my app does not complain about a missing LoginModule but throws the attached
error stacktrace.
For Tomcat I do the following:
in catalina.properties I set
###JAAS
java.security.auth.login.config=${catalina.base}/conf/login.config
and the login.config looks like this:
MyApp {
de.jato.security.auth.module.JatoServletLoginModule Sufficient
loginServlet=/login/login.jsp;
};
I tried to use a special geronimo-web.xml where I set the
context-priority-classloadertrue/context-priority-classloader
But I still get the same error:
javax.security.auth.login.LoginException:
org.apache.geronimo.common.GeronimoSecurityException: Unable to instantiate
login module
Caused by: java.lang.ClassNotFoundException:
de.jato.security.auth.module.JatoServletLoginModule
Am I doing something wrong? The class is in the war I deployed, and
everything works fine in Tomcat.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Reopened: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=all ] Jeff Genender reopened GERONIMO-1480: - Looking into new issue for TGR Cross context include does not set jacc contextID for 2nd web app. (Tomcat only) Key: GERONIMO-1480 URL: http://issues.apache.org/jira/browse/GERONIMO-1480 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0.1, 1.1 Reporter: David Jencks Assignee: Jeff Genender Priority: Blocker Fix For: 1.1, 1.0.1 If you do a cross context include from web app A to web app B, the jacc contextID fetched from PolicyContext when you evaluate isUserInRole in web app B is the contextID for A, not B. Presumably the cross context dispatch does not go through the PolicyContextValve for B. Here's a thread trace that demonstrates this, with a couple annotations. [EMAIL PROTECTED] daemon prio=5, in group main, status: RUNNING implies():80, GeronimoPolicy.java implies():46, JaasPolicyCoordinator.java implies():189, ProtectionDomain.java checkPermission():254, AccessControlContext.java hasRole():248, TomcatGeronimoRealm.java isUserInRole():2128, Request.java isUserInRole():761, RequestFacade.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():265, PortletRequestImpl.java _jspService():46, roles.jsp service():97, HttpJspBase.java service():688, HttpServlet.java service():322, JspServletWrapper.java serviceJspFile():314, JspServlet.java service():264, JspServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java include():72, JetspeedRequestDispatcher.java doView():363, GenericServletPortlet.java doDispatch():250, GenericPortlet.java render():178, GenericPortlet.java render():102, JetspeedPortletInstance.java THIS IS WEB APP B doGet():230, JetspeedContainerServlet.java service():595, HttpServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java THIS IS A INCLUDING B invoke():213, ServletPortletInvoker.java render():125, ServletPortletInvoker.java renderPortlet():119, PortletContainerImpl.java renderPortlet():120, JetspeedPortletContainerWrapper.java execute():120, RenderingJobImpl.java renderNow():110, PortletRendererImpl.java aggregateAndRender():199, PageAggregatorImpl.java aggregateAndRender():182, PageAggregatorImpl.java build():106, PageAggregatorImpl.java invoke():48, AggregatorValve.java invokeNext():166, JetspeedPipeline.java invoke():132, ActionValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():76, ContainerValve.java invokeNext():166, JetspeedPipeline.java invoke():100, DecorationValve.java invokeNext():166, JetspeedPipeline.java invoke():179, ProfilerValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():143, LoginValidationValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():148, PasswordCredentialValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():168, LocalizationValveImpl.java invokeNext():166, JetspeedPipeline.java run():117, AbstractSecurityValve.java doPrivileged():-1, AccessController.java doAsPrivileged():437, Subject.java invoke():111, AbstractSecurityValve.java invokeNext():166, JetspeedPipeline.java invoke():55, PortalURLValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():128, CapabilityValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():145, JetspeedPipeline.java service():231, JetspeedEngine.java THIS IS WEB APP A: doGet():226, JetspeedServlet.java service():595, HttpServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java
[jira] Commented: (GERONIMODEVTOOLS-62) NPE in starting Geronimo server
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-62?page=comments#action_12365583 ] Sachin Patel commented on GERONIMODEVTOOLS-62: -- As we discussed, enable the geronimo facet during project creation and rerun the scenario. NPE in starting Geronimo server --- Key: GERONIMODEVTOOLS-62 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-62 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: WTP M200602070438 + Geronimo 0206_1658 plugins + Geronimo 1.0 server When going through bottom-up Web service scenario selecting to generate proxy and test Web service, the Geronimo server comes up with the following error in the console: Geronimo startup complete 11:27:42,031 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd 11:28:08,879 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd 11:28:55,627 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd 11:28:55,787 ERROR [EngineConfigurationFactoryServlet] Unable to find config file. Creating new servlet engine config file: /WEB-INF/server-config.wsdd 11:29:03,798 WARN [TomcatModuleBuilder] Web application does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. 11:29:04,119 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=Application_ID,J2EEServer=geronimo,j2eeType=WebModule,name=g2Client.war because no targets are running for reference J2EEApplication matching the patterns geronimo.server:J2EEServer=geronimo,j2eeType=J2EEApplication,name=Application_ID 11:29:04,129 INFO [StandardContext] Container org.apache.catalina.core.ContainerBase.[/g2Client] has not been started 11:29:04,129 ERROR [GBeanInstance] Problem in doFail of geronimo.server:J2EEApplication=Application_ID,J2EEServer=geronimo,j2eeType=WebModule,name=g2Client.war java.lang.NullPointerException at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:305) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$9f00ee94.removeContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:424) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:955) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:520) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.attemptFullStart(GBeanSingleReference.java:154) at org.apache.geronimo.gbean.runtime.GBeanSingleReference.targetAdded(GBeanSingleReference.java:127) at org.apache.geronimo.gbean.runtime.AbstractGBeanReference.addTarget(AbstractGBeanReference.java:242) at org.apache.geronimo.gbean.runtime.GBeanSingleReference$1.running(GBeanSingleReference.java:163) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:155) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:38) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:231) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:350) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at
[jira] Created: (GERONIMODEVTOOLS-64) Tolerate projects or EARs without Geronimo facet.
Tolerate projects or EARs without Geronimo facet. - Key: GERONIMODEVTOOLS-64 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-64 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: WTP M101 0207 and 0206 Geronimo plugins. If I add more then one EAR targetted to Geronimo runtime but do not add the Geronimo facet, then I get the error: !MESSAGE Configuration with id Application_IDalready exists. Existing configuration will be overwri tten with redeploy. Deployer operation failed: Could not parse application.xml org.apache.geronimo.common.DeploymentException: Could not parse application.xml at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:176 ) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.j ava:122) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$6abab4ad.getDeploym entPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) Doing the same with Web project works beacuse the configID is falling back on the context root which will be uniquiq for all web projects in the workbench. I think the same defaulting should happen for EAR and other J2EE projects (other than Web project) so that adding the Geronimo facet is not required but just nice to have. This is especially important for code that programmatically create projects and EARs so that they are not required to add the default facet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://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
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=comments#action_12365621 ] Anita Kulshreshtha commented on GERONIMO-1585: -- o.a.g.security.util.URLPattern.getQualifiedPattern(..) should reject */ from the qualified pattern as per JACC 3.1.3.1 Qualified URL Pattern Names. Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Components: web, security Versions: 1.0 Environment: Geronimo 1.0 with Jetty Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 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: http://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
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=comments#action_12365622 ] Anita Kulshreshtha commented on GERONIMO-1585: -- Please read that as /* Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Components: web, security Versions: 1.0 Environment: Geronimo 1.0 with Jetty Reporter: Aaron Mulder Priority: Critical Fix For: 1.0.1, 1.1 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: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMODEVTOOLS-64) Tolerate projects or EARs without Geronimo facet.
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-64?page=all ] Sachin Patel resolved GERONIMODEVTOOLS-64: -- Resolution: Won't Fix The facet will need to be created programatically. J2EE tooling is not making the dd's id's unique between projects. So if the geronimo facet is not created, then the Geronimo runtime uses the dd id's as its configID which will cause conflicts when deploying multiple projects that do not contain a geronimo specific deployment plan. Tolerate projects or EARs without Geronimo facet. - Key: GERONIMODEVTOOLS-64 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-64 Project: Geronimo-Devtools Type: Bug Environment: Windows XP Reporter: Kathy Chan Driver: WTP M101 0207 and 0206 Geronimo plugins. If I add more then one EAR targetted to Geronimo runtime but do not add the Geronimo facet, then I get the error: !MESSAGE Configuration with id Application_IDalready exists. Existing configuration will be overwri tten with redeploy. Deployer operation failed: Could not parse application.xml org.apache.geronimo.common.DeploymentException: Could not parse application.xml at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:176 ) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.j ava:122) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor. java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$6abab4ad.getDeploym entPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) Doing the same with Web project works beacuse the configID is falling back on the context root which will be uniquiq for all web projects in the workbench. I think the same defaulting should happen for EAR and other J2EE projects (other than Web project) so that adding the Geronimo facet is not required but just nice to have. This is especially important for code that programmatically create projects and EARs so that they are not required to add the default facet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in module javamail-transport
At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail- transport module dependent on our specific javamail implementation? -David On Feb 6, 2006, at 11:04 PM, Bruce Snyder wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo- javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
[jira] Commented: (GERONIMO-1585) Web app security on /* causes deployment exception
[
http://issues.apache.org/jira/browse/GERONIMO-1585?page=comments#action_12365630
]
Anita Kulshreshtha commented on GERONIMO-1585:
--
Aaron could you please add a line pat = / as shown here in
o.a.g.security.util.URLPattern and test if your app works.
public URLPattern(String pat) {
if (pat == null) t..
if (pat.length() == 0) ...
if (pat.equals(/) || pat.equals(/*)) {
type = DEFAULT;
pat = /; --
new line
. .}else
Web app security on /* causes deployment exception
--
Key: GERONIMO-1585
URL: http://issues.apache.org/jira/browse/GERONIMO-1585
Project: Geronimo
Type: Bug
Components: web, security
Versions: 1.0
Environment: Geronimo 1.0 with Jetty
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.0.1, 1.1
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1603) shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables
shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables --- Key: GERONIMO-1603 URL: http://issues.apache.org/jira/browse/GERONIMO-1603 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Fix For: 1.0.1, 1.1 The shutdown.bat does not set ERRORLEVEL and does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables that the other batch files support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1604) Output from deploy.sh/bat is inconsistent with other scripts - does not output info on environment variable settings (e.g. JAVA_HOME)
Output from deploy.sh/bat is inconsistent with other scripts - does not output info on environment variable settings (e.g. JAVA_HOME) - Key: GERONIMO-1604 URL: http://issues.apache.org/jira/browse/GERONIMO-1604 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Fix For: 1.0.1, 1.1 The other scripts/bat files output the following information prior to executing the command: Using GERONIMO_BASE: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/sissonj/test/geronimo-1.0.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/j2se I will fix the deploy.sh and deploy.bat scripts so that they operate the same. It is worthwhile outputting this information to aid daignosis, especially for first time users. For advanced users who don't want to see this information when they use Geronimo's scripts, they can set the new environment variable GERONIMO_ENV_INFO to off (the default being on). The geronimo.bat, geronimo.sh, deploy.bat and deploy.sh files will check this environment variable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=comments#action_12365635 ] Jeff Genender commented on GERONIMO-1480: - Ok, I think its fixed now...so please try again from HEAD. If it works, I will commit it to 1.0.1. Cross context include does not set jacc contextID for 2nd web app. (Tomcat only) Key: GERONIMO-1480 URL: http://issues.apache.org/jira/browse/GERONIMO-1480 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0.1, 1.1 Reporter: David Jencks Assignee: Jeff Genender Priority: Blocker Fix For: 1.1, 1.0.1 If you do a cross context include from web app A to web app B, the jacc contextID fetched from PolicyContext when you evaluate isUserInRole in web app B is the contextID for A, not B. Presumably the cross context dispatch does not go through the PolicyContextValve for B. Here's a thread trace that demonstrates this, with a couple annotations. [EMAIL PROTECTED] daemon prio=5, in group main, status: RUNNING implies():80, GeronimoPolicy.java implies():46, JaasPolicyCoordinator.java implies():189, ProtectionDomain.java checkPermission():254, AccessControlContext.java hasRole():248, TomcatGeronimoRealm.java isUserInRole():2128, Request.java isUserInRole():761, RequestFacade.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():265, PortletRequestImpl.java _jspService():46, roles.jsp service():97, HttpJspBase.java service():688, HttpServlet.java service():322, JspServletWrapper.java serviceJspFile():314, JspServlet.java service():264, JspServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java include():72, JetspeedRequestDispatcher.java doView():363, GenericServletPortlet.java doDispatch():250, GenericPortlet.java render():178, GenericPortlet.java render():102, JetspeedPortletInstance.java THIS IS WEB APP B doGet():230, JetspeedContainerServlet.java service():595, HttpServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java THIS IS A INCLUDING B invoke():213, ServletPortletInvoker.java render():125, ServletPortletInvoker.java renderPortlet():119, PortletContainerImpl.java renderPortlet():120, JetspeedPortletContainerWrapper.java execute():120, RenderingJobImpl.java renderNow():110, PortletRendererImpl.java aggregateAndRender():199, PageAggregatorImpl.java aggregateAndRender():182, PageAggregatorImpl.java build():106, PageAggregatorImpl.java invoke():48, AggregatorValve.java invokeNext():166, JetspeedPipeline.java invoke():132, ActionValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():76, ContainerValve.java invokeNext():166, JetspeedPipeline.java invoke():100, DecorationValve.java invokeNext():166, JetspeedPipeline.java invoke():179, ProfilerValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():143, LoginValidationValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():148, PasswordCredentialValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():168, LocalizationValveImpl.java invokeNext():166, JetspeedPipeline.java run():117, AbstractSecurityValve.java doPrivileged():-1, AccessController.java doAsPrivileged():437, Subject.java invoke():111, AbstractSecurityValve.java invokeNext():166, JetspeedPipeline.java invoke():55, PortalURLValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():128, CapabilityValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():145, JetspeedPipeline.java service():231, JetspeedEngine.java THIS IS WEB APP A: doGet():226, JetspeedServlet.java service():595, HttpServlet.java service():688, HttpServlet.java internalDoFilter():252,
[jira] Created: (GERONIMO-1605) Display PID of started process when using geronimo.sh start or startup.sh
Display PID of started process when using geronimo.sh start or startup.sh - Key: GERONIMO-1605 URL: http://issues.apache.org/jira/browse/GERONIMO-1605 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.1 Enchance geronimo.sh to display the PID of started process when Geronimo is started using geronimo.sh start or startup.sh. This is useful for developers who may have a number of Geronimo processes running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1606) Display message indicating Geronimo is being started in another window when started with geronimo.bat start or startup.bat
Display message indicating Geronimo is being started in another window when started with geronimo.bat start or startup.bat -- Key: GERONIMO-1606 URL: http://issues.apache.org/jira/browse/GERONIMO-1606 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.1 Display a message indicating Geronimo is being started in another window in case the user does not notice that geronimo was started in another window when started with geronimo.bat start or startup.bat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1607) Allow user to specify arguments to be specified on the Windows START command issued by geronimo.sh
Allow user to specify arguments to be specified on the Windows START command issued by geronimo.sh -- Key: GERONIMO-1607 URL: http://issues.apache.org/jira/browse/GERONIMO-1607 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.1 Allow arguments to the Windows START command to be specified in an environment variable GERONIMO_WIN_START_ARGS. The Windows START command is used if Geronimo is started the following ways: geronimo.bat start startup.bat For example, the GERONIMO_WIN_START_ARGS environment variable could be set to /MIN to start Geronimo in a minimized window. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1607) Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1607?page=all ] John Sisson updated GERONIMO-1607: -- Summary: Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat (was: Allow user to specify arguments to be specified on the Windows START command issued by geronimo.sh) Allow user to specify arguments to be used on the Windows START command issued by geronimo.bat -- Key: GERONIMO-1607 URL: http://issues.apache.org/jira/browse/GERONIMO-1607 Project: Geronimo Type: Improvement Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.1 Allow arguments to the Windows START command to be specified in an environment variable GERONIMO_WIN_START_ARGS. The Windows START command is used if Geronimo is started the following ways: geronimo.bat start startup.bat For example, the GERONIMO_WIN_START_ARGS environment variable could be set to /MIN to start Geronimo in a minimized window. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1608) Improve Geronimo script documentation
Improve Geronimo script documentation - Key: GERONIMO-1608 URL: http://issues.apache.org/jira/browse/GERONIMO-1608 Project: Geronimo Type: Improvement Components: startup/shutdown, usability Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.0.1, 1.1 * Describe relationship between geronimo.bat/sh ,startup.bat/sh and shutdown.bat/sh in the geronimo.bat/sh file * Make it clearer that users shouldn't have to edit script files just to set environment variables. They should be using the setenv.bat/sh files that are called by geronimo.bat/sh and deploy.bat/sh -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1609) Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat
Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat - Key: GERONIMO-1609 URL: http://issues.apache.org/jira/browse/GERONIMO-1609 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 * Fix typo in geronimo.bat where it echos a message that it cannot find setclasspath.bat. It should read setjavaenv.bat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1609) Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat
[ http://issues.apache.org/jira/browse/GERONIMO-1609?page=all ] John Sisson updated GERONIMO-1609: -- Summary: Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat (was: Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat) Fix typo in error message in geronimo.bat - cannot find ...setclasspath.bat should read cannot find ...setjavaenv.bat - Key: GERONIMO-1609 URL: http://issues.apache.org/jira/browse/GERONIMO-1609 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 * Fix typo in geronimo.bat where it echos a message that it cannot find setclasspath.bat. It should read setjavaenv.bat -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in module javamail-transport
David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail-transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail-transport module because the implementation of the MimeUtility class will also need the same converters. -David On Feb 6, 2006, at 11:04 PM, Bruce Snyder wrote: On 2/6/06, Jian Liao [EMAIL PROTECTED] wrote: Geronimo spec updated. you have to rebuild it. But you still can not make it right after rebuild geronimo-spec, so I just bypass this module in the top maven.xml. Jian is correct, the compilation errors are due to changes to the geronimo-spec-javamail module today. In order to avoid the compilation errors, you'll need to check out the whole specs trunk: https://svn.apache.org/repos/asf/geronimo/specs/trunk/ and at least build the geronimo-spec-javamail module using Maven 2 and the following command: mvn clean install This will place the updated javamail spec jar here: ~/.maven/repository/org.apache.geronimo.specs/jars/geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar which will then allow the javamail-transport module to be built correctly. HTH Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
[jira] Created: (GERONIMO-1610) deploy.bat does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables
deploy.bat does not honour GERONIMO_BATCH_ECHO and GERONIMO_BATCH_PAUSE environment variables - Key: GERONIMO-1610 URL: http://issues.apache.org/jira/browse/GERONIMO-1610 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1611) Apache Geronimo Web site update
Apache Geronimo Web site update --- Key: GERONIMO-1611 URL: http://issues.apache.org/jira/browse/GERONIMO-1611 Project: Geronimo Type: Improvement Components: website Reporter: Hernan Cunico Assigned to: Bruce Snyder I have updated the template of the current Apache Geronimo Web site to use the one proposed from EPIQ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1611) Apache Geronimo Web site update
[ http://issues.apache.org/jira/browse/GERONIMO-1611?page=all ] Hernan Cunico updated GERONIMO-1611: Attachment: sites_geronimo.06-02-08.zip Apache Geronimo Web site update --- Key: GERONIMO-1611 URL: http://issues.apache.org/jira/browse/GERONIMO-1611 Project: Geronimo Type: Improvement Components: website Reporter: Hernan Cunico Assignee: Bruce Snyder Attachments: sites_geronimo.06-02-08.zip I have updated the template of the current Apache Geronimo Web site to use the one proposed from EPIQ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1611) Apache Geronimo Web site update
[ http://issues.apache.org/jira/browse/GERONIMO-1611?page=comments#action_12365649 ] Hernan Cunico commented on GERONIMO-1611: - The attached file is not the final version and there is still a lot of work in progress. I will continue to put updates daily to this jira Apache Geronimo Web site update --- Key: GERONIMO-1611 URL: http://issues.apache.org/jira/browse/GERONIMO-1611 Project: Geronimo Type: Improvement Components: website Reporter: Hernan Cunico Assignee: Bruce Snyder Attachments: sites_geronimo.06-02-08.zip I have updated the template of the current Apache Geronimo Web site to use the one proposed from EPIQ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1612) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh
Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh --- Key: GERONIMO-1612 URL: http://issues.apache.org/jira/browse/GERONIMO-1612 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 This was accidentally carried over from the Tomcat code the script was based upon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1612) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1612?page=comments#action_12365659 ] Jeff Genender commented on GERONIMO-1612: - Are you absolutely sure you want to remove this? Should there not be an ability to add on to the endorsed dirs via the command line? Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh --- Key: GERONIMO-1612 URL: http://issues.apache.org/jira/browse/GERONIMO-1612 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 This was accidentally carried over from the Tomcat code the script was based upon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in module javamail-transport
On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail- transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail- transport module because the implementation of the MimeUtility class will also need the same converters. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. -David
Re: Maven 2 Repository for Geronimo
At the very least, I'd like the interface to be the same. Can you find and post the maven2 repository interface to this list? My feeling on this is if it works it works. I don't think we should turn on downloading by default anytime soon, but I think we should make it available as an options so people can begin to play with it. -dain On Feb 8, 2006, at 3:17 AM, Jason Dillon wrote: Okay... though I think it should be relatively simple... I had been chatting with some Atlassian developers about potentially using the maven2 repo for plugin discover/download for confluence and jira. From chatting with some maven2 peeps looks like it might be relatively simple to get something basic functional. I think it would be positive direction for Geronimo... as if it works, then G would be able to pull artifacts from multiple local and remote repositories. If I can get it to work, and objections to potentially including this? --jason On Feb 7, 2006, at 12:27 PM, Dain Sundstrom wrote: Cuz, I think that is will be too much work to get in and tested. We're trying to get this done in the next few days, so it is just easier to write one that can read the m2 layout. -dain On Feb 7, 2006, at 1:39 PM, Jason Dillon wrote: Why not reuse the Maven2 code to handle repository access/ aggregation/etc ? --jason On Feb 6, 2006, at 9:00 PM, Dain Sundstrom wrote: I have added a repository that can read a repo using the maven 2 layout. This required a few changes to the Repository interface, so please take a look at it. The code is the configId branch that David Jencks and I are working on for the quick 1.1 release (old 1.0.1). Specifically, Aaron can you take a look at this? It will impact the console code and I don't want to create a mess for you to deal with. http://svn.apache.org/viewcvs.cgi/geronimo/branches/configid/ modules/system/src/java/org/apache/geronimo/system/repository/ Maven2Repository.java Thanks, -dain
Re: Compilation errors in module javamail-transport
David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. [javac] import org.apache.geronimo.mail.util.Hex; [javac] import org.apache.geronimo.mail.util.Base64; [javac] import org.apache.geronimo.mail.util.XText Is this the case or are there other things that make our javamail-transport module dependent on our specific javamail implementation? I believe there are a few package-scope methods defined on some of the javax.mail.* classes that also introduce some dependencies (note that the Sun impl also appears to do that in some places). I placed those classes in the javamail jar rather than the javamail-transport module because the implementation of the MimeUtility class will also need the same converters. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. Rick -David
CORBA Incubation setup procedures
I think I need: SVN http://svn.apache.org/repos/asf/incubator/yoko Jira Mailing lists [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Regards, Alan
[jira] Commented: (GERONIMO-1612) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1612?page=comments#action_12365666 ] John Sisson commented on GERONIMO-1612: --- Pretty sure :-) This was removed for the following reasons: * It wasn't documented in the geronimo.sh script * It isn't implemented in the corresponding geronimo.bat script * You can set system properties on the command line by using the existing GERONIMO_OPTS and JAVA_OPTS environment variables. * JARs should be picked up if you place then in the geronimo\lib\endorsed directory (pointed to by the META-INF/MANIFEST.MF file in bin\server.jar) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh --- Key: GERONIMO-1612 URL: http://issues.apache.org/jira/browse/GERONIMO-1612 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 This was accidentally carried over from the Tomcat code the script was based upon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1612) Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh
[ http://issues.apache.org/jira/browse/GERONIMO-1612?page=comments#action_12365669 ] John Sisson commented on GERONIMO-1612: --- Spoke with Jeff on IRC and he said Ok...seems good to me...as long as its doable on the command line, I am cool with it So all should be fine. Remove -Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS from commands in geronimo.sh --- Key: GERONIMO-1612 URL: http://issues.apache.org/jira/browse/GERONIMO-1612 Project: Geronimo Type: Bug Components: startup/shutdown Versions: 1.0 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.0.1, 1.1 This was accidentally carried over from the Tomcat code the script was based upon. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Compilation errors in module javamail-transport
On Feb 8, 2006, at 4:26 PM, Rick McGuire wrote: David Blevins wrote: On Feb 8, 2006, at 2:35 PM, Rick McGuire wrote: David Blevins wrote: At first blush it looks like there are just three util classes that make the javamail-transport module dependent on our specific javamail implementation. Do you think it makes much sense to try and keep them separate? Or are they too coupled already to be worth it? It's kind of a PITA to have to have a tight (i.e. snapshot) dependency on a spec project. But obviously javamail is a mess and it may just be too hard. I'm starting to think it was a mistake to have javamail-transport be a separate jar file from the spec code. In the Sun case, all of the code is in a single jar, so you only need the javamail jar and the activation jar to use it. Because of our current split, we require 3 jars. It might make sense to move the transport/store code into the spec jar since they are so tightly coupled. If they are fundamentally one unit and completely tied together, it may make more sense to put them together. Course, I may not understand the implications of what I say :) I guess if the javamail-transport module is going to be where all the change occurs, then having it outside specs kind of handy -- provided the javamail module itself calms down and doesn't keep changing right along with it. Could go a couple ways. -David
Re: CORBA Incubation setup procedures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: I think I need: * SVN o http://svn.apache.org/repos/asf/incubator/yoko * Jira * Mailing lists o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] Hang on a moment. I see that Geronimo is cool with it, but I don't see any discussion of this proposal on [EMAIL PROTECTED] just the message saying that Geronimo wants to sponsor it. Before we start setting things up, I'd really like to call for some opinions about the proposal from *outside* the sponsoring TLP. Alan's message points out that the proposal is at http://wiki.apache.org/incubator/CorbaProposal Anyone on general@incubator.apache.org have any comments to make on the proposal? Even just 'yeah, looks good to me' ? Mine is that 22 seems a rather large number (!) of initial committers for a podling.. If nothing further comes from this message within a couple of days, let's go ahead. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ+qdxZrNPMCpn3XdAQKjrAP9GlZgvfc2GYDu8SsKYtPBCPzAL8rHLjOL UwhEDqZPlvtQC8jpWIkxOrsUiZw+p3YhMzRkNrR5odmyGcdEsZFy2epSz7EQhoMB z4jR/ABCgH5pOpxunPfW+apyCcqC6xmPdt5KKnRWQDOdNpr15BWZLATZKXEJaiyY lhRxBQH4WPs= =dfIM -END PGP SIGNATURE-
RE: [VOTE-RESULT] Yoko - A CORBA Server Sub-Project Proposal - PASSED
Alan, Please note that this is not a Geronimo sub-project. Incubator projects are just that: Incubator projects whose final destination will be determined at graduation. Amongst other issues, we want to be inviting and inclusive of whomever wants to participate, including other ASF projects. Pre-supposing that it is a sub-project of any particular TLP can be contrary to community building. Hmmm ... I think that we should work this into our docs. --- Noel
Re: [VOTE-RESULT] Yoko - A CORBA Server Sub-Project Proposal - PASSED
On 2/8/2006 5:50 PM, Noel J. Bergman wrote: Alan, Please note that this is not a Geronimo sub-project. Incubator projects are just that: Incubator projects whose final destination will be determined at graduation. Amongst other issues, we want to be inviting and inclusive of whomever wants to participate, including other ASF projects. Pre-supposing that it is a sub-project of any particular TLP can be contrary to community building. Cool. So Geronimo is merely the sponsoring PMC which will help it through the incubator? At graduation, the community will decide its final resting place? Hmmm ... I think that we should work this into our docs. Thanks. Regards, Alan
Re: CORBA Incubation setup procedures
On 2/8/2006 5:41 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: I think I need: * SVN o http://svn.apache.org/repos/asf/incubator/yoko * Jira * Mailing lists o [EMAIL PROTECTED] o [EMAIL PROTECTED] o [EMAIL PROTECTED] Hang on a moment. I see that Geronimo is cool with it, but I don't see any discussion of this proposal on general@incubator.apache.org.. just the message saying that Geronimo wants to sponsor it. Before we start setting things up, I'd really like to call for some opinions about the proposal from *outside* the sponsoring TLP. Alan's message points out that the proposal is at http://wiki.apache.org/incubator/CorbaProposal Anyone on general@incubator.apache.org have any comments to make on the proposal? Even just 'yeah, looks good to me' ? CRAP. CRAP. CRAP. CRAP. I could have sworn that I sent this to general@incubator.apache.org as well. Sorry, my bad! (Sorry Geir, I was wrong!) Mine is that 22 seems a rather large number (!) of initial committers for a podling.. A real CORBA server is as complicated as a J2EE server. If nothing further comes from this message within a couple of days, let's go ahead. Cool. Regards, Alan
[jira] Commented: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=comments#action_12365679 ] Jian Liao commented on GERONIMO-1480: - Sorry for the delay, although there are still two exceptions here, but isUserInRole() works. I think Exception_2is caused by Exception_1. I will also look into it. Thanks! Exception 1 ## java.lang.StringIndexOutOfBoundsException: String index out of range: -2 at java.lang.String.init(String.java:192) at org.apache.tomcat.util.buf.CharChunk.toStringInternal(CharChunk.java: 499) at org.apache.tomcat.util.buf.StringCache.toString(StringCache.java:325) at org.apache.tomcat.util.buf.CharChunk.toString(CharChunk.java:495) at org.apache.tomcat.util.http.mapper.Mapper.internalMapWrapper(Mapper.j ava:776) at org.apache.tomcat.util.http.mapper.Mapper.map(Mapper.java:531) at org.apache.geronimo.tomcat.listener.DispatchListener.getWrapperName(D ispatchListener.java:104) at org.apache.geronimo.tomcat.listener.DispatchListener.beforeDispatch(D ispatchListener.java:71) at org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(Di spatchListener.java:50) at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSu pport.java:295) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:668) at org.apache.catalina.core.ApplicationDispatcher.processRequest(Applica tionDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD ispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis patcher.java:301) at org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.j ava:693) at org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.jav a:660) at org.apache.jsp.index_jsp._jspService(org.apache.jsp.index_jsp:45) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper .java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3 14) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu bjectValve.java:46) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:432) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. invoke(GeronimoStandardContext.java:273) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero nimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: 541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java :868) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p rocessConnection(Http11BaseProtocol.java:663) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo int.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol lowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP ool.java:684) at java.lang.Thread.run(Thread.java:534) Exception 2 ## java.lang.NullPointerException at org.apache.geronimo.tomcat.listener.DispatchListener.getWrapperName(D ispatchListener.java:106) at org.apache.geronimo.tomcat.listener.DispatchListener.beforeDispatch(D ispatchListener.java:71) at org.apache.geronimo.tomcat.listener.DispatchListener.instanceEvent(Di spatchListener.java:50) at org.apache.catalina.util.InstanceSupport.fireInstanceEvent(InstanceSu pport.java:295) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp atcher.java:668) at
Re: [continuum] BUILD FAILURE: Geronimo
On 2/8/06, continuum [EMAIL PROTECTED] wrote: Online report : http://ci.gbuild.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/202 Build statistics: State: Failed Previous State: Failed Started at: Wed, 8 Feb 2006 14:00:56 -0800 Finished at: Wed, 8 Feb 2006 14:05:49 -0800 Total time: 4m 53s Build Trigger: Schedule Exit code: 70 Building machine hostname: stan.gbuild.org Operating system : Linux(unknown) Java version : 1.4.2_08(Sun Microsystems Inc.) Changes modules/tomcat/src/java/org/apache/geronimo/tomcat/listener/DispatchListener.java modules/tomcat/src/java/org/apache/geronimo/tomcat/interceptor/PolicyContextBeforeAfter.java modules/tomcat/src/java/org/apache/geronimo/tomcat/realm/TomcatGeronimoRealm.java Output: ... + | geronimo and geronimo-plugins Geronimo :: JavaMail Transport | Memory: 14M/24M + DEPRECATED: the default goal should be specified in the build section of project.xml instead of maven.xml build:end: build:start: multiproject:install-callback: [echo] Running jar:install for Geronimo :: JavaMail Transport java:prepare-filesystem: java:compile: depend closure=false srcdir=1.4 dump=false destdir=/home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/target/classes/depend [echo] Compiling to /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/target/classes [javac] Compiling 14 source files to /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/target/classes [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/CramMD5Authenticator.java:26: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/CramMD5Authenticator.java:27: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/DigestMD5Authenticator.java:29: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/DigestMD5Authenticator.java:30: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Hex; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/LoginAuthenticator.java:24: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/PlainAuthenticator.java:24: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/transport/smtp/SMTPTransport.java:52: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.Base64; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/transport/smtp/SMTPTransport.java:53: package org.apache.geronimo.mail.util does not exist [javac] import org.apache.geronimo.mail.util.XText; [javac] ^ [javac] /home/continuum/continuum-1.0.2/apps/continuum/work/1/modules/javamail-transport/src/java/org/apache/geronimo/javamail/authentication/CramMD5Authenticator.java:99: cannot resolve symbol [javac] symbol : variable Hex [javac] location: class org.apache.geronimo.javamail.authentication.CramMD5Authenticator [javac] String
[jira] Created: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size
Eliminate unncessary dependencies to reduce assemnbly footprint size Key: GERONIMO-1613 URL: http://issues.apache.org/jira/browse/GERONIMO-1613 Project: Geronimo Type: Improvement Components: general Versions: 1.1 Environment: all Reporter: Joe Bohn Fix For: 1.1 Clean up assembly project.xml and eliminate some unnecessary dependencies in various modules and configs. This will reduce the footprint size (with special attention to the minimal-tomcat-assembly. The patch contains the following: - clean up minimal-tomcat-server\project.xml to remove commented out sections - clean up web-jms-tomcat-server\project.xml to remove commented out sections - remove dependencies from config\j2ee_server on xstream, jaxr-api, and geronimo-derby - remove dependencies from config\j2ee_deployer on geronimo-client-builder - remove dependencies from module\tomcat on activecluster, wadi-core, and wadi-tomcat55 There are still more dependencies that should be removed but this is a start. These changes reduce the disk footprint of minimal-tomcat-server from 27 meg to about 21 meg. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1613) Eliminate unncessary dependencies to reduce assemnbly footprint size
[ http://issues.apache.org/jira/browse/GERONIMO-1613?page=all ] Joe Bohn updated GERONIMO-1613: --- Attachment: RemoveDeps.patch Patch created in win-XP from geronimo root directory. I verified that I could start all server configs, access the console, and deploy a web application with these changes. This isnt't the most extensive test ... so I hope that these changes don't cause any problems in other scenarios. Eliminate unncessary dependencies to reduce assemnbly footprint size Key: GERONIMO-1613 URL: http://issues.apache.org/jira/browse/GERONIMO-1613 Project: Geronimo Type: Improvement Components: general Versions: 1.1 Environment: all Reporter: Joe Bohn Fix For: 1.1 Attachments: RemoveDeps.patch Clean up assembly project.xml and eliminate some unnecessary dependencies in various modules and configs. This will reduce the footprint size (with special attention to the minimal-tomcat-assembly. The patch contains the following: - clean up minimal-tomcat-server\project.xml to remove commented out sections - clean up web-jms-tomcat-server\project.xml to remove commented out sections - remove dependencies from config\j2ee_server on xstream, jaxr-api, and geronimo-derby - remove dependencies from config\j2ee_deployer on geronimo-client-builder - remove dependencies from module\tomcat on activecluster, wadi-core, and wadi-tomcat55 There are still more dependencies that should be removed but this is a start. These changes reduce the disk footprint of minimal-tomcat-server from 27 meg to about 21 meg. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CORBA Incubation setup procedures
ALL incubator requests for infrastructure MUST be reflected in an appropriate status file under http://incubator.apache.org/projects/index.html before they are requested. There are no exceptions. Roy
[jira] Commented: (GERONIMO-1480) Cross context include does not set jacc contextID for 2nd web app. (Tomcat only)
[ http://issues.apache.org/jira/browse/GERONIMO-1480?page=comments#action_12365688 ] Jian Liao commented on GERONIMO-1480: - 1. My web application context is /jetspeed, length = 9. 2. The value of request.getAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR) is /portal, length = 7, so the MessageBytes instance (mb) created with dispatchPath has a length = 7, start = Offset = 0. 3. mapper.map(mb, mappingData); will try to substring mb to get rid of context name, so a StringIndexOutOfBoundsException occur. It seems that mb is expected to contains the context name, like /jetspeed/portal. Cross context include does not set jacc contextID for 2nd web app. (Tomcat only) Key: GERONIMO-1480 URL: http://issues.apache.org/jira/browse/GERONIMO-1480 Project: Geronimo Type: Bug Components: Tomcat Versions: 1.0.1, 1.1 Reporter: David Jencks Assignee: Jeff Genender Priority: Blocker Fix For: 1.1, 1.0.1 If you do a cross context include from web app A to web app B, the jacc contextID fetched from PolicyContext when you evaluate isUserInRole in web app B is the contextID for A, not B. Presumably the cross context dispatch does not go through the PolicyContextValve for B. Here's a thread trace that demonstrates this, with a couple annotations. [EMAIL PROTECTED] daemon prio=5, in group main, status: RUNNING implies():80, GeronimoPolicy.java implies():46, JaasPolicyCoordinator.java implies():189, ProtectionDomain.java checkPermission():254, AccessControlContext.java hasRole():248, TomcatGeronimoRealm.java isUserInRole():2128, Request.java isUserInRole():761, RequestFacade.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():163, HttpServletRequestWrapper.java isUserInRole():265, PortletRequestImpl.java _jspService():46, roles.jsp service():97, HttpJspBase.java service():688, HttpServlet.java service():322, JspServletWrapper.java serviceJspFile():314, JspServlet.java service():264, JspServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java include():72, JetspeedRequestDispatcher.java doView():363, GenericServletPortlet.java doDispatch():250, GenericPortlet.java render():178, GenericPortlet.java render():102, JetspeedPortletInstance.java THIS IS WEB APP B doGet():230, JetspeedContainerServlet.java service():595, HttpServlet.java service():688, HttpServlet.java internalDoFilter():252, ApplicationFilterChain.java doFilter():173, ApplicationFilterChain.java invoke():672, ApplicationDispatcher.java doInclude():574, ApplicationDispatcher.java include():499, ApplicationDispatcher.java THIS IS A INCLUDING B invoke():213, ServletPortletInvoker.java render():125, ServletPortletInvoker.java renderPortlet():119, PortletContainerImpl.java renderPortlet():120, JetspeedPortletContainerWrapper.java execute():120, RenderingJobImpl.java renderNow():110, PortletRendererImpl.java aggregateAndRender():199, PageAggregatorImpl.java aggregateAndRender():182, PageAggregatorImpl.java build():106, PageAggregatorImpl.java invoke():48, AggregatorValve.java invokeNext():166, JetspeedPipeline.java invoke():132, ActionValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():76, ContainerValve.java invokeNext():166, JetspeedPipeline.java invoke():100, DecorationValve.java invokeNext():166, JetspeedPipeline.java invoke():179, ProfilerValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():143, LoginValidationValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():148, PasswordCredentialValveImpl.java invokeNext():166, JetspeedPipeline.java invoke():168, LocalizationValveImpl.java invokeNext():166, JetspeedPipeline.java run():117, AbstractSecurityValve.java doPrivileged():-1, AccessController.java doAsPrivileged():437, Subject.java invoke():111, AbstractSecurityValve.java invokeNext():166, JetspeedPipeline.java invoke():55, PortalURLValveImpl.java invokeNext():166, JetspeedPipeline.java
gbuild: continuum for jdk 1.5 install -- help
We're going to need another continuum install for building the openejb 3 stuff and servicemix and anything else that wants to build under 1.5. Is there anyone out there with some bandwidth to do this? -David
[jira] Commented: (GERONIMO-1611) Apache Geronimo Web site update
[ http://issues.apache.org/jira/browse/GERONIMO-1611?page=comments#action_12365693 ] Bruce Snyder commented on GERONIMO-1611: Thank you so much for your work on the site! It's really coming along. I'm getting a bunch of conflicts when doing an svn update on the content in the .zip file. It would be extremely helpful if you could create a diff file against the latest SVN and attach it to this issue as well. The command to produce a diff file is as follows: svn diff site.diff This command performs a diff and directs the output to a file named site.diff that can be attached to this issue. Please let me know if you have any issues. Apache Geronimo Web site update --- Key: GERONIMO-1611 URL: http://issues.apache.org/jira/browse/GERONIMO-1611 Project: Geronimo Type: Improvement Components: website Reporter: Hernan Cunico Assignee: Bruce Snyder Attachments: sites_geronimo.06-02-08.zip I have updated the template of the current Apache Geronimo Web site to use the one proposed from EPIQ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Oracle XA RAR for G1.0?
Thanks! My DBA cleared this for me and now XA is working with 1 Oracle DS and 1 ActiveMQ CF. I still can not get the 2 Oracle datasources working together with XA though. Did anyone have a chance to peek at that URL I mailed describing a similar problem? The one that suggested that some Oracle XA flag needs to be set for loosly coupled branches? --jason -Original Message- From: lichtner [EMAIL PROTECTED] Date: Tue, 7 Feb 2006 22:24:38 To:dev@geronimo.apache.org Subject: Re: Oracle XA RAR for G1.0? Since you crashed so many times and then had to delete the log, which knows how to clean up the in-doubt transactions, you now have some transactions which are waiting to be committed or rolled back and are holding locks (as they should.) If you have a dba I would get him/her involved. To do it manually you have to do a select on DBA_2PC_PENDING http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14237/statviews_3002.htm#sthref1821 and then do ROLLBACK FORCE or COMMIT FORCE as shown here: http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14231/ds_txnman.htm#i1007905 If you do not privileges for the select, you can try to log in as sys with the default Oracle password: sqlplus sys/CHANGE_ON_INSTALL Sometimes they don't bother to change it. If you grant the JDBC user the ability to select on DBA_2PC_PENDING (or other appropriate view) then Geronimo (once the NPE is fixed) can settle these automatically for you. Guglielmo On Tue, 7 Feb 2006, Jason Dillon wrote: It finally dawned on my that my connection to ActiveMQ using: vm://localhost?asyncSend=true Was a bad idea. So I tired using these: * vm://localhost * tcp://localhost:61616 Both of which don't hang... but now were back to more Oracle exceptions: snip 18:24:47,683 WARN [JDBCExceptionReporter] SQL Error: 1591, SQLState: 72000 18:24:47,683 ERROR [JDBCExceptionReporter] ORA-01591: lock held by in-doubt distributed transaction 6.28.6034 18:24:47,684 WARN [JDBCExceptionReporter] SQL Error: 1591, SQLState: 72000 18:24:47,684 ERROR [JDBCExceptionReporter] ORA-01591: lock held by in-doubt distributed transaction 6.28.6034 18:24:47,686 WARN [JDBCExceptionReporter] SQL Error: 1591, SQLState: 72000 18:24:47,686 ERROR [JDBCExceptionReporter] ORA-01591: lock held by in-doubt distributed transaction 6.28.6034 18:24:47,686 WARN [JDBCExceptionReporter] SQL Error: 1591, SQLState: 72000 18:24:47,686 ERROR [JDBCExceptionReporter] ORA-01591: lock held by in-doubt distributed transaction 6.28.6034 18:24:47,687 ERROR [JDBCExceptionReporter] Could not execute JDBC batch update java.sql.BatchUpdateException: ORA-01591: lock held by in-doubt distributed transaction 6.28.6034 at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:498) at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:12368) at org.tranql.connector.jdbc.StatementHandle.executeBatch(StatementHandle.java:157) at net.sf.hibernate.impl.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:54) at net.sf.hibernate.impl.BatcherImpl.executeBatch(BatcherImpl.java:126) at net.sf.hibernate.impl.SessionImpl.executeAll(SessionImpl.java:2421) at net.sf.hibernate.impl.SessionImpl.execute(SessionImpl.java:2371) at net.sf.hibernate.impl.SessionImpl.flush(SessionImpl.java:2240) at org.springframework.orm.hibernate.HibernateTemplate$22.doInHibernate(HibernateTemplate.java:595) at org.springframework.orm.hibernate.HibernateTemplate.execute(HibernateTemplate.java:312) at org.springframework.orm.hibernate.HibernateTemplate.flush(HibernateTemplate.java:593) at com.solidusnetworks.paycore.util.hibernate.BaseDAOHibernate.save(BaseDAOHibernate.java:176) at com.solidusnetworks.ach.oltp.dao.impl.ECheckDAOHibernate.saveECheck(ECheckDAOHibernate.java:208) at com.solidusnetworks.paycore.ach.model.check.service.CheckUpdateServiceBean.addECheck(CheckUpdateServiceBean.java:117) at com.solidusnetworks.paycore.ach.model.check.service.CheckUpdateServiceBean$$FastClassByCGLIB$$70674c74.invoke(generated) at org.openejb.dispatch.AbstractMethodOperation.invoke(AbstractMethodOperation.java:90) at org.openejb.slsb.BusinessMethod.execute(BusinessMethod.java:67) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80) at
Re: More Oracle woes...
I will mail a concise and terse update tomorrow... Spent most of today trying to create some JMeter components to test this stuff. --jason -Original Message- From: Matt Hogstrom [EMAIL PROTECTED] Date: Tue, 07 Feb 2006 17:36:20 To:dev@geronimo.apache.org Subject: Re: More Oracle woes... Jason, I'm catching up with your thread. Can you post an update and I'll be back on this evening. Sorry for the pain :( Jason Dillon wrote: So, I was going to punt on the TranQL Oracle-specific connector and just try to bundled generic version with the Oracle driver. So I used the wizard to generate a plan, and installed it... but when I try to use it I get fluff like: snip 13:46:07,901 WARN [GeronimoConnectionEventListener] connectionErrorOccurred called with null java.sql.SQLException: Unsupported feature at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179) at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269) at oracle.jdbc.dbaccess.DBError.throwUnsupportedFeatureSqlException(DBError.java:690) at oracle.jdbc.OracleDatabaseMetaData.supportsGetGeneratedKeys(OracleDatabaseMetaData.java:3766) at org.tranql.connector.jdbc.DatabaseMetaDataHandle.supportsGetGeneratedKeys(DatabaseMetaDataHandle.java:1089) 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:324) at net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:80) at net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1155) at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:789) at org.springframework.orm.hibernate.LocalSessionFactoryBean.newSessionFactory(LocalSessionFactoryBean.java:535) ... /snip So, it looks like boolean supportsGetGeneratedKeys() is getting called, but for some reason boolean OracleDatabaseMetaData.supportsGetGeneratedKeys() throws an exception instead of just returning false. I get the same behavior with these: * oracle/ojdbc14/9.2.0.5/jar * oracle/classes12/9.2.0.5/jar But, seems like this guy is much happier: * oracle/classes12/10.1.0.2.0_g/jar * * * Anyways, I guess this is just useful for chronicling my pain with Oracle, hopefully I'll get this sorted soon and then we can document the magic so no one has to go through this again. :-( --jason
[jira] Updated: (GERONIMO-1500) Geronimo-Jetty startup fails after adding and removing an HTTPS Connector
[ http://issues.apache.org/jira/browse/GERONIMO-1500?page=all ] Vamsavardhana Reddy updated GERONIMO-1500: -- Fix Version: 1.0.1 1.1 Geronimo-Jetty startup fails after adding and removing an HTTPS Connector - Key: GERONIMO-1500 URL: http://issues.apache.org/jira/browse/GERONIMO-1500 Project: Geronimo Type: Bug Versions: 1.0 Environment: Geronimo-Jetty server, Win XP, SunJDK 1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: 1.0.1, 1.1 Geronimo startup fails after adding and removing an HTTPS Connector through Geronimo Console. Steps to recreate this problem: 1. Start the Geronimo-Jetty server (*** I used the zip distribution geronimo-jetty-j2ee-1.0-20051222.zip ***) 2. Add an HTTPS Connector using link provided in WebServers portlet in Geronimo Console. 3. Delete the HTTPS Connector created in step 2 using link provided in WebServers portlet in Geronimo Console. 4. Stop the Geronimo-Jetty server. 5. Start the Geronimo-Jetty server. At this step, the server startup fails. The following exception is logged to geronimo.log: 21:37:53,587 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.0/car,J2EEServer=geronimo,j2eeType=AttributeStore,name=AttributeManager java.lang.NullPointerException at org.apache.geronimo.system.configuration.GBeanOverride.init(GBeanOverride.java:128) at org.apache.geronimo.system.configuration.ConfigurationOverride.init(ConfigurationOverride.java:51) at org.apache.geronimo.system.configuration.ServerOverride.init(ServerOverride.java:41) at org.apache.geronimo.system.configuration.LocalAttributeManager.load(LocalAttributeManager.java:323) at org.apache.geronimo.system.configuration.LocalAttributeManager.doStart(LocalAttributeManager.java:419) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:286) at org.apache.geronimo.system.main.Daemon.init(Daemon.java:82) at org.apache.geronimo.system.main.Daemon.main(Daemon.java:404) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
