[jira] Commented: (GERONIMO-2402) Redeployment fails after third iteration.
[ http://issues.apache.org/jira/browse/GERONIMO-2402?page=comments#action_12456716 ] Rakesh Midha commented on GERONIMO-2402: You were right about (modules != null) ... is redundant. thanks for closing Vamsi > Redeployment fails after third iteration. > - > > Key: GERONIMO-2402 > URL: http://issues.apache.org/jira/browse/GERONIMO-2402 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1, 1.1.1 > Environment: JDK 1.4.2_08, Windows/XP Pro, Version 2002 SP/2 >Reporter: Fran Varin > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 1.1.2, 2.0-M1 > > Attachments: hotdeployupdate.patch > > > Here is a modified copy of the test case that reproduces the bug. In its > original state there were some screen shots included for clarity sake. > However, it is not possible to include those here. The applicaiton that was > used in concert with this test case was an extremely simply project that just > included one JSP. There was no "geronimo-web.xml" used in the project and it > was deployed in "exploded" form. > Step 1 - Launch Geronimo > ? For this test I used the 1.1.1-RC3 Version. > ? I am pointing to Java SE v1.4.2_08 > ? The standard startup.bat was used to start the server with no > modification. > ? The application does not contain a "Geronimo-web.xml" descriptor. > ? Below are all of the message on the console after the Geronimo started. > Note that the application was deployed > Booting Geronimo Kernel (in Java 1.4.1_02)... > Module 1/20 geronimo/rmi-naming/1.1.1-rc3/car started in .265s > Module 2/20 geronimo/j2ee-server/1.1.1-rc3/car started in .563s > Module 3/20 geronimo/j2ee-security/1.1.1-rc3/car started in .547s > Module 4/20 geronimo/axis/1.1.1-rc3/carstarted in .078s > Module 5/20 geronimo/openejb/1.1.1-rc3/car started in .313s > Module 6/20 geronimo/system-database/1.1.1-rc3/car started in 1.750s > Module 7/20 geronimo/activemq-broker/1.1.1-rc3/car started in 1.188s > Module 8/20 geronimo/activemq/1.1.1-rc3/carstarted in .390s > Module 9/20 geronimo/tomcat/1.1.1-rc3/car started in 2.015s > Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1-rc3/car started in .297s > Module 11/20 geronimo/j2ee-deployer/1.1.1-rc3/car started in .234s > Module 12/20 geronimo/openejb-deployer/1.1.1-rc3/carstarted in .266s > Module 13/20 geronimo/client-deployer/1.1.1-rc3/car started in .047s > Module 14/20 geronimo/axis-deployer/1.1.1-rc3/car started in .078s > Module 15/20 geronimo/sharedlib/1.1.1-rc3/car started in .016s > Module 16/20 geronimo/tomcat-deployer/1.1.1-rc3/car started in .093s > Module 17/20 geronimo/welcome-tomcat/1.1.1-rc3/car started in .266s > Module 18/20 geronimo/webconsole-tomcat/1.1.1-rc3/car started in 4.297s > Module 19/20 geronimo/remote-deploy-tomcat/1.1.1-rc3/carstarted in .234s > Module 20/20 geronimo/hot-deployer/1.1.1-rc3/carstarted in .343s > Startup completed in 16 seconds > Listening on Ports: > 1099 0.0.0.0 RMI Naming > 1527 0.0.0.0 Derby Connector > 4201 0.0.0.0 ActiveIO Connector EJB > 4242 0.0.0.0 Remote Login Listener > 8009 0.0.0.0 Tomcat Connector AJP > 8080 0.0.0.0 Tomcat Connector HTTP > 8443 0.0.0.0 Tomcat Connector HTTPS > 0.0.0.0 JMX Remoting Connector >61616 0.0.0.0 ActiveMQ Message Broker Connector > Started Application Modules: > EAR: geronimo/webconsole-tomcat/1.1.1-rc3/car > RAR: geronimo/activemq/1.1.1-rc3/car > WAR: geronimo/remote-deploy-tomcat/1.1.1-rc3/car > WAR: geronimo/welcome-tomcat/1.1.1-rc3/car > Web Applications: > http://RI150WS311:8080/ > http://RI150WS311:8080/console > http://RI150WS311:8080/console-standard > http://RI150WS311:8080/remote-deploy > Geronimo Application Server started > 11:15:15,111 INFO [Hot Deployer] Deploying Test.war > 11:15:15,423 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. > Deployed default/Test/1158074115142/war @ > http://RI150WS311:8080/Test > Examine the "deploy" directory. Note that it contains the application as > deployed. > Examine the "repository\default" directory. Note that it contains what I > refer to as the actually running deployed application. >
Re: svn commit: r482713 - in /geronimo/specs: branches/1_1/geronimo-spec-j2ee-connector/src/main/java/javax/resource/ branches/1_1/geronimo-spec-j2ee-connector/src/test/java/javax/resource/ trunk/gero
Kevan,
After your Simpler suggestion, I did a little investigation and made it even
Simpler :o) . Returning super.toString() in ResourceException.toString()
has the same effect as eliminating the method altogether. I guess the
problem is with the bad testcase and it resulted in introducing further
problems. I think we should remove both ResourceException.toString() and
ResourceExceptionTest.testToString() and this fix can go into all
specs\branches and trunk.
Vamsi
On 12/8/06, Kevan Miller <[EMAIL PROTECTED]> wrote:
Vamsi,
A few things --
First. Simpler, I think, to use the following as the toString
implementation:
public String toString() {
// unit tests revealed that the errorCode is not included
return super.toString();
}
I'm not sure what's going on in specs/branches/1_1. However, at
present your change in that branch would never be picked up. The j2ee
connector version number (1.1 ?) must not be right. Latest release
version is 1.0.1 and specs/trunk is building 1.1-SNAPSHOT...
Would be nice to fix this problem for 1.2 (I say this mostly out of
guilt, because I see I've been sitting on a patch to fix this problem
for a while...). This would require sorting out the version number...
Only fixing in trunk will be just fine...
--kevan
On Dec 5, 2006, at 12:10 PM, [EMAIL PROTECTED] wrote:
> Author: vamsic007
> Date: Tue Dec 5 09:10:35 2006
> New Revision: 482713
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=482713
> Log:
> GERONIMO-1519 ResourceException.toString() can return null
> o Fixes toString() to return non-null string
>
> Modified:
> geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> main/java/javax/resource/ResourceException.java
> geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> test/java/javax/resource/ResourceExceptionTest.java
> geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
> java/javax/resource/ResourceException.java
> geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/test/
> java/javax/resource/ResourceExceptionTest.java
>
> Modified: geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/
> src/main/java/javax/resource/ResourceException.java
> URL: http://svn.apache.org/viewvc/geronimo/specs/branches/1_1/
> geronimo-spec-j2ee-connector/src/main/java/javax/resource/
> ResourceException.java?view=diff&rev=482713&r1=482712&r2=482713
> ==
>
> --- geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> main/java/javax/resource/ResourceException.java (original)
> +++ geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> main/java/javax/resource/ResourceException.java Tue Dec 5 09:10:35
> 2006
> @@ -79,6 +79,8 @@
>
> public String toString() {
> // unit tests revealed that the errorCode is not included
> -return getMessage();
> +String className = getClass().getName();
> +String msg = getMessage();
> +return msg != null ? className + ": "+msg : className;
> }
> }
>
> Modified: geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/
> src/test/java/javax/resource/ResourceExceptionTest.java
> URL: http://svn.apache.org/viewvc/geronimo/specs/branches/1_1/
> geronimo-spec-j2ee-connector/src/test/java/javax/resource/
> ResourceExceptionTest.java?view=diff&rev=482713&r1=482712&r2=482713
> ==
>
> --- geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> test/java/javax/resource/ResourceExceptionTest.java (original)
> +++ geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
> test/java/javax/resource/ResourceExceptionTest.java Tue Dec 5
> 09:10:35 2006
> @@ -54,9 +54,9 @@
>
> public void testToString() {
> ResourceException exception = new ResourceException
> ("problem");
> -assertEquals("problem", exception.toString());
> +assertEquals(ResourceException.class.getName()+":
> "+"problem", exception.toString());
>
> ResourceException other = new ResourceException("other
> problem", "123");
> -assertEquals("other problem", other.toString());
> +assertEquals(ResourceException.class.getName()+": "+"other
> problem", other.toString());
> }
> }
>
> Modified: geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/
> main/java/javax/resource/ResourceException.java
> URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
> j2ee-connector_1.5_spec/src/main/java/javax/resource/
> ResourceException.java?view=diff&rev=482713&r1=482712&r2=482713
> ==
>
> --- geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
> java/javax/resource/ResourceException.java (original)
> +++ geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
> java/javax/resource/ResourceException.java Tue Dec 5 09:10:
[jira] Closed: (GERONIMO-2168) NPE when deploying RAR
[ http://issues.apache.org/jira/browse/GERONIMO-2168?page=all ]
Kevan Miller closed GERONIMO-2168.
--
Fix Version/s: 2.0-M1
(was: 1.2)
Resolution: Duplicate
Dup of GERONIMO-1519
Tim, thanks a bunch for the patch. Apologies for letting it sit for so long.
> NPE when deploying RAR
> --
>
> Key: GERONIMO-2168
> URL: http://issues.apache.org/jira/browse/GERONIMO-2168
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.1
> Environment: Solaris 9 (Sparc), Java 1.5.0_06 (also appears in
> 1.4.2_05)
>Reporter: Tim Howe
> Assigned To: Kevan Miller
>Priority: Critical
> Fix For: 2.0-M1
>
> Attachments: ResourceException.patch
>
>
> I've been using Geronimo 1.0, and now 1.1, as the app server for the
> development of a JCA connector for our proprietary EIS and generally
> been very happy with it.
> I've had no problem running servlets, deploying WARs, and the like.
> However, I've run into a problem deploying a RAR that I built. I view
> it as highly probably that there's a bug somewhere in my resource
> adapter, but it seems to be triggering a bug in Geronimo, which appears
> in both Java 1.4.2 and 1.5:
> {quote}
> {{23:52:38,091 ERROR [GBeanInstanceState] Error while starting; GBean is now
> in the FAILED state:
> abstractName="com.celebrityresorts/rcc/0/rar?J2EEApplication=null,JCAConnectionFactory=Celebrity%20Resorts%20RCC%20development%20instance,JCAResource=com.celebrityresorts/rcc/0/rar,ResourceAdapter=com.celebrityresorts/rcc/0/rar,ResourceAdapterModule=com.celebrityresorts/rcc/0/rar,j2eeType=JCAManagedConnectionFactory,name=Celebrity%20Resorts%20RCC%20development%20instance"
> java.lang.NullPointerException
> at java.io.PrintWriter.write(PrintWriter.java:401)
> at java.io.PrintWriter.print(PrintWriter.java:546)
> at java.io.PrintWriter.println(PrintWriter.java:683)
> at java.lang.Throwable.printStackTrace(Throwable.java:510)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.printException(GBeanInstance.java:1047)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:983)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
> at
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
> at
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)}}
> {quote}
> and so on. The only thing I can figure is that somehow the Exception
> getting thrown is null, but I can't see how, as it seems to stem from
> bq. {{throw new Exception("A reference has failed so construction can not
> complete");}}
> so I'm very confused. Of course it's also quite late for me and I may
> be reading the stack trace wrong.
--
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-2455) Upgrade to new MX4J service release
[ http://issues.apache.org/jira/browse/GERONIMO-2455?page=comments#action_12456701 ] Kevan Miller commented on GERONIMO-2455: Just checked the maven upload request that i submitted to get the new mx4j release uploaded to a maven repo. It got rejected for not being up to snuff. I'll have to look to see what's wrong... > Upgrade to new MX4J service release > --- > > Key: GERONIMO-2455 > URL: http://issues.apache.org/jira/browse/GERONIMO-2455 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1, 1.1, 1.0, 1.1.2, 1.2 >Reporter: Kevan Miller > Assigned To: Kevan Miller > Fix For: 1.1.2, 1.2 > > > There's a timing hole in the mx4j Monitor implementation. In some scenarios, > a Monitor will not receive an appropriate Notifcation after being started. > The fix for the problem has been committed to mx4j head. I've run tests using > a private build from mx4j head, all looks well. > Once available, we should upgrade to the mx4j service release 3.0.2. -- 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-1494) Potential infinite loop in ActiveMQ shutdown processing
[ http://issues.apache.org/jira/browse/GERONIMO-1494?page=all ] Kevan Miller closed GERONIMO-1494. -- Resolution: Duplicate No idea if this problem can still occur in AMQ 4. Pretty sure that an identical jira was raised in AMQ, anyway... > Potential infinite loop in ActiveMQ shutdown processing > --- > > Key: GERONIMO-1494 > URL: http://issues.apache.org/jira/browse/GERONIMO-1494 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 1.0 >Reporter: Kevan Miller > Assigned To: Kevan Miller >Priority: Minor > Fix For: 1.2 > > > The geronimo.log posted to http://issues.apache.org/jira/browse/GERONIMO-1372 > shows evidence of infinite loop in ActiveMQ shutdown processing. > The log entry from the 1372 log is excerpted below: > 17:30:34,325 WARN [TransportChannelSupport] Caught exception dispatching > message and no ExceptionListener registered: javax.jms.JMSException: > asyncSend failed: java.io.EOFException: Cannot write to the stream any more > it has already been closed > javax.jms.JMSException: asyncSend failed: java.io.EOFException: Cannot write > to the stream any more it has already been closed > at > org.activemq.util.JMSExceptionHelper.newJMSException(JMSExceptionHelper.java:49) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:483) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) > > at > org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.reconnect(ActiveMQAsfEndpointWorker.java:176) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.access$200(ActiveMQAsfEndpointWorker.java:40) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker$1$1.onException(ActiveMQAsfEndpointWorker.java:83) > > at > org.activemq.transport.TransportChannelSupport.onAsyncException(TransportChannelSupport.java:445) > > at > org.activemq.transport.tcp.TcpTransportChannel.doAsyncSend(TcpTransportChannel.java:484) > > at > org.activemq.transport.TransportChannelSupport.asyncSendWithReceipt(TransportChannelSupport.java:160) > > at > org.activemq.transport.TransportChannelSupport.send(TransportChannelSupport.java:145) > > at > org.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1377) > at > org.activemq.ActiveMQConnection.sendConnectionInfoToBroker(ActiveMQConnection.java:1617) > > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > ... (you get the picture) > at org.activemq.ActiveMQConnection.close(ActiveMQConnection.java:762) > at > org.activemq.ra.ActiveMQBaseEndpointWorker.safeClose(ActiveMQBaseEndpointWorker.java:78) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.disconnect(ActiveMQAsfEndpointWorker.java:164) > > at > org.activemq.ra.ActiveMQAsfEndpointWorker.stop(ActiveMQAsfEndpointWorker.java:139) > > at > org.activemq.ra.ActiveMQResourceAdapter.endpointDeactivation(ActiveMQResourceAdapter.java:261) > > at > org.apache.geronimo.connect
Re: svn commit: r482713 - in /geronimo/specs: branches/1_1/geronimo-spec-j2ee-connector/src/main/java/javax/resource/ branches/1_1/geronimo-spec-j2ee-connector/src/test/java/javax/resource/ trunk/gero
Vamsi,
A few things --
First. Simpler, I think, to use the following as the toString
implementation:
public String toString() {
// unit tests revealed that the errorCode is not included
return super.toString();
}
I'm not sure what's going on in specs/branches/1_1. However, at
present your change in that branch would never be picked up. The j2ee
connector version number (1.1 ?) must not be right. Latest release
version is 1.0.1 and specs/trunk is building 1.1-SNAPSHOT...
Would be nice to fix this problem for 1.2 (I say this mostly out of
guilt, because I see I've been sitting on a patch to fix this problem
for a while...). This would require sorting out the version number...
Only fixing in trunk will be just fine...
--kevan
On Dec 5, 2006, at 12:10 PM, [EMAIL PROTECTED] wrote:
Author: vamsic007
Date: Tue Dec 5 09:10:35 2006
New Revision: 482713
URL: http://svn.apache.org/viewvc?view=rev&rev=482713
Log:
GERONIMO-1519 ResourceException.toString() can return null
o Fixes toString() to return non-null string
Modified:
geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
main/java/javax/resource/ResourceException.java
geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
test/java/javax/resource/ResourceExceptionTest.java
geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
java/javax/resource/ResourceException.java
geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/test/
java/javax/resource/ResourceExceptionTest.java
Modified: geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/
src/main/java/javax/resource/ResourceException.java
URL: http://svn.apache.org/viewvc/geronimo/specs/branches/1_1/
geronimo-spec-j2ee-connector/src/main/java/javax/resource/
ResourceException.java?view=diff&rev=482713&r1=482712&r2=482713
==
--- geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
main/java/javax/resource/ResourceException.java (original)
+++ geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
main/java/javax/resource/ResourceException.java Tue Dec 5 09:10:35
2006
@@ -79,6 +79,8 @@
public String toString() {
// unit tests revealed that the errorCode is not included
-return getMessage();
+String className = getClass().getName();
+String msg = getMessage();
+return msg != null ? className + ": "+msg : className;
}
}
Modified: geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/
src/test/java/javax/resource/ResourceExceptionTest.java
URL: http://svn.apache.org/viewvc/geronimo/specs/branches/1_1/
geronimo-spec-j2ee-connector/src/test/java/javax/resource/
ResourceExceptionTest.java?view=diff&rev=482713&r1=482712&r2=482713
==
--- geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
test/java/javax/resource/ResourceExceptionTest.java (original)
+++ geronimo/specs/branches/1_1/geronimo-spec-j2ee-connector/src/
test/java/javax/resource/ResourceExceptionTest.java Tue Dec 5
09:10:35 2006
@@ -54,9 +54,9 @@
public void testToString() {
ResourceException exception = new ResourceException
("problem");
-assertEquals("problem", exception.toString());
+assertEquals(ResourceException.class.getName()+":
"+"problem", exception.toString());
ResourceException other = new ResourceException("other
problem", "123");
-assertEquals("other problem", other.toString());
+assertEquals(ResourceException.class.getName()+": "+"other
problem", other.toString());
}
}
Modified: geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/
main/java/javax/resource/ResourceException.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
j2ee-connector_1.5_spec/src/main/java/javax/resource/
ResourceException.java?view=diff&rev=482713&r1=482712&r2=482713
==
--- geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
java/javax/resource/ResourceException.java (original)
+++ geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/main/
java/javax/resource/ResourceException.java Tue Dec 5 09:10:35 2006
@@ -78,6 +78,8 @@
public String toString() {
// unit tests revealed that the errorCode is not included
-return getMessage();
+String className = getClass().getName();
+String msg = getMessage();
+return msg != null ? className + ": "+msg : className;
}
}
Modified: geronimo/specs/trunk/geronimo-j2ee-connector_1.5_spec/src/
test/java/javax/resource/ResourceExceptionTest.java
URL: http://svn.apache.org/viewvc/geronimo/specs/trunk/geronimo-
j2ee-connector_1.5_spec/src/test/java/javax/resource/
ResourceExceptionTest.java?view=diff&rev=482713&r1=482712&r2=482713
Convention on dropping tests under the test framework
Since there were some questions today on where to drop new tests, I'll take a stab at creating a convention. Feel free to offer your suggestions so that we can modify it as we go along. We began by having 2 testsuites just as an example. geronimo/testsuite/ console-testsuite deployment-testsuite But almost everything can fall under the category of the deployment-testsuite since most tests do need some deployable artifact. So I think we should use the deployment-testsuite purely for testing the deploy tool. Especially, it should be used to test features like hot-deploy, redeploy and undeploy which have had JIRAs before. We should categorize the tests so that they reflect the broad functional areas of the server. * web-testsuite (servlets, jsp, jstl) * enterprise-testsuite (ejb, jpa, jms, jacc, jta, javamail, jaf etc) * mgmt-testsuite (jee management, deployment) * webservices-testsuite (wsee, jaxb, stax, saaj, ws-metadata etc) * performance-testsuite (server startup time, server footprint etc) * security-testsuite * console-testsuite * regression (compatibility) If nobody has any objection to this top categorization, I shall go ahead and create these testsuites over the weekend. Meanwhile you may drop your tests in the existing testsuites for now. I shall move them appropriately. Lastly, how do we deal with super apps like daytrader that can span across multiple testsuites ? Cheers Prasad
[jira] Closed: (GERONIMO-2129) Allow user to specify the pool size for Stateless Session beans
[ http://issues.apache.org/jira/browse/GERONIMO-2129?page=all ] Matt Hogstrom closed GERONIMO-2129. --- Resolution: Fixed Committed to Open EJB > Allow user to specify the pool size for Stateless Session beans > --- > > Key: GERONIMO-2129 > URL: http://issues.apache.org/jira/browse/GERONIMO-2129 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > OpenEJB has code implemented to Pool Stateless session beans. This support > is currently hardcoded to a cache size of one which eliminates any > performance benefit of caching. A new attribute will be added to the OpenEJB > XSD that will allow the user to specify the pool size to be used for a > deployed stateless session bean. > The attribute will be and will take an integer value as its > argument. -- 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
Need patch review.. Builders to use DeployableModule Interface
I've attached a patch http://issues.apache.org/jira/browse/
GERONIMO-2638 that provides the changes from our builders use of
JarFile to a new interface DeployableModule. Since 1.2 is currently
less disruptive, I've created a patch that can be applied to 1.2 and
eventually I'll port it to trunk. I did the changes in a way so that
all the builders don't have to change at once and the migration can
be done incrementally. Thus the use of the "temporary" classes,
ModuleBuilder2, ConfigurationBuilder2, and their abstract impls. The
current patch only changes the EARConfigBuilder and the
WebModuleBuilders (minus WebServices). I want to go ahead and get
this out so I can get input prior to migrating the rest of the
builders. So please provide your comments, concerns, feedback.
In a nutshell, the basic flow behind this change is the following..
(1) A deployableModuleType (gbean) can be set now in the
DeploymentManager by the client (eclipse for example)
(2) Given the artifact to deploy, (previously a JarFile), a new
DeployableModule instance will be created through the
DeployableModuleFactory class, passing the the artifact, where its a
JarFile or in the eclipse case, an xml file describing the
application and where all of its resources, jars, classes reside.
(3) Now the builders will now be passed around this instance of
DeployableModule, rather then the JarFile and the builders will
process the artifact, when possible, using the DeployableModule
interface.
And basically thats it. This allows Geronimo to build the
configuration from any directory structure, and no longer has to
conform to a J2EE archive structure and the copy of a resource in an
IDE is the copy that is running. It is completley pluggable and you
can easily provide support for an IDE or even a Maven project structure.
The only thing I don't like is when you're dealing with a JarFile
(the primary case outside of an IDE). I'm creating a wrapper around
the Jar using the DeployableModule implementation JarDeployable. The
problem is that whenever you're processing the JarEntries, you can't
use the interface and have to call..
if(deployable.isArchive()) {
JarFile jar = deployable.getJarFile()
//process the jar
} else {
//use the interface
}
There are only a few cases where we're travesing through the entries
of a Jar, so I'm not sure if people think this is a big deal or a
huge annoyance having to deal with 2 cases.
Please review as it would be nice to get this into M1. If you have
any suggestions on how we can improve the interface, I would love to
hear your input as I just threw this interface together a while ago
and I'm sure we can improve on it.
Thanks.
-sachin
[jira] Updated: (GERONIMO-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile
[ http://issues.apache.org/jira/browse/GERONIMO-2638?page=all ] Sachin Patel updated GERONIMO-2638: --- Patch Info: [Patch Available] > Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of > JarFile > --- > > Key: GERONIMO-2638 > URL: http://issues.apache.org/jira/browse/GERONIMO-2638 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M1 >Reporter: Sachin Patel > Assigned To: Sachin Patel > Fix For: 2.0-M1 > > Attachments: GERONIMO-1526-v1.2.patch > > -- 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-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile
[ http://issues.apache.org/jira/browse/GERONIMO-2638?page=all ] Sachin Patel updated GERONIMO-2638: --- Issue Type: RTC (was: New Feature) > Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of > JarFile > --- > > Key: GERONIMO-2638 > URL: http://issues.apache.org/jira/browse/GERONIMO-2638 > Project: Geronimo > Issue Type: RTC > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M1 >Reporter: Sachin Patel > Assigned To: Sachin Patel > Fix For: 2.0-M1 > > Attachments: GERONIMO-1526-v1.2.patch > > -- 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-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile
[ http://issues.apache.org/jira/browse/GERONIMO-2638?page=all ] Sachin Patel updated GERONIMO-2638: --- Attachment: GERONIMO-1526-v1.2.patch Patch should be applied to 1.2 even though its intent is 2.0. > Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of > JarFile > --- > > Key: GERONIMO-2638 > URL: http://issues.apache.org/jira/browse/GERONIMO-2638 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0-M1 >Reporter: Sachin Patel > Assigned To: Sachin Patel > Fix For: 2.0-M1 > > Attachments: GERONIMO-1526-v1.2.patch > > -- 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-2638) Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile
Improve ModuleBuilder and ConfigurationBuilder interfaces to replace use of JarFile --- Key: GERONIMO-2638 URL: http://issues.apache.org/jira/browse/GERONIMO-2638 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: deployment Affects Versions: 2.0-M1 Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 2.0-M1 -- 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
Help building Geronimo 1.2?
Ran into the following while trying to build from the 1.2 branch today...
I'm a little new to this, so... any thoughts? I checked the target directory
and the XmlUtilTest class appears to be there.
[INFO]
[INFO] Building Geronimo :: Kernel
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/home/cjblythe/geronimo12/modules/geronimo-kernel/target/classes/META-INF
[INFO] Copying 2 files to
/home/cjblythe/geronimo12/modules/geronimo-kernel/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 176 source files to
/home/cjblythe/geronimo12/modules/geronimo-kernel/target/classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 30 source files to
/home/cjblythe/geronimo12/modules/geronimo-kernel/target/test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
/home/cjblythe/geronimo12/modules/geronimo-kernel/target/surefire-reports
Warning: -enableassertions not understood. Ignoring.
org.apache.maven.surefire.booter.SurefireExecutionException: while resolving
class: org.apache.geronimo.kernel.util.XmlUtilTest; nested exception is
java.lang.NoClassDefFoundError: while resolving class:
org.apache.geronimo.kernel.util.XmlUtilTest
java.lang.NoClassDefFoundError: while resolving class:
org.apache.geronimo.kernel.util.XmlUtilTest
at java.lang.VMClassLoader.resolveClass(java.lang.Class)
(/usr/lib/libgcj.so.5.0.0)
at java.lang.Class.initializeClass() (/usr/lib/libgcj.so.5.0.0)
at java.lang.Class.isAssignableFrom(java.lang.Class)
(/usr/lib/libgcj.so.5.0.0)
at org.apache.maven.surefire.junit.JUnitDirectoryTestSuite.createTestSet(
java.lang.Class, java.lang.ClassLoader) (Unknown Source)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(
java.lang.ClassLoader) (Unknown Source)
at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(
java.lang.Object[], java.lang.ClassLoader, java.lang.ClassLoader) (Unknown
Source)
at org.apache.maven.surefire.Surefire.run(java.util.List, java.util.List,
java.lang.ClassLoader, java.lang.ClassLoader) (Unknown Source)
at _Jv_CallAnyMethodA(java.lang.Object, java.lang.Class, _Jv_Method,
boolean, boolean, java.lang.Class[], jvalue, jvalue, boolean)
(/usr/lib/libgcj.so.5.0.0)
at _Jv_CallAnyMethodA(java.lang.Object, java.lang.Class, _Jv_Method,
boolean, java.lang.Class[], java.lang.Object[]) (/usr/lib/libgcj.so.5.0.0)
at java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[])
(/usr/lib/libgcj.so.5.0.0)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess()
(Unknown Source)
at org.apache.maven.surefire.booter.SurefireBooter.main(java.lang.String[])
(Unknown Source)
Caused by: java.lang.ClassNotFoundException:
javax.xml.parsers.DocumentBuilderFactory not found in
[file:/home/cjblythe/geronimo12/modules/geronimo-kernel/target/classes/,
file:/home/cjblythe/geronimo12/modules/geronimo-kernel/target/test-classes/,
file:/root/.m2/repository/stax/stax-api/1.0/stax-api-1.0.jar,
file:/root/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar,
file:/root/.m2/repository/xstream/xstream/1.1.3/xstream-1.1.3.jar,
file:/root/.m2/repository/org/apache/geronimo/specs/geronimo-qname_1.1_spec/1.0.1/geronimo-qname_1.1_spec-
1.0.1.jar, file:/root/.m2/repository/xmlbeans/xbean/2.0.0/xbean-2.0.0.jar,
file:/root/.m2/repository/commons-logging/commons-logging/1.0.4/commons-
logging-1.0.4.jar,
file:/home/cjblythe/geronimo12/testsupport/testsupport-common/target/testsupport-
common-1.2-SNAPSHOT.jar, file:/root/.m2/repository/xpp3/xpp3/1.1.3.3/xpp3-
1.1.3.3.jar, file:/root/.m2/repository/log4j/log4j/1.2.13/log4j-1.2.13.jar,
file:/root/.m2/repository/org/apache/geronimo/genesis/config/logging-config/1.1-SNAPSHOT/logging-
config-1.1-SNAPSHOT.jar,
file:/root/.m2/repository/cglib/cglib-nodep/2.1_3/cglib-nodep-2.1_3.jar,
file:/root/.m2/repository/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar]
at java.net.URLClassLoader.findClass(java.lang.String)
(/usr/lib/libgcj.so.5.0.0)
at java.lang.ClassLoader.loadClass(java.lang.String, boolean)
(/usr/lib/libgcj.so.5.0.0)
at _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader)
(/usr/lib/libgcj.so.5.0.0)
at _Jv_FindClassFromSignature(byte, java.lang.ClassLoader)
(/usr/lib/libgcj.so.5.0.0)
at _Jv_BytecodeVerifier.type.compatible(_Jv_BytecodeVerifier.type&,
_Jv_BytecodeVerifier) (/usr/lib/libgcj.so.5.0.0)
at _Jv_BytecodeVerifier.verify_instructions_0()
(/usr/lib/libgcj.so.5.0.0)
at _Jv_VerifyMethod(_Jv_InterpMethod) (/usr/lib/libgcj.so.5.0.0)
at _Jv_PrepareClass(java.lang.Class) (/usr/lib/libgcj.so.5.0.0)
at _Jv_WaitForState(java.
Re: [jira] Closed: (GERONIMO-1135) Keystore password in System.properties
David, I guess the better place for that would be in the documentation. Do we want to have redundant GBean definitions in configurations just to show how to use them? Or am I missing some point? Vamsi On 12/8/06, David Jencks <[EMAIL PROTECTED]> wrote: I kinda think we might want to keep the empty SystemProperties gbean to make it more obvious where to set them in config.xml. If we do this we should include an empty override in config.xml. What do others think? thanks david jencks On Dec 7, 2006, at 11:21 AM, Vamsavardhana Reddy (JIRA) wrote: > [ http://issues.apache.org/jira/browse/GERONIMO-1135?page=all ] > > Vamsavardhana Reddy closed GERONIMO-1135. > - > > Resolution: Fixed > > Removing the keystore related system properties did not seem to > break anything. Removed "SystemProperties" GBean definition > altogether from the plan since there are no properties to set. > > Fixed in rev 483612. > >> Keystore password in System.properties >> -- >> >> Key: GERONIMO-1135 >> URL: http://issues.apache.org/jira/browse/ >> GERONIMO-1135 >> Project: Geronimo >> Issue Type: Bug >> Security Level: public(Regular issues) >> Components: security >>Affects Versions: 1.0-M5 >>Reporter: Aaron Mulder >> Assigned To: Vamsavardhana Reddy >>Priority: Critical >> Fix For: 1.2, 2.0-M1 >> >> >> If you look at the System properties, the keystore and trust store >> passwords are in there. I'm not sure who puts them in there, but >> we need to find a way to stop that -- or else prevent applications >> from reading them? > > -- > 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: [jira] Closed: (GERONIMO-1135) Keystore password in System.properties
I kinda think we might want to keep the empty SystemProperties gbean to make it more obvious where to set them in config.xml. If we do this we should include an empty override in config.xml. What do others think? thanks david jencks On Dec 7, 2006, at 11:21 AM, Vamsavardhana Reddy (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-1135?page=all ] Vamsavardhana Reddy closed GERONIMO-1135. - Resolution: Fixed Removing the keystore related system properties did not seem to break anything. Removed "SystemProperties" GBean definition altogether from the plan since there are no properties to set. Fixed in rev 483612. Keystore password in System.properties -- Key: GERONIMO-1135 URL: http://issues.apache.org/jira/browse/ GERONIMO-1135 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Vamsavardhana Reddy Priority: Critical Fix For: 1.2, 2.0-M1 If you look at the System properties, the keystore and trust store passwords are in there. I'm not sure who puts them in there, but we need to find a way to stop that -- or else prevent applications from reading them? -- 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: [jira] Commented: (SM-751) Flow tracing with correlation id
On 12/7/06, Roger Menday <[EMAIL PROTECTED]> wrote: I get the impression that the servicemix-bpe component is not using the latest ode code - however, as it is today, this component *doesn't* seem to be sticking the correlationID, into exchanges it is making. This would be useful here too. I guess this will also be a problem with any non-servicemix components too :) ? servicemix-bpe also doesn't add the senderEndpoint as a property into the exchanges it makes. servicemix-bpe is based on a donation to the ODE project which is not maintained. You should try the ODE Service Engine provided by the ODE project itself. I'm currently looking at the audit component, and knowing the senderEndpoint is important to know the initiator of an exchange (?), or can I find this out some other way ... (?) correlationId and senderEndpoint seem generally useful things to ship around in MessageExchanges. Is this the sort of thing JBI should specify I wonder ... ? I do agree. Maybe this will be part of the 2.0 spec ... Roger ps. the SVN trunk doesn't seem to build the core module at the moment. > >> >> ? >> >> thanks, >> >> Roger >> > >> >> Flow tracing with correlation id >> >> >> >> >> >> Key: SM-751 >> >> URL: https://issues.apache.org/activemq/browse/SM-751 >> >> Project: ServiceMix >> >> Issue Type: Improvement >> >>Reporter: Gianfranco Boccalon >> >> Attachments: servicemix-components.zip >> >> >> >> >> >> Add the possibility to trace the flow of the messages inside a >> Service Assembly. >> >> For example, if we have a Service Assembly composed of three >> components, two binding components (call them BC1 and BC2) and a >> service engine (SE) organized in this sequence BC1->SE->BC2, we need >> to recognize that the output messages produced by the SE component >> are related to some messages provided by BC1. >> >> To do this, we need to add a "process correlation id" to the >> message exchanges and to modify the used components, to propagate >> this correlation id in all Message Exchanges sent. >> >> Enclosed there is the modified code for the following components: >> >> - HTTP binding component: here I added the code to generate the >> correlation Id and set it in the Message Exchange >> >> - Splitter >> >> - Router (the lightweight component) >> >> >> > >> > >> >> >> > > -- Cheers, Guillaume Nodet
[jira] Assigned: (GERONIMO-2377) deploying a new datasource with the same name does not indicate any problem in the console
[ http://issues.apache.org/jira/browse/GERONIMO-2377?page=all ] Dain Sundstrom reassigned GERONIMO-2377: Assignee: Dain Sundstrom (was: Bill Dudney) > deploying a new datasource with the same name does not indicate any problem > in the console > -- > > Key: GERONIMO-2377 > URL: http://issues.apache.org/jira/browse/GERONIMO-2377 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2 >Reporter: Bill Dudney > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2377.bdudney.patch > > > Console acts as if it deployeed the datasource but the console spits out an > error message; > Deployer operation failed: Module console.dbpool/DefaultDS/1.0/rar already > exists in the server. Try to undeploy it first or use the redeploy command. > org.apache.geronimo.common.DeploymentException: Module > console.dbpool/DefaultDS/1.0/rar already exists in the server. Try to > undeploy it first or use the redeploy command. > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:855) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) > at > org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) > at > org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) > at java.lang.Thread.run(Thread.java:552) -- 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-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=all ] Dain Sundstrom closed GERONIMO-2169. Resolution: Invalid 1.2 doesn't use maven 1 anymore > Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding > tagged version of OpenEJB (not a branch) > --- > > Key: GERONIMO-2169 > URL: http://issues.apache.org/jira/browse/GERONIMO-2169 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1, 1.1.2 >Reporter: Kevan Miller > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of > OpenEJB. It should be checking out tags/v2_1. > We need to fix in Geronimo 1.1.1. The release process should be updated to > insure we don't repeat this mistake in the future. -- 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: 1.2 Beta Tasks
On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We have a few remaining SNAPSHOTS dependencies in the tree [2]. OpenEJB and Yoko are still being worked on for this release so a SNAPSHOT dependency is fine. ActiveIO and OpenJPA have released versions for the code we are using and I will work to replace this today. Done. We only have SNAPSHOT dependencies on Yoko, a few Geronimo specs, TranQL and OpenEJB. -dain
[jira] Closed: (GERONIMO-2522) Hot deployer makes app hangs
[ http://issues.apache.org/jira/browse/GERONIMO-2522?page=all ] Vamsavardhana Reddy closed GERONIMO-2522. - Fix Version/s: 1.1.2 1.2 2.0-M1 Resolution: Fixed Fixed by GERONIMO-2548 and GERONIMO-2402 together. Thanks Rakesh for providing the patches. > Hot deployer makes app hangs > > > Key: GERONIMO-2522 > URL: http://issues.apache.org/jira/browse/GERONIMO-2522 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 1.1.1 > Environment: Linux 2.6.15-1.2054_FC5smp > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) > Using JAVA_OPTS > -J-server -XX:NewSize=250M -XX:MaxNewSize=250M -Xms1000M -Xmx1000M > -Djava.awt.headless=true > Pentium IV 3.0 HT, 2GB mem >Reporter: Dario Andrade > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.1.2, 1.2, 2.0-M1 > > > When modifying a jsp file in GERONIMO_BASE/deploy/root/, a > redeployment occurs. > After that, no more requests are processed, hanging for an indefinite period > of time (waited for more than 2 minutes). > After shutting down geronimo, removing GERONIMO_BASE/repository/default/*, > commenting out config.xml module and finally starting up the AS, evertyhing > works fine. > I had to --inPlace deploy and set > load="false" to the hot-deployer.car module in config.xml, in order to avoid > future problems. -- 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-2402) Redeployment fails after third iteration.
[ http://issues.apache.org/jira/browse/GERONIMO-2402?page=all ] Vamsavardhana Reddy closed GERONIMO-2402. - Fix Version/s: 1.1.2 Resolution: Fixed Verified the fix works in branches\1.1, branches\1.2 and trunk. Thanks Rakesh. Fixed in rev 483713. > Redeployment fails after third iteration. > - > > Key: GERONIMO-2402 > URL: http://issues.apache.org/jira/browse/GERONIMO-2402 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1, 1.1.1 > Environment: JDK 1.4.2_08, Windows/XP Pro, Version 2002 SP/2 >Reporter: Fran Varin > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.1.2, 1.2, 2.0-M1 > > Attachments: hotdeployupdate.patch > > > Here is a modified copy of the test case that reproduces the bug. In its > original state there were some screen shots included for clarity sake. > However, it is not possible to include those here. The applicaiton that was > used in concert with this test case was an extremely simply project that just > included one JSP. There was no "geronimo-web.xml" used in the project and it > was deployed in "exploded" form. > Step 1 - Launch Geronimo > ? For this test I used the 1.1.1-RC3 Version. > ? I am pointing to Java SE v1.4.2_08 > ? The standard startup.bat was used to start the server with no > modification. > ? The application does not contain a "Geronimo-web.xml" descriptor. > ? Below are all of the message on the console after the Geronimo started. > Note that the application was deployed > Booting Geronimo Kernel (in Java 1.4.1_02)... > Module 1/20 geronimo/rmi-naming/1.1.1-rc3/car started in .265s > Module 2/20 geronimo/j2ee-server/1.1.1-rc3/car started in .563s > Module 3/20 geronimo/j2ee-security/1.1.1-rc3/car started in .547s > Module 4/20 geronimo/axis/1.1.1-rc3/carstarted in .078s > Module 5/20 geronimo/openejb/1.1.1-rc3/car started in .313s > Module 6/20 geronimo/system-database/1.1.1-rc3/car started in 1.750s > Module 7/20 geronimo/activemq-broker/1.1.1-rc3/car started in 1.188s > Module 8/20 geronimo/activemq/1.1.1-rc3/carstarted in .390s > Module 9/20 geronimo/tomcat/1.1.1-rc3/car started in 2.015s > Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1-rc3/car started in .297s > Module 11/20 geronimo/j2ee-deployer/1.1.1-rc3/car started in .234s > Module 12/20 geronimo/openejb-deployer/1.1.1-rc3/carstarted in .266s > Module 13/20 geronimo/client-deployer/1.1.1-rc3/car started in .047s > Module 14/20 geronimo/axis-deployer/1.1.1-rc3/car started in .078s > Module 15/20 geronimo/sharedlib/1.1.1-rc3/car started in .016s > Module 16/20 geronimo/tomcat-deployer/1.1.1-rc3/car started in .093s > Module 17/20 geronimo/welcome-tomcat/1.1.1-rc3/car started in .266s > Module 18/20 geronimo/webconsole-tomcat/1.1.1-rc3/car started in 4.297s > Module 19/20 geronimo/remote-deploy-tomcat/1.1.1-rc3/carstarted in .234s > Module 20/20 geronimo/hot-deployer/1.1.1-rc3/carstarted in .343s > Startup completed in 16 seconds > Listening on Ports: > 1099 0.0.0.0 RMI Naming > 1527 0.0.0.0 Derby Connector > 4201 0.0.0.0 ActiveIO Connector EJB > 4242 0.0.0.0 Remote Login Listener > 8009 0.0.0.0 Tomcat Connector AJP > 8080 0.0.0.0 Tomcat Connector HTTP > 8443 0.0.0.0 Tomcat Connector HTTPS > 0.0.0.0 JMX Remoting Connector >61616 0.0.0.0 ActiveMQ Message Broker Connector > Started Application Modules: > EAR: geronimo/webconsole-tomcat/1.1.1-rc3/car > RAR: geronimo/activemq/1.1.1-rc3/car > WAR: geronimo/remote-deploy-tomcat/1.1.1-rc3/car > WAR: geronimo/welcome-tomcat/1.1.1-rc3/car > Web Applications: > http://RI150WS311:8080/ > http://RI150WS311:8080/console > http://RI150WS311:8080/console-standard > http://RI150WS311:8080/remote-deploy > Geronimo Application Server started > 11:15:15,111 INFO [Hot Deployer] Deploying Test.war > 11:15:15,423 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. > Deployed default/Test/1158074115142/war @ > http://RI150WS311:8080/Test > Examine the "deploy" directory. Note that it contains the application as > deployed. > Examine the "repository\default" directory. Note that it contains what I > refer to as the actual
[jira] Closed: (GERONIMO-2439) add secure transport support to POP3 (i.e., SSL)
[ http://issues.apache.org/jira/browse/GERONIMO-2439?page=all ] Rick McGuire closed GERONIMO-2439. -- Resolution: Fixed Committed revision 483693. Thanks for the contribution Jason! > add secure transport support to POP3 (i.e., SSL) > > > Key: GERONIMO-2439 > URL: http://issues.apache.org/jira/browse/GERONIMO-2439 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Jason Warner > Assigned To: Rick McGuire >Priority: Minor > Attachments: POP3SSLConnection.patch, POP3SSLConnection.patch > > > SSL authentication added to POP3 -- 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-2637) Remove Peer transport setup from JMS portlet in 1.2
Remove Peer transport setup from JMS portlet in 1.2 --- Key: GERONIMO-2637 URL: http://issues.apache.org/jira/browse/GERONIMO-2637 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: console Reporter: Dain Sundstrom Assigned To: Paul McMahan Fix For: 1.2 The Peer transport doesn't work in 1.2 so the portlet option to configure it should be removed. -- 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-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] Dain Sundstrom updated GERONIMO-1786: - Fix Version/s: (was: 1.2) Assignee: (was: Dain Sundstrom) After the upgrade to ActiveIO 3.0 the same problem exists. On inspection of the code the Peer transport doesn't support this operation. The GUI for this feature will be removed from 1.2. > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.2, 1.1, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Fix For: 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at
[jira] Updated: (GERONIMO-2551) Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR artifact maven-metadata doesn't exist
[ http://issues.apache.org/jira/browse/GERONIMO-2551?page=all ] Dain Sundstrom updated GERONIMO-2551: - Assignee: Paul McMahan (was: Dain Sundstrom) > Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR > artifact maven-metadata doesn't exist > > > Key: GERONIMO-2551 > URL: http://issues.apache.org/jira/browse/GERONIMO-2551 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.1.1, 1.1.x, 1.2 >Reporter: Donald Woods > Assigned To: Paul McMahan > Fix For: 1.2, 2.0 > > Attachments: G2551-1.1.1.patch > > > 1) If an artifact version listed in a repos maven-metadata.xml doesn't exist, > then the PluginInstallerGBean code takes a NPE. > 2) If a maven-metadat.xml doesn't exist for a dependent JAR file artifact the > selected repo, then the PluginInstallerGBean code takes a NPE. -- 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-2584) Hot deploy module/server restart, throws IllegalArgumentException if application deployed using hotdeployment
[ http://issues.apache.org/jira/browse/GERONIMO-2584?page=all ] Vamsavardhana Reddy closed GERONIMO-2584. - Fix Version/s: 1.1.2 2.0-M1 (was: 2.0) Resolution: Fixed Verified the patch on branches\1.1, branches\1.2 and trunk. Fixed in rev 483678. > Hot deploy module/server restart, throws IllegalArgumentException if > application deployed using hotdeployment > - > > Key: GERONIMO-2584 > URL: http://issues.apache.org/jira/browse/GERONIMO-2584 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 1.2 > Environment: Windows XP, but should be valid for all platforms >Reporter: Rakesh Midha > Assigned To: Vamsavardhana Reddy > Fix For: 1.1.2, 1.2, 2.0-M1 > > Attachments: hotdepoystartup.patch > > > This is a problem similar to one reported in > https://issues.apache.org/jira/browse/GERONIMO-2402, the server restart or > hot-deploy module restart fails with followng error if in a previous run you > deployed an application using hot deployment. > The exception trace is : > 00:54:43,008 ERROR [DirectoryMonitor] Unable to scan file > C:\geronimo\geronimobu > ild\geronimo-tomcat-j2ee-1.2-SNAPSHOT\deploy\sampleHello during initialization > java.lang.IllegalArgumentException: Invalid id: sampleHello > at > org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:4 > 9) > at > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment > Time(DirectoryHotDeployer.java:216) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct > oryMonitor.java:233) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni > tor.java:206) > at java.lang.Thread.run(Thread.java:534) > 00:54:47,014 INFO [DirectoryHotDeployer] Deploying sampleHello > 00:54:51,350 WARN [TomcatModuleBuilder] Web application . does not contain a > WE > B-INF/geronimo-web.xml deployment plan. This may or may not be a problem, > depen > ding on whether you have things like resource references that need to be > resolve > d. You can also give the deployer a separate deployment plan file on the > comman > d line. > 00:54:51,841 ERROR [GBeanInstance] Problem in doFail of > default/sampleHello/1163 > 964291070/war?J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 > 163964291070/war > java.lang.RuntimeException: java.lang.NullPointerException > at > org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContai > ner.java:339) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b07 > 3.invoke() > ... 31 more > 00:54:51,841 ERROR [GBeanInstanceState] Error while starting; GBean is now in > th > e FAILED state: > abstractName="default/sampleHello/1163964291070/war?J2EEApplicat > ion=null,j2eeType=WebModule,name=default/sampleHello/1163964291070/war" > java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is > not > unique > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase > .java:749) > Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: > Configuratio > n default/sampleHello/1163964291070/war failed to start due to the following > rea > sons: > The service > J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 > 163964291070/war did not start because the doStart method threw an exception. > java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is > not > unique > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase > .java:749) > Steps to recreate: > 1. Start server > 2. Deploy sample application, by placing sampleApp folder in deploy directory > 3. Application will be deployed and runs fine. > 4. Restart server, or restart hot-deploy module > 5. The above mentioned exception is thrown. -- 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: 1.2 Beta Tasks
On Dec 7, 2006, at 1:32 PM, Dain Sundstrom wrote: We only have a few remaining optional and required tasks before we can cut the 1.2 beta :D TASK: Review YOUR JIRAs --- We have 60 JIRAs assigned to 1.2. Please review the issues assigned to you, and if you do not plan on fixing them in the next say 7 days move out of 1.2. Those with JIRAs remaining [1] at the end of the release will be shamed :) I'll have a look at my Jira's. Other Tasks --- Normally legal is the biggest problem, and Kevan has done a wonderful in this area. FWIU, the only remaining legal issue is the presence Sun schemas and dtds in the servlet and jsp spec jars, and Kevan is working to find out if they are a real problem. Any thing else I missed Kevan? Tomcat distributions contain the same xsd's/dtd's that our specs contain. I've sent a note to [EMAIL PROTECTED] concerning their rights to redistribute the files. Initial response was that their use is covered by original donation of Tomcat by Sun to the ASF. I don't have access to the Foundation documents that describe the donation. So, I have no way of verifying this... Tomcat has placed an ASF license header on these schemas. But they also contain the Sun copyright and license restrictions. If I don't hear back from the Tomcat crowd, soon. I guess I'll follow up on legal-discuss. We have a few remaining SNAPSHOTS dependencies in the tree [2]. OpenEJB and Yoko are still being worked on for this release so a SNAPSHOT dependency is fine. ActiveIO and OpenJPA have released versions for the code we are using and I will work to replace this today. Matt promised me a release of TranQL for this release, and I am hoping to get this today. Since OpenEJB has never been through the incubator process, I'm not so sure about shipping a snapshot. I don't think incubator would be too happy about that. I have some updates to openejb (to help get it ready for a release) which I hope to commit soon. I've sent a note to [EMAIL PROTECTED] about getting openejb release ready... Hmm. I see that Yoko's M1 release vote is still running --kevan
Re: How to build devtools/eclipse-plugin?
I think I'm gonna have to update this project's poms... repos need to be updated, rsync-repositories need to be removed, disto config needs to be normalized, etc. What is needed from the legacy repos? Using legacy repos tends to confuse m2 and generally I would recommend avoiding it where possible. What is in maven1-sppatel? I'm also a bit confused by the way that have been setup. For example, there is modules/eclipse-support, though there is no modules/pom.xml as I would have expected. Same with maven-plugins. Any reason for this? Anyways, this is not building for me now with a bunch of missing artifacts, though my guess is that some of that is due to network issues possibly due to the use of the apache rsync repos as mvn repos (which is not what they are for). [INFO] Failed to resolve artifact. Missing: -- 1) org.eclipse.plugins:org.eclipse.jst.j2ee.web:jar:1.1.2.v200610182223 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jst.j2ee.web \ -Dversion=1.1.2.v200610182223 -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.jst.j2ee.web:jar: 1.1.2.v200610182223 2) org.eclipse.plugins:org.eclipse.wst.common.project.facet.core:jar: 1.0.1.v200605040144 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.wst.common.project.facet.core \ -Dversion=1.0.1.v200605040144 -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.wst.common.project.facet.core:jar: 1.0.1.v200605040144 3) org.eclipse.plugins:org.eclipse.jst.server.core:jar: 1.0.1.v200605040115 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jst.server.core \ -Dversion=1.0.1.v200605040115 -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.jst.server.core:jar: 1.0.1.v200605040115 4) org.eclipse.plugins:org.eclipse.emf.ecore:jar:2.2.0.v200609210005 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.emf.ecore \ -Dversion=2.2.0.v200609210005 -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.emf.ecore:jar:2.2.0.v200609210005 5) org.eclipse.plugins:org.eclipse.jem.util:jar:1.2.1.v20060918_M Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jem.util \ -Dversion=1.2.1.v20060918_M -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.jem.util:jar:1.2.1.v20060918_M 6) org.eclipse.plugins:org.eclipse.jst.j2ee.jca:jar:1.1.2.v200610182223 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jst.j2ee.jca \ -Dversion=1.1.2.v200610182223 -Dpackaging=jar -Dfile=/path/ to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.jst.j2ee.jca:jar: 1.1.2.v200610182223 7) org.eclipse.plugins:org.eclipse.jdt.core:jar:3.2.1.r321_v20060823 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jdt.core \ -Dversion=3.2.1.r321_v20060823 -Dpackaging=jar -Dfile=/ path/to/file Path to dependency: 1) org.apache.geronimo.devtools:org.apache.geronimo.st.core:jar: 1.1.0 2) org.eclipse.plugins:org.eclipse.jdt.core:jar:3.2.1.r321_v20060823 8) org.eclipse.plugins:org.eclipse.jst.common.project.facet.core:jar: 1.0.1.v200605040115 Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.eclipse.plugins - DartifactId=org.eclipse.jst.common.project.facet.core \ -Dversion=1.0.1.v200605040115 -Dpackaging=jar -Dfile=/path/ to/f
Re: CMP failures in 2.3 (was: Openjeb itests - 552 tests, 2 failures, 2 errors)
Thanks for confirming that it does not break other tests. I will debug the two other failures other the week-end. Thanks, Gianny On 08/12/2006, at 5:20 AM, Prasad Kashyap wrote: I dropped the key-generator element from the BasicCmpBeanExplicitPK cmp entity and that fixed the 2 failures. Please apply the patch in - https://issues.apache.org/jira/browse/OPENEJB-402 We are now down to just 2 errors ! Thanx Prasad On 12/7/06, Gianny Damour <[EMAIL PROTECTED]> wrote: > CMRMappingTests.testOneToManyDoNotSetCMR Time elapsed: 0.26 sec > <<< ERROR! > org.apache.openejb.test.TestFailureException: null; nested > exception is: > junit.framework.AssertionFailedError: Received Exception class > javax.transaction.RollbackException : Unable to commit: transaction > marked for rollback > at > org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean.t e > stOneToManyDoNotSetCMR(CMRMappingFacadeBean.java:245) > at > org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean$ > $FastClassByCGLIB$$9687c6d6.invoke() > at org.apache.openejb.dispatch.AbstractMethodOperation.invoke > (AbstractMethodOperation.java:58) > at org.apache.openejb.slsb.BusinessMethod.execute > (BusinessMethod.java:36) > > CMRMappingTests.testOneToOneDoNotSetCMR Time elapsed: 0.06 sec > <<< ERROR! > org.apache.openejb.test.TestFailureException: null; nested > exception is: > junit.framework.AssertionFailedError: Received Exception class > javax.transaction.RollbackException : Unable to commit: transaction > marked for rollback > at > org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean.t e > stOneToOneDoNotSetCMR(CMRMappingFacadeBean.java:137) > at > org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean$ > $FastClassByCGLIB$$9687c6d6.invoke() > at org.apache.openejb.dispatch.AbstractMethodOperation.invoke > (AbstractMethodOperation.java:58) > at org.apache.openejb.slsb.BusinessMethod.execute > (BusinessMethod.java:36) > > > Nothing is jumping out at me. Gianny, you have any ideas? > > -David > > >
Re: hostname vs. IP
On 12/7/06, Hernan Cunico <[EMAIL PROTECTED]> wrote:
Hi All,
is there a way to force Geronimo to display the hostname when deploying apps?
it seems to randomly change from one interface to another (I have 2 IPs diff
network on my machine) and from IP to server name. I can't figure out why
Geronimo is picking one over the other, it seems to be random.
Web Applications:
http://192.168.1.10:8080/
http://192.168.1.10:8080/console
http://192.168.1.10:8080/console-standard
http://192.168.1.10:8080/dojo
http://192.168.1.10:8080/hello
http://192.168.1.10:8080/remote-deploy
Any suggestions?
This is probably because only the method InetAddress.getHost() is
being used instead of InetAddress.getHostName(). But using
getHostName() and having it work correctly requires a reverse lookup
to be performed. But I'm sure it can be changed.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
Re: 1.2 Beta Tasks
Thanks for the nudge dain, I went through and fixed/closed/moved all my 1.2 jiras... now its someone else's fault :-) thanks david jencks On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We only have a few remaining optional and required tasks before we can cut the 1.2 beta :D TASK: Review YOUR JIRAs --- We have 60 JIRAs assigned to 1.2. Please review the issues assigned to you, and if you do not plan on fixing them in the next say 7 days move out of 1.2. Those with JIRAs remaining [1] at the end of the release will be shamed :) Other Tasks --- Normally legal is the biggest problem, and Kevan has done a wonderful in this area. FWIU, the only remaining legal issue is the presence Sun schemas and dtds in the servlet and jsp spec jars, and Kevan is working to find out if they are a real problem. Any thing else I missed Kevan? We have a few remaining SNAPSHOTS dependencies in the tree [2]. OpenEJB and Yoko are still being worked on for this release so a SNAPSHOT dependency is fine. ActiveIO and OpenJPA have released versions for the code we are using and I will work to replace this today. Matt promised me a release of TranQL for this release, and I am hoping to get this today. We have an exception being thrown in shutdown from GBeanBinding.removeBinding():159 and I'll fix that today. Thanks for all the help. Hopefully we can get the beta shipped next week! -dain [1] Currently assigned JIRA for 1.2 Aaron Mulder 3 Alan Cabrera 1 Bill Dudney 1 Christopher M. Cardona 1 David Jencks 20 Donald Woods 1 Gianny Damour 1 Kevan Miller 6 Matt Hogstrom 2 Prasad Kashyap 1 Rakesh Midha 1 Rick McGuire 1 Unassigned 21 [2] Current SNAPSHOT dependencies: activeio-core-3.0-SNAPSHOT.jar geronimo-schema-j2ee_1.4-1.1-SNAPSHOT.jar geronimo-schema-jee_5-1.0-SNAPSHOT.jar geronimo-javamail_1.3.1_spec-1.2-SNAPSHOT.jar geronimo-jpa_3.0_spec-1.0-SNAPSHOT.jar openejb-axis-2.2-incubating-SNAPSHOT.jar openejb-builder-2.2-incubating-SNAPSHOT.jar openejb-corba-2.2-incubating-SNAPSHOT.jar openejb-corba-builder-2.2-incubating-SNAPSHOT.jar openejb-core-2.2-incubating-SNAPSHOT.jar openejb-pkgen-builder-2.2-incubating-SNAPSHOT.jar openejb-yoko-2.2-incubating-SNAPSHOT.jar openjpa-all-0.9.6-incubating-SNAPSHOT.jar tranql-1.4-SNAPSHOT.jar tranql-connector-1.3-SNAPSHOT.jar tranql-connector-derby-common-1.2-SNAPSHOT.jar tranql-connector-1.3-SNAPSHOT.jar tranql-connector-derby-common-1.2-SNAPSHOT.jar yoko-core-1.0-incubating-M2-SNAPSHOT.jar yoko-rmi-impl-1.0-incubating-M2-SNAPSHOT.jar yoko-rmi-spec-1.0-incubating-M2-SNAPSHOT.jar yoko-spec-corba-1.0-incubating-M2-SNAPSHOT.jar yoko-spec-corba-1.0-incubating-M2-SNAPSHOT.jar
[jira] Closed: (GERONIMO-2627) jsr88 classpath is all messed up
[ http://issues.apache.org/jira/browse/GERONIMO-2627?page=all ] David Jencks closed GERONIMO-2627. -- Resolution: Fixed This works for me now wish we had some automated tests. > jsr88 classpath is all messed up > > > Key: GERONIMO-2627 > URL: http://issues.apache.org/jira/browse/GERONIMO-2627 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2, 2.0 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0 > > > jsr88 requires a lotta stuff in the classpath that isn't there: > geronimo-deploy-jsr88 requires xmlbeans to compile, but its not available at > runtime: this is because theres some misplaced dconfigbean stuff for app > client and application in there, should be moved to appropriate builder > modules. > it also depends on geronimo-deployment which just got removed in > GERONIMO-2624: only use is to create a temp file. I'm copying the method > into AbstractDeployCommand. > The DeploymentManager implementations also have hardcoded references to > RARConfigurer and WARConfigurer and there's no way these will ever be on a > command line classpath. I think the solution to this is to start a kernel, > start a few appropriate configs, and register the configueres with something > the DeploymentManagers can get at. I asked on the dev list for better ideas. > In any case the hardcoding just doesn't work. -- 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: Daytrader app clients
On Dec 7, 2006, at 11:50 AM, Christopher Blythe wrote: David... When I tried the streamer client I ran into the same issue that Donald Woods reported... From what I could tell, the geronimo server starts up the RMI listener on 1099 and the streamer app client is is also trying to startup a listener on the same port. That is why the address already in use exception is being thrown. However, I can't explain why the streamer client would try to startup another listener on the same port. Thoughts? That comes from some kind of bad dependency getting installed into the app client so the rmi-naming config is getting started. This doesn't happen for me with 1.2 and the daytrader-jpa plan. It might happen with earlier geronimos. Also, any clue as to were there Axis class file is located? the geronimo-axis jar. Again, in 1.2 this should be getting added automatically to the classpath, and probably isn't in earlier geronimo versions. In the mean time guess I'll take a look at the jpa plan you checked in. It only works on geronimo 1.2, despite being in daytrader trunk. Hope this helps david jencks Thanks... Chris On 12/7/06, David Jencks <[EMAIL PROTECTED]> wrote: The last time I checked these both worked great with the daytrader- jpa plan I checked in. I could see everything in streamer and perform all the operations I could find in wsapp. thanks david jencks On Dec 7, 2006, at 11:26 AM, Christopher Blythe wrote: > I was wondering if anyone out there has successfully used the wsapp > and streamer application clients that are packaged with Daytrader? > > Using the 1.2 branch, I was able to start the wsapp client, but was > unable to perform any web services operations against the server > due to the following exception. > > Exception in thread "AWT-EventQueue-0" > java.lang.NoClassDefFoundError: > org.apache.geronimo.axis.client.ServiceMethodInterceptor > > Any clues as to where this class is located? I checked the > axis-1.4.jar in the repository, but it wasn't there. > > As for the streamer app client, I was unable to get it to start. > > Thanks... > > Chris > > -- > "I say never be complete, I say stop being perfect, I say let... > lets evolve, let the chips fall where they may." - Tyler Durden -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Updated: (GERONIMO-2439) add secure transport support to POP3 (i.e., SSL)
[ http://issues.apache.org/jira/browse/GERONIMO-2439?page=all ] Jason Warner updated GERONIMO-2439: --- Attachment: POP3SSLConnection.patch Sorry about that, Rick. I though I had hounded out all those smtp references but I missed a bunch. Fixed up that port thing as well. Default for POP3Store is 110 and for POP3SSLStore is 995. > add secure transport support to POP3 (i.e., SSL) > > > Key: GERONIMO-2439 > URL: http://issues.apache.org/jira/browse/GERONIMO-2439 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Jason Warner > Assigned To: Rick McGuire >Priority: Minor > Attachments: POP3SSLConnection.patch, POP3SSLConnection.patch > > > SSL authentication added to POP3 -- 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-2624) Offline deployer busted
[ http://issues.apache.org/jira/browse/GERONIMO-2624?page=all ] David Jencks closed GERONIMO-2624. -- Resolution: Fixed only functional test is missing... > Offline deployer busted > --- > > Key: GERONIMO-2624 > URL: http://issues.apache.org/jira/browse/GERONIMO-2624 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.2, 2.0 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0 > > > There seems to be at least 2 problems: > 1. geronimo-deployment jar should not be in lib > 2. list of offline-deployers is really out of date. > 3. we don't have any functional tests to detect when it breaks. -- 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-2580) CorbaRefBuilder inserts ref for java:comp/CORBA that fails when corba gbean is not present.
[ http://issues.apache.org/jira/browse/GERONIMO-2580?page=all ] David Jencks closed GERONIMO-2580. -- Resolution: Fixed Seems to work now. > CorbaRefBuilder inserts ref for java:comp/CORBA that fails when corba gbean > is not present. > --- > > Key: GERONIMO-2580 > URL: http://issues.apache.org/jira/browse/GERONIMO-2580 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.2, 2.0 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0 > > > I just fixed the CorbaRefBuilder to actually work, however now it's inserting > References that cause starting components to fail when there isn't a matching > CORBABean available. > I'm not sure what the best solution is. One simple solution would be to > remove the CorbaRefBuilder from configurations without corba running. > However this would mean you'd have to explicitly enable corba deployments > when you want them. -- 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-2499) Generalize NamingBuilder so it can handle more than just jndi building
[ http://issues.apache.org/jira/browse/GERONIMO-2499?page=all ] David Jencks closed GERONIMO-2499. -- Fix Version/s: 2.0-M1 Resolution: Fixed More changes to the pluggable builder concept need a new jira issue. This one is sufficiently done. > Generalize NamingBuilder so it can handle more than just jndi building > -- > > Key: GERONIMO-2499 > URL: http://issues.apache.org/jira/browse/GERONIMO-2499 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0-M1 > > > we need a more unified idea of a deployer. I think we might be able to > generalize and abstract the NamingBuilder interface. One needed step is to > pass a map of info useful to the builders rather than just the jndi context > map. The jndi context map can be an entry in the new map. -- 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-2497) integrate TripleSec as a JACC provider
[ http://issues.apache.org/jira/browse/GERONIMO-2497?page=all ] David Jencks updated GERONIMO-2497: --- Fix Version/s: Wish List (was: 1.2) Not yet imported into apache directory :-( > integrate TripleSec as a JACC provider > -- > > Key: GERONIMO-2497 > URL: http://issues.apache.org/jira/browse/GERONIMO-2497 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: Wish List > > > The TripleSec project will soon be a part of Apache Directory. It should be > failrly simple to use it as a JACC provider in geronimo. CF mailing list > discussion. -- 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-2492) Integrate CXF webservices
[ http://issues.apache.org/jira/browse/GERONIMO-2492?page=all ] David Jencks updated GERONIMO-2492: --- Fix Version/s: 2.0-M1 (was: 1.2) > Integrate CXF webservices > - > > Key: GERONIMO-2492 > URL: http://issues.apache.org/jira/browse/GERONIMO-2492 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0-M1 > > > Integrate CXF for webservices. Probably at least 3 steps > - pojo ws > - ejb ws > - ws client > There's a early version of a celtix-geronimo deployer we can try updating. -- 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-2491) Hibernate passes connections between servlets which we don't support
[ http://issues.apache.org/jira/browse/GERONIMO-2491?page=all ] David Jencks updated GERONIMO-2491: --- Fix Version/s: 2.0-M1 (was: 1.1.2) (was: 1.2) Assignee: Jeff Genender (was: David Jencks) If you can get roller to deploy and this is still a problem please reassign to me with a stack trace. If we fixed this problem please close. If you can't get roller to deploy anymore either, assign it back to me :-) > Hibernate passes connections between servlets which we don't support > > > Key: GERONIMO-2491 > URL: http://issues.apache.org/jira/browse/GERONIMO-2491 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector >Affects Versions: 1.1.1, 1.2 >Reporter: David Jencks > Assigned To: Jeff Genender > Fix For: 2.0-M1 > > > This is based on examination of roller running in geronimo-tomcat and is > partly speculation. There's certainly a problem. > 1. request sets InstanceContext 1 in ConnectionTrackingCoordinator. > 2. roller starts a persistence context (in hibernate jargon a session) in a > servlet filter. No connection is opened yet > 3. tiles dispatches to a jsp > 4. dispatch sets InstanceContext 2 in CTC > 5. jsp does something persistent causing hibernate to open a db connection. > This is registered with IC 2. > 6. jsp dispatch returns, so IC 1 is set in CTC > 7. roller commits the persistence context in the servlet filter, which closes > the connection. Closing the connection attempts to unregister from the > current IC. IC 1 doesn't know anything about this connection. we get an > NPE. > The solution isn't clear to me at the moment. -- 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-2485) PersistenceUnitGBean needs a NamespaceDrivenDeployer
[ http://issues.apache.org/jira/browse/GERONIMO-2485?page=all ] David Jencks updated GERONIMO-2485: --- Fix Version/s: 2.0-M1 (was: 1.2) > PersistenceUnitGBean needs a NamespaceDrivenDeployer > > > Key: GERONIMO-2485 > URL: http://issues.apache.org/jira/browse/GERONIMO-2485 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: persistence >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0-M1 > > > Most of the config into in PersistenceUnitGBean can be read out of > persistence.xml. We should write a NamespaceDrivenBuilder that uses custom > xml and can either set stuff from the supplied xml, look for persistence.xml > in a specified location, or look for persistence.xml in a default location, > and parse persistence.xml. -- 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-2479) j2ee remote ejb clients should look for "localhost" not 0.0.0.0 by default
[ http://issues.apache.org/jira/browse/GERONIMO-2479?page=all ] David Jencks closed GERONIMO-2479. -- Fix Version/s: 2.0-M1 Resolution: Fixed This has been fixed for a while using the property PlanClientAddresses set to 127.0.0.1 > j2ee remote ejb clients should look for "localhost" not 0.0.0.0 by default > -- > > Key: GERONIMO-2479 > URL: http://issues.apache.org/jira/browse/GERONIMO-2479 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0-M1 > > > The OpenEjbClientRemoteRefBuilder is misconfigured to try to connect to > 0.0.0.0 which doesn't make sense. Change to localhost. -- 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
hostname vs. IP
Hi All, is there a way to force Geronimo to display the hostname when deploying apps? it seems to randomly change from one interface to another (I have 2 IPs diff network on my machine) and from IP to server name. I can't figure out why Geronimo is picking one over the other, it seems to be random. Web Applications: http://192.168.1.10:8080/ http://192.168.1.10:8080/console http://192.168.1.10:8080/console-standard http://192.168.1.10:8080/dojo http://192.168.1.10:8080/hello http://192.168.1.10:8080/remote-deploy Any suggestions? Cheers! Hernan
Re: [jira] Commented: (DAYTRADER-17) Dojo-based interface for Daytrader
It's at /dojo. Note that the dojo app is deployed in geronimo's j2ee assemblies but is not explicitly started by default. It gets automatically started because the console has a dependency against it. If the console is not installed or started then you can either start the dojo app manually from the console/CLI or include a dependency against it in your deployment plan. The latter approach is preferable since it lets geronimo do the dependency management for you. Best wishes, Paul On 12/7/06, Christopher Blythe <[EMAIL PROTECTED]> wrote: Paul... you'll have to refresh my memory... what context does geronimo provide the pre-packaged version of dojo at? On 12/7/06, Paul McMahan (JIRA) < dev@geronimo.apache.org> wrote: > [ http://issues.apache.org/jira/browse/DAYTRADER-17?page=comments#action_12456563 ] > > Paul McMahan commented on DAYTRADER-17: > --- > > This sounds like a good idea. I think an improvement would be for the daytrader app to always refer to the dojo resources at "/dojo" and either use the geronimo's dojo which is at that location or (for other app servers) have the user install the dojo webapp to that context as an additional step. My concern with changing the daytrader code is that most app servers don't guarantee you can make changes to an application after deployment. e.g. upgrading the app would lose modifications, also think about a clustered env, etc. > > > Dojo-based interface for Daytrader > > -- > > > > Key: DAYTRADER-17 > > URL: http://issues.apache.org/jira/browse/DAYTRADER-17 > > Project: DayTrader > > Issue Type: New Feature > > Components: Web Tier > >Affects Versions: 1.2 > >Reporter: Christopher James Blythe > > Attachments: daytrader-17.zip, daytrader-17.zip > > > > > > Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. > > -- > 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 > > > -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Assigned: (GERONIMO-2129) Allow user to specify the pool size for Stateless Session beans
[ http://issues.apache.org/jira/browse/GERONIMO-2129?page=all ] Dain Sundstrom reassigned GERONIMO-2129: Assignee: Matt Hogstrom If this is not going to make it into 1.2, please move to another release. > Allow user to specify the pool size for Stateless Session beans > --- > > Key: GERONIMO-2129 > URL: http://issues.apache.org/jira/browse/GERONIMO-2129 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 1.2 > > > OpenEJB has code implemented to Pool Stateless session beans. This support > is currently hardcoded to a cache size of one which eliminates any > performance benefit of caching. A new attribute will be added to the OpenEJB > XSD that will allow the user to specify the pool size to be used for a > deployed stateless session bean. > The attribute will be and will take an integer value as its > argument. -- 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-2460) JPA container managed persistence support
[ http://issues.apache.org/jira/browse/GERONIMO-2460?page=all ] David Jencks closed GERONIMO-2460. -- Fix Version/s: 2.0-M1 Resolution: Fixed Enough is working... we can open specific bugs for anything else we find. > JPA container managed persistence support > - > > Key: GERONIMO-2460 > URL: http://issues.apache.org/jira/browse/GERONIMO-2460 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0-M1 > > > Provide some way to use jpa with container managed persistence while we > figure out the spec deployment details. > An implementation is in sandbox/javaee5. You set up a PersistenceUnitGBean > in your app plan and use persistence-context-refs in your app jndi > descriptions (in the geronimo plan, not the spec dd) -- 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] Assigned: (GERONIMO-2630) sun j2ee schemas are being redistributed in jsp and servlet specs
[ http://issues.apache.org/jira/browse/GERONIMO-2630?page=all ] Dain Sundstrom reassigned GERONIMO-2630: Assignee: Kevan Miller FWIU Kevan is looking at this one. > sun j2ee schemas are being redistributed in jsp and servlet specs > - > > Key: GERONIMO-2630 > URL: http://issues.apache.org/jira/browse/GERONIMO-2630 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: specs >Affects Versions: 1.2, 2.0 >Reporter: Kevan Miller > Assigned To: Kevan Miller >Priority: Blocker > Fix For: 1.2, 2.0 > > > A variety of Sun J2EE xsd's and dtd's are being redistributed in our corba > 3.0, jsp and servlet specs. > We had the same problem in our j2ee-schema module a while back. Without > written outhorization from Sun, we cannot redistribute these xsd's and dtd's. > Here's a list of problem files, that I see: > trunk/geronimo-corba_3.0_spec/src/main/idl/CosTransactions.idl:11://Copyright > 1995-1996, Sun Microsystems, Inc. > trunk/geronimo-jsp_2.0_spec/src/main/schema/jsp_2_0.xsd:18: Copyright > 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.0_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:19: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_0.xsd:34: Copyright > 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/jsp_2_1.xsd:35: Copyright > 2003-2005 Sun Microsystems, Inc. > trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_0.xsd:35: > Copyright 2003 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-jsp_2.1_spec/src/main/schema/web-jsptaglibrary_2_1.xsd:36: > Copyright 2003-2005 Sun Microsystems, Inc. > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_1_4.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_1_1.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:2:Copyright > 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_3.dtd:38:Copyright > 2000-2001 Sun Microsystems, Inc., > trunk/geronimo-servlet_2.4_spec/src/main/schema/web-app_2_4.xsd:18: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/http/package.html:6: > Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. > trunk/geronimo-servlet_2.5_spec/src/main/java/javax/servlet/package.html:6: > Copyright 2001 Sun Microsystems, Inc. All Rights Reserved. > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_1_4.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_1_1.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/j2ee_web_services_client_1_1.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:18:Copyright > 2000-2001 Sun Microsystems, Inc. 901 San Antonio Road, > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_3.dtd:54:Copyright > 2000-2001 Sun Microsystems, Inc., > trunk/geronimo-servlet_2.5_spec/src/main/schema/web-app_2_4.xsd:34: > Copyright 2002 Sun Microsystems, Inc., 901 San Antonio -- 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-2339) Empty auth-constraint tag in web app security-constraint does not prevent access to resource
[ http://issues.apache.org/jira/browse/GERONIMO-2339?page=all ] Dain Sundstrom closed GERONIMO-2339. Resolution: Won't Fix Assignee: Vamsavardhana Reddy > Empty auth-constraint tag in web app security-constraint does not prevent > access to resource > > > Key: GERONIMO-2339 > URL: http://issues.apache.org/jira/browse/GERONIMO-2339 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security, Tomcat >Affects Versions: 1.1.1 > Environment: Geronimo Tomcat 1.1.1 >Reporter: Vamsavardhana Reddy > Assigned To: Vamsavardhana Reddy > Fix For: 1.1.2, 1.2, 2.0 > > Attachments: g2339.war > > > I have the following security constraint in web.xml > > > No Access > /forbidden/* > > > > This means /forbidden/* is not accessible by any user. The permission woks > fine if the application is deployed in Geronimo Jetty distribution. > If the application is deployed in Geronimo Tomcat distribution, URLs > /forbidden/* are accessible by all users. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2210) Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2210?page=all ]
Dain Sundstrom updated GERONIMO-2210:
-
Fix Version/s: 2.0
(was: 1.2)
Assignee: Anita Kulshreshtha
No need to back port the fix to 1.2. If this is fixed in trunk, please close
the issue.
> Enable tests (geronimo-connector-builder :: **/Connector15DCBTest.java)
> ---
>
> Key: GERONIMO-2210
> URL: http://issues.apache.org/jira/browse/GERONIMO-2210
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
>Affects Versions: 1.2
>Reporter: Jason Dillon
> Assigned To: Anita Kulshreshtha
> Fix For: 2.0
>
>
> A few tests failed in non-obvious ways when run under the m2 build. Need
> someone who knows these tests better to inspect, resolve and enable the test
> (remove the test exclusions in the pom).
> The test fails with (on the console):
> {noformat}
> Ignoring connectiondefinition-instance/config-setting ServerUrl (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting UserName (no matching
> config-property in J2EE DD)
> Ignoring connectiondefinition-instance/config-setting Password (no matching
> config-property in J2EE DD)
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Queue' and class 'org.activemq.message.ActiveMQQueue' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> Geronimo connector deployment plan has admin object with interface
> 'javax.jms.Topic' and class 'org.activemq.message.ActiveMQTopic' but the
> ra.xml does not have a matching adminobject declared. Deleting this
> adminobject from the Geronimo plan.
> {noformat}
> And in the surefire report:
> {noformat}
> ---
> Test set: org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest
> ---
> Tests run: 4, Failures: 3, Errors: 1, Skipped: 0, Time elapsed: 1.488 sec <<<
> FAILURE!
> testCreateDatabase(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.66 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.geronimo.connector.deployment.jsr88.ConnectionDefinition.configure(ConnectionDefinition.java:64)
> at
> org.apache.geronimo.connector.deployment.jsr88.ResourceAdapter.setConnectionDefinition(ResourceAdapter.java:111)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateDatabase(Connector15DCBTest.java:114)
> testWriteWithNulls(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.046 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<1> but was:<0>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testWriteWithNulls(Connector15DCBTest.java:205)
> testCreateJMSResource(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.382 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testCreateJMSResource(Connector15DCBTest.java:355)
> testLoadJMSResources(org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest)
> Time elapsed: 0.38 sec <<< FAILURE!
> junit.framework.AssertionFailedError: expected:<7> but was:<4>
> at junit.framework.Assert.fail(Assert.java:47)
> at junit.framework.Assert.failNotEquals(Assert.java:282)
> at junit.framework.Assert.assertEquals(Assert.java:64)
> at junit.framework.Assert.assertEquals(Assert.java:201)
> at junit.framework.Assert.assertEquals(Assert.java:207)
> at
> org.apache.geronimo.connector.deployment.jsr88.Connector15DCBTest.testLoadJMSResources
[jira] Closed: (GERONIMO-2459) Connector deployer needs to add dependency to j2ee-server for J2EEServer gbean reference
[ http://issues.apache.org/jira/browse/GERONIMO-2459?page=all ] David Jencks closed GERONIMO-2459. -- Fix Version/s: 2.0-M1 Resolution: Fixed This appears to have been fixed some time ago. I don't know if there is an equivalent problem on the app client. > Connector deployer needs to add dependency to j2ee-server for J2EEServer > gbean reference > > > Key: GERONIMO-2459 > URL: http://issues.apache.org/jira/browse/GERONIMO-2459 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2, 2.0-M1 > > > The connector ResourceAdapterModule gbean has a reference to the J2eeServer > jsr-77 gbean that is in the j2ee-server module. Thus the connector-deployer > should install a dependency to j2ee-server through its default-environment > merging. Right now we don't see this because the system-database module > includes an explicit dependency on j2ee-server as it should not do. -- 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-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=all ] Dain Sundstrom updated GERONIMO-2283: - Fix Version/s: (was: 1.2) Assignee: Vamsavardhana Reddy > Common libs portlet guesses wrong group ID, gives no usage advice > - > > Key: GERONIMO-2283 > URL: http://issues.apache.org/jira/browse/GERONIMO-2283 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Vamsavardhana Reddy > Fix For: 1.1.x, 2.0 > > > When selecting a file for the repository portlet, it selected the version > number as the group ID. It should probably default to a blank group ID and > make the user enter it -- the best it can select from the file name is > probably the artifact, version, and type. > Also, it should have an option where you pick a JAR and it gives you the > dependency syntax you need to add that JAR to the classpath for an > application or other Geronimo module. -- 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-2392) Too hard to tell why a gbean doesn't start
[ http://issues.apache.org/jira/browse/GERONIMO-2392?page=all ]
David Jencks closed GERONIMO-2392.
--
Fix Version/s: 2.0-M1
Resolution: Fixed
Fixed trunk rev 483639
1.2 rev 483640
> Too hard to tell why a gbean doesn't start
> --
>
> Key: GERONIMO-2392
> URL: http://issues.apache.org/jira/browse/GERONIMO-2392
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
>Reporter: David Jencks
> Assigned To: David Jencks
> Fix For: 1.2, 2.0-M1
>
>
> I keep having trouble figuring out why my gbeans wont start. The following
> helps me see what's going on. What do people think about committing this?
> Index:
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
> ===
> ---
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
> (revision 441840)
> +++
> modules/geronimo-kernel/src/main/java/org/apache/geronimo/kernel/config/ConfigurationUtil.java
> (working copy)
> @@ -363,6 +363,9 @@
> loaded.add(gbeanData.getAbstractName());
> } catch (GBeanAlreadyExistsException e) {
> throw new InvalidConfigException(e);
> +} catch (Throwable e) {
> +log.warn("Could not load gbean " +
> gbeanData.getAbstractName(), e);
> +throw e;
> }
> }
>
--
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-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12456575 ] Dain Sundstrom commented on GERONIMO-2283: -- Still a problem in 1.2 > Common libs portlet guesses wrong group ID, gives no usage advice > - > > Key: GERONIMO-2283 > URL: http://issues.apache.org/jira/browse/GERONIMO-2283 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.2, 1.1.x, 2.0 > > > When selecting a file for the repository portlet, it selected the version > number as the group ID. It should probably default to a blank group ID and > make the user enter it -- the best it can select from the file name is > probably the artifact, version, and type. > Also, it should have an option where you pick a JAR and it gives you the > dependency syntax you need to add that JAR to the classpath for an > application or other Geronimo module. -- 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-2397) Need to use the jee5 schemas without redistributing them
[ http://issues.apache.org/jira/browse/GERONIMO-2397?page=all ] David Jencks closed GERONIMO-2397. -- Resolution: Fixed This has been working for a while > Need to use the jee5 schemas without redistributing them > > > Key: GERONIMO-2397 > URL: http://issues.apache.org/jira/browse/GERONIMO-2397 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > > AFAICT the jee5 schemas have the same vague language prohibiting > redistribution as the j2ee 1.4 schemas, so we better not have them in > publically accessible svn. > Just as we did for the j2ee 1.4 schemas I'll set up a module in tck that > builds xmlbeans source and binary jars for the jee5 schemas and remove them > from the sandbox/servlet2.5 where they are publically available today. -- 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-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=comments#action_12456572 ] Dain Sundstrom commented on GERONIMO-1786: -- May be cause by using activeio 3.0 SNAPSHOT when we should be using the 3.0 release. Will try upgrading. > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.1, 1.2, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerIm
[jira] Closed: (GERONIMO-2350) CertificateChainCallbackHandler willfully conceals causes of failure
[ http://issues.apache.org/jira/browse/GERONIMO-2350?page=all ] David Jencks closed GERONIMO-2350. -- Fix Version/s: 2.0-M1 Resolution: Fixed Fixed in 1.2 rev 483635 trunk rev 483636 > CertificateChainCallbackHandler willfully conceals causes of failure > > > Key: GERONIMO-2350 > URL: http://issues.apache.org/jira/browse/GERONIMO-2350 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.1.2, 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.1.2, 1.2, 2.0-M1 > > > The CertificateChainCallbackHandler has a lot of ways to fail, all of which > are caused by configuration errors, not invalid user input/attempts to hack > in. This stuff is hard enough to set up without hiding problems. This > should be improved to clearly indicate the problems when they occur. -- 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] Assigned: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] Dain Sundstrom reassigned GERONIMO-1786: Assignee: Dain Sundstrom > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ, console >Affects Versions: 1.0, 1.1, 1.2, 1.1.1 > Environment: Geronimo 1.0.0 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > 222: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > 223:
[jira] Assigned: (GERONIMO-2560) Realm added using SecurityRealm portlet does not work
[ http://issues.apache.org/jira/browse/GERONIMO-2560?page=all ] Dain Sundstrom reassigned GERONIMO-2560: Assignee: Vamsavardhana Reddy > Realm added using SecurityRealm portlet does not work > - > > Key: GERONIMO-2560 > URL: http://issues.apache.org/jira/browse/GERONIMO-2560 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, security >Affects Versions: 1.2, 2.0 >Reporter: Vamsavardhana Reddy > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 2.0 > > > A new security realm added using SecurityRealm portlet does not get listed in > the portlet. There are no deployment errors. Also, if an application is > configured to authenticate against this realm, login is failing since the > realm could not be found. > The deployment plan for security realms generated in the console seems to use > a "service" tag in place of "gbean" tag. If the service tag is changed to > gbean tag, the realm is getting listed in the SecurityRealm portlet. -- 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-2292) Investigate unused targetConfigId parameter in EJB refs
[ http://issues.apache.org/jira/browse/GERONIMO-2292?page=all ] David Jencks updated GERONIMO-2292: --- Fix Version/s: Wish List (was: 1.1.2) > Investigate unused targetConfigId parameter in EJB refs > --- > > Key: GERONIMO-2292 > URL: http://issues.apache.org/jira/browse/GERONIMO-2292 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, OpenEJB >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: David Jencks > Fix For: Wish List > > > In OpenEJBReferenceBuilder: > createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument. > Then they often call getMatch or getImplicitMatch and don't use the > targetConfigId. As a result, the current module's ID is always used as the > targetConfigId: > context.findGBeans(new AbstractNameQuery(context.getId(), ... > This means that the query will never match EJBs in a parent of the current > configuration. It should be changed to use the targetConfigId instead of the > current module's ID. > This does not come up if a pattern element is used in the mapping, though > that mapping strategy runs into a different 1.1 bug (ClassCastException on > org.openejb.proxy.ProxyInfo) -- 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: [jira] Commented: (DAYTRADER-17) Dojo-based interface for Daytrader
Paul... you'll have to refresh my memory... what context does geronimo provide the pre-packaged version of dojo at? On 12/7/06, Paul McMahan (JIRA) wrote: [ http://issues.apache.org/jira/browse/DAYTRADER-17?page=comments#action_12456563] Paul McMahan commented on DAYTRADER-17: --- This sounds like a good idea. I think an improvement would be for the daytrader app to always refer to the dojo resources at "/dojo" and either use the geronimo's dojo which is at that location or (for other app servers) have the user install the dojo webapp to that context as an additional step. My concern with changing the daytrader code is that most app servers don't guarantee you can make changes to an application after deployment. e.g. upgrading the app would lose modifications, also think about a clustered env, etc. > Dojo-based interface for Daytrader > -- > > Key: DAYTRADER-17 > URL: http://issues.apache.org/jira/browse/DAYTRADER-17 > Project: DayTrader > Issue Type: New Feature > Components: Web Tier >Affects Versions: 1.2 >Reporter: Christopher James Blythe > Attachments: daytrader-17.zip, daytrader-17.zip > > > Have opened this to track work on the Dojo-based UI for Daytrader that I have been playing around with. -- 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 -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Closed: (GERONIMO-2549) NullPointerException: CommandListConfigurations
[ http://issues.apache.org/jira/browse/GERONIMO-2549?page=all ] Dain Sundstrom closed GERONIMO-2549. Resolution: Fixed Thanks for the patch Mark DeLaFranier > NullPointerException: CommandListConfigurations > --- > > Key: GERONIMO-2549 > URL: http://issues.apache.org/jira/browse/GERONIMO-2549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 > Environment: windows xp >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2549.patch > > > > deploy.bat search-plugins http://bogus-server/maven2 > Using GERONIMO_BASE: D:\geronimo\1.2 > Using GERONIMO_HOME: D:\geronimo\1.2 > Using GERONIMO_TMPDIR: D:\geronimo\1.2\var\temp > Using JRE_HOME:d:\dev\jdk142 > Username: system > Password: *** > Exception in thread "main" java.lang.NullPointerException > at > org.apache.geronimo.deployment.cli.CommandListConfigurations.execute(CommandListConfigurations.java:84) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:160) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- 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-2560) Realm added using SecurityRealm portlet does not work
[
http://issues.apache.org/jira/browse/GERONIMO-2560?page=comments#action_12456564
]
Vamsavardhana Reddy commented on GERONIMO-2560:
---
SecurityRealm portlet is currently generating a plan given below. There are no
deployment errors.
But then the new realm does not get listed in the portlet and the realm could
not be used for authentication.
What is wrong with this plan?
{code}
http://geronimo.apache.org/xml/ns/deployment-1.2";>
console.realm
myrealm
1.0
car
org.apache.geronimo.configs
j2ee-security
car
http://geronimo.apache.org/xml/ns/deployment-1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
myrealm
ServerInfo
JaasLoginService
http://geronimo.apache.org/xml/ns/loginconfig-1.2";>
myrealm
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule
var/security/users.properties
var/security/groups.properties
{code}
> Realm added using SecurityRealm portlet does not work
> -
>
> Key: GERONIMO-2560
> URL: http://issues.apache.org/jira/browse/GERONIMO-2560
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: console, security
>Affects Versions: 1.2, 2.0
>Reporter: Vamsavardhana Reddy
>Priority: Critical
> Fix For: 1.2, 2.0
>
>
> A new security realm added using SecurityRealm portlet does not get listed in
> the portlet. There are no deployment errors. Also, if an application is
> configured to authenticate against this realm, login is failing since the
> realm could not be found.
> The deployment plan for security realms generated in the console seems to use
> a "service" tag in place of "gbean" tag. If the service tag is changed to
> gbean tag, the realm is getting listed in the SecurityRealm portlet.
--
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: (DAYTRADER-17) Dojo-based interface for Daytrader
[ http://issues.apache.org/jira/browse/DAYTRADER-17?page=comments#action_12456563 ] Paul McMahan commented on DAYTRADER-17: --- This sounds like a good idea. I think an improvement would be for the daytrader app to always refer to the dojo resources at "/dojo" and either use the geronimo's dojo which is at that location or (for other app servers) have the user install the dojo webapp to that context as an additional step. My concern with changing the daytrader code is that most app servers don't guarantee you can make changes to an application after deployment. e.g. upgrading the app would lose modifications, also think about a clustered env, etc. > Dojo-based interface for Daytrader > -- > > Key: DAYTRADER-17 > URL: http://issues.apache.org/jira/browse/DAYTRADER-17 > Project: DayTrader > Issue Type: New Feature > Components: Web Tier >Affects Versions: 1.2 >Reporter: Christopher James Blythe > Attachments: daytrader-17.zip, daytrader-17.zip > > > Have opened this to track work on the Dojo-based UI for Daytrader that I have > been playing around with. -- 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: Daytrader app clients
David... When I tried the streamer client I ran into the same issue that Donald Woods reported... From what I could tell, the geronimo server starts up the RMI listener on 1099 and the streamer app client is is also trying to startup a listener on the same port. That is why the address already in use exception is being thrown. However, I can't explain why the streamer client would try to startup another listener on the same port. Thoughts? Also, any clue as to were there Axis class file is located? In the mean time guess I'll take a look at the jpa plan you checked in. Thanks... Chris On 12/7/06, David Jencks <[EMAIL PROTECTED]> wrote: The last time I checked these both worked great with the daytrader- jpa plan I checked in. I could see everything in streamer and perform all the operations I could find in wsapp. thanks david jencks On Dec 7, 2006, at 11:26 AM, Christopher Blythe wrote: > I was wondering if anyone out there has successfully used the wsapp > and streamer application clients that are packaged with Daytrader? > > Using the 1.2 branch, I was able to start the wsapp client, but was > unable to perform any web services operations against the server > due to the following exception. > > Exception in thread "AWT-EventQueue-0" > java.lang.NoClassDefFoundError: > org.apache.geronimo.axis.client.ServiceMethodInterceptor > > Any clues as to where this class is located? I checked the > axis-1.4.jar in the repository, but it wasn't there. > > As for the streamer app client, I was unable to get it to start. > > Thanks... > > Chris > > -- > "I say never be complete, I say stop being perfect, I say let... > lets evolve, let the chips fall where they may." - Tyler Durden -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
Re: Daytrader app clients
The last time I checked these both worked great with the daytrader- jpa plan I checked in. I could see everything in streamer and perform all the operations I could find in wsapp. thanks david jencks On Dec 7, 2006, at 11:26 AM, Christopher Blythe wrote: I was wondering if anyone out there has successfully used the wsapp and streamer application clients that are packaged with Daytrader? Using the 1.2 branch, I was able to start the wsapp client, but was unable to perform any web services operations against the server due to the following exception. Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: org.apache.geronimo.axis.client.ServiceMethodInterceptor Any clues as to where this class is located? I checked the axis-1.4.jar in the repository, but it wasn't there. As for the streamer app client, I was unable to get it to start. Thanks... Chris -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Updated: (GERONIMO-2246) Why resource-env-ref:admin-object-module?
[ http://issues.apache.org/jira/browse/GERONIMO-2246?page=all ] David Jencks updated GERONIMO-2246: --- Fix Version/s: 2.0 (was: 1.2) > Why resource-env-ref:admin-object-module? > - > > Key: GERONIMO-2246 > URL: http://issues.apache.org/jira/browse/GERONIMO-2246 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: connector, deployment >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: David Jencks > Fix For: 2.0 > > > When mapping resource-env-refs (or a message-destination), It doesn't seem > like admin-object-module is necessary. It can be provided alongside > admin-object-name in order to narrow the search down to a specific module > within an EAR (the current EAR or any EAR in the dependency graph that has a > module with that name). However, if you need to specify a module, you can > just use: > > jms.rar > foo > > Instead of using admin-object-module and admin-object-name. It doesn't seem > like this redundancy gets us anything, so I'd rather remove > admin-object-module and make admin-object-link work like any other > resource/EJB link (name only -- use "pattern" for more complex stuff). > If we proceed, I don't think we necessarily want to remove it in 1.1.x > (breaking backward compatibility with 1.1.0) -- we can remove it in 1.2 and > remove message-destination-link at the same time. > David J, could you comment? -- 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-2613) Some portlets in the console can't size correctly
[ http://issues.apache.org/jira/browse/GERONIMO-2613?page=all ] Dain Sundstrom updated GERONIMO-2613: - Fix Version/s: (was: 1.2) (was: 2.0) > Some portlets in the console can't size correctly > - > > Key: GERONIMO-2613 > URL: http://issues.apache.org/jira/browse/GERONIMO-2613 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console > Environment: this is for revision r480769 >Reporter: Hernan Cunico > > Here is a list of portlets I saw having rendering problems. > JMS Server Manager (uses just 50% of the available space) > Installed Web Applications (does not wrap up, have to scroll sideways) > Installed J2EE Connectors (does not wrap up, have to scroll sideways) > Installed System Modules (does not wrap up, have to scroll sideways) > Console Realm, both Console Realm Users and Console Realm Groups (uses just > 50% of the available space) -- 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-2227) ENC Lookup Fix (include parent modules)
[ http://issues.apache.org/jira/browse/GERONIMO-2227?page=all ] David Jencks updated GERONIMO-2227: --- Fix Version/s: Wish List (was: 1.x) Assignee: Aaron Mulder (was: David Jencks) Don't see how to progress without more info... > ENC Lookup Fix (include parent modules) > --- > > Key: GERONIMO-2227 > URL: http://issues.apache.org/jira/browse/GERONIMO-2227 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Aaron Mulder > Fix For: Wish List > > Attachments: 2227-enc-include-parents.patch > > > I ran across this while working on plugins that use resource-ref-like > features to identify a database connection pool, JMS destination, etc. > The problem was that some naming searches were restricted to the current > module only when I felt all parents should be searched too. > I would like David J to review this before I commit it, as my understanding > of the code in question is not terribly thorough. -- 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-2082) [m2] stax dependencies are all wrong
[ http://issues.apache.org/jira/browse/GERONIMO-2082?page=all ] David Jencks updated GERONIMO-2082: --- Fix Version/s: 2.0 (was: 1.2) > [m2] stax dependencies are all wrong > > > Key: GERONIMO-2082 > URL: http://issues.apache.org/jira/browse/GERONIMO-2082 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0 > > Attachments: geronimo-no-stax-v2.diff, geronimo-no-stax.diff, > m2-repo.jar, openejb-no-stax-v2.diff, openejb-no-stax.diff, xbean-2.0.0.pom, > xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar, > xmlbeans-maven-plugin-2.0.1-SNAPSHOT.jar > > > The dependencies for xmlbeans and the maven xmlbeans plugins are all wrong. > xmlbeans pom needs to depend on stax-api, see > http://jira.codehaus.org/browse/MEV-406 > xmlbeans plugin needs to have stax-api and stax dependencies removed, see > http://jira.codehaus.org/browse/MXMLBEANS-19 > At this point we can remove all stax and stax-api dependencies from our (and > openejb) poms. > I'll attach the modified xmlbeans pom, the modified plugin, and the patches > to remove all stax mentions from our poms. I'd appreciate some verification > of my results. -- 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-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=all ] Dain Sundstrom updated GERONIMO-1431: - Fix Version/s: 2.0 (was: 1.2) > Make deploy tool and hot deploy directory work better together > -- > > Key: GERONIMO-1431 > URL: http://issues.apache.org/jira/browse/GERONIMO-1431 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment, Hot Deploy Dir >Affects Versions: 1.0 >Reporter: Aaron Mulder >Priority: Critical > Fix For: 2.0 > > Attachments: hotdeploydelete.patch > > > Right now if you deploy something with the deploy tool and then drop an > update in the hot deploy directory, it doesn't work. The hot deploy dir > expects you to only use the hot dpeloy dir for that module. > Likewise, if you deploy something with the hot deploy dir and then undeploy > it with the deploy tool, it is not deleted from the hot deploy dir. > Both of those can be fixed. -- 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-2387) Server life cycle log entries should be generated by the server
[ http://issues.apache.org/jira/browse/GERONIMO-2387?page=all ] Dain Sundstrom updated GERONIMO-2387: - Fix Version/s: (was: 1.2) > Server life cycle log entries should be generated by the server > --- > > Key: GERONIMO-2387 > URL: http://issues.apache.org/jira/browse/GERONIMO-2387 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Kevan Miller > Fix For: 1.1.2, 2.0 > > > By default, geronimo should generate life cycle log entries. For example: > 1) "starting" with environmental information > 2) "started" > 3) stopping -- 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-2079) No methodProxy in EJBInvocation at startup under heavy load
[ http://issues.apache.org/jira/browse/GERONIMO-2079?page=all ] David Jencks updated GERONIMO-2079: --- Fix Version/s: Wish List (was: 1.2) Assignee: Matt Hogstrom (was: David Jencks) Is this a performance decrease we should worry about? > No methodProxy in EJBInvocation at startup under heavy load > --- > > Key: GERONIMO-2079 > URL: http://issues.apache.org/jira/browse/GERONIMO-2079 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: OpenEJB >Affects Versions: 1.1 >Reporter: David Jencks > Assigned To: Matt Hogstrom > Fix For: Wish List > > Attachments: 2079.patch, GERONIMO-2079.failed1.patch > > > After deploying daytrader, if you apply heavy load (50 threads) you get about > 60 exceptions like this: > java.lang.NullPointerException > at > org.openejb.proxy.EJBMethodInterceptor.createEJBInvocation(EJBMethodInterceptor.java:203) > at > org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:131) > at > org.openejb.proxy.EntityEJBLocalObject$$EnhancerByCGLIB$$84c9ae5f.getDataBean() > at > org.apache.geronimo.samples.daytrader.web.prims.PingServlet2EntityLocal.doGet(PingServlet2EntityLocal.java:126) > at > org.apache.geronimo.samples.daytrader.web.prims.PingServlet2EntityLocal.doPost(PingServlet2EntityLocal.java:54) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:46) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) > at java.lang.Thread.run(Thread.java:534) > > > Looking into the code, it appears that cglib is calling EJBMethodInterceptor > with a null methodProxy. After these startup exceptions, which appear to > occur within the first 2 seconds of load, there are no further exceptions: i > ran it for 17 minutes at 1200 pages/sec. -- 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
Daytrader app clients
I was wondering if anyone out there has successfully used the wsapp and streamer application clients that are packaged with Daytrader? Using the 1.2 branch, I was able to start the wsapp client, but was unable to perform any web services operations against the server due to the following exception. Exception in thread "AWT-EventQueue-0" java.lang.NoClassDefFoundError: org.apache.geronimo.axis.client.ServiceMethodInterceptor Any clues as to where this class is located? I checked the axis-1.4.jar in the repository, but it wasn't there. As for the streamer app client, I was unable to get it to start. Thanks... Chris -- "I say never be complete, I say stop being perfect, I say let... lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Assigned: (GERONIMO-2522) Hot deployer makes app hangs
[ http://issues.apache.org/jira/browse/GERONIMO-2522?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2522: - Assignee: Vamsavardhana Reddy > Hot deployer makes app hangs > > > Key: GERONIMO-2522 > URL: http://issues.apache.org/jira/browse/GERONIMO-2522 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 1.1.1 > Environment: Linux 2.6.15-1.2054_FC5smp > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) > Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) > Using JAVA_OPTS > -J-server -XX:NewSize=250M -XX:MaxNewSize=250M -Xms1000M -Xmx1000M > -Djava.awt.headless=true > Pentium IV 3.0 HT, 2GB mem >Reporter: Dario Andrade > Assigned To: Vamsavardhana Reddy >Priority: Critical > > When modifying a jsp file in GERONIMO_BASE/deploy/root/, a > redeployment occurs. > After that, no more requests are processed, hanging for an indefinite period > of time (waited for more than 2 minutes). > After shutting down geronimo, removing GERONIMO_BASE/repository/default/*, > commenting out config.xml module and finally starting up the AS, evertyhing > works fine. > I had to --inPlace deploy and set > load="false" to the hot-deployer.car module in config.xml, in order to avoid > future problems. -- 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-1722) Module migration to Maven 2: activemq-embedded-rar
[ http://issues.apache.org/jira/browse/GERONIMO-1722?page=all ] David Jencks closed GERONIMO-1722. -- Fix Version/s: 2.0 Resolution: Fixed 1.2 rev 483619 trunk rev 483620 > Module migration to Maven 2: activemq-embedded-rar > -- > > Key: GERONIMO-1722 > URL: http://issues.apache.org/jira/browse/GERONIMO-1722 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 1.2 >Reporter: Jacek Laskowski > Assigned To: David Jencks > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-1722.patch > > > It's a task to help keep track of the progress of the module build migration > to Maven2 -- 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] Assigned: (GERONIMO-2584) Hot deploy module/server restart, throws IllegalArgumentException if application deployed using hotdeployment
[ http://issues.apache.org/jira/browse/GERONIMO-2584?page=all ] Vamsavardhana Reddy reassigned GERONIMO-2584: - Assignee: Vamsavardhana Reddy > Hot deploy module/server restart, throws IllegalArgumentException if > application deployed using hotdeployment > - > > Key: GERONIMO-2584 > URL: http://issues.apache.org/jira/browse/GERONIMO-2584 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Hot Deploy Dir >Affects Versions: 1.2 > Environment: Windows XP, but should be valid for all platforms >Reporter: Rakesh Midha > Assigned To: Vamsavardhana Reddy > Fix For: 1.2, 2.0 > > Attachments: hotdepoystartup.patch > > > This is a problem similar to one reported in > https://issues.apache.org/jira/browse/GERONIMO-2402, the server restart or > hot-deploy module restart fails with followng error if in a previous run you > deployed an application using hot deployment. > The exception trace is : > 00:54:43,008 ERROR [DirectoryMonitor] Unable to scan file > C:\geronimo\geronimobu > ild\geronimo-tomcat-j2ee-1.2-SNAPSHOT\deploy\sampleHello during initialization > java.lang.IllegalArgumentException: Invalid id: sampleHello > at > org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:4 > 9) > at > org.apache.geronimo.deployment.hot.DirectoryHotDeployer.getDeployment > Time(DirectoryHotDeployer.java:216) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct > oryMonitor.java:233) > at > org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni > tor.java:206) > at java.lang.Thread.run(Thread.java:534) > 00:54:47,014 INFO [DirectoryHotDeployer] Deploying sampleHello > 00:54:51,350 WARN [TomcatModuleBuilder] Web application . does not contain a > WE > B-INF/geronimo-web.xml deployment plan. This may or may not be a problem, > depen > ding on whether you have things like resource references that need to be > resolve > d. You can also give the deployer a separate deployment plan file on the > comman > d line. > 00:54:51,841 ERROR [GBeanInstance] Problem in doFail of > default/sampleHello/1163 > 964291070/war?J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 > 163964291070/war > java.lang.RuntimeException: java.lang.NullPointerException > at > org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContai > ner.java:339) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b07 > 3.invoke() > ... 31 more > 00:54:51,841 ERROR [GBeanInstanceState] Error while starting; GBean is now in > th > e FAILED state: > abstractName="default/sampleHello/1163964291070/war?J2EEApplicat > ion=null,j2eeType=WebModule,name=default/sampleHello/1163964291070/war" > java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is > not > unique > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase > .java:749) > Caused by: org.apache.geronimo.gbean.InvalidConfigurationException: > Configuratio > n default/sampleHello/1163964291070/war failed to start due to the following > rea > sons: > The service > J2EEApplication=null,j2eeType=WebModule,name=default/sampleHello/1 > 163964291070/war did not start because the doStart method threw an exception. > java.lang.IllegalArgumentException: addChild: Child name '/sampleHello' is > not > unique > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase > .java:749) > Steps to recreate: > 1. Start server > 2. Deploy sample application, by placing sampleApp folder in deploy directory > 3. Application will be deployed and runs fine. > 4. Restart server, or restart hot-deploy module > 5. The above mentioned exception is thrown. -- 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-2402) Redeployment fails after third iteration.
[ http://issues.apache.org/jira/browse/GERONIMO-2402?page=all ] Vamsavardhana Reddy updated GERONIMO-2402: -- Fix Version/s: 2.0-M1 Assignee: Vamsavardhana Reddy > Redeployment fails after third iteration. > - > > Key: GERONIMO-2402 > URL: http://issues.apache.org/jira/browse/GERONIMO-2402 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.1, 1.1.1 > Environment: JDK 1.4.2_08, Windows/XP Pro, Version 2002 SP/2 >Reporter: Fran Varin > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 2.0-M1 > > Attachments: hotdeployupdate.patch > > > Here is a modified copy of the test case that reproduces the bug. In its > original state there were some screen shots included for clarity sake. > However, it is not possible to include those here. The applicaiton that was > used in concert with this test case was an extremely simply project that just > included one JSP. There was no "geronimo-web.xml" used in the project and it > was deployed in "exploded" form. > Step 1 - Launch Geronimo > ? For this test I used the 1.1.1-RC3 Version. > ? I am pointing to Java SE v1.4.2_08 > ? The standard startup.bat was used to start the server with no > modification. > ? The application does not contain a "Geronimo-web.xml" descriptor. > ? Below are all of the message on the console after the Geronimo started. > Note that the application was deployed > Booting Geronimo Kernel (in Java 1.4.1_02)... > Module 1/20 geronimo/rmi-naming/1.1.1-rc3/car started in .265s > Module 2/20 geronimo/j2ee-server/1.1.1-rc3/car started in .563s > Module 3/20 geronimo/j2ee-security/1.1.1-rc3/car started in .547s > Module 4/20 geronimo/axis/1.1.1-rc3/carstarted in .078s > Module 5/20 geronimo/openejb/1.1.1-rc3/car started in .313s > Module 6/20 geronimo/system-database/1.1.1-rc3/car started in 1.750s > Module 7/20 geronimo/activemq-broker/1.1.1-rc3/car started in 1.188s > Module 8/20 geronimo/activemq/1.1.1-rc3/carstarted in .390s > Module 9/20 geronimo/tomcat/1.1.1-rc3/car started in 2.015s > Module 10/20 geronimo/geronimo-gbean-deployer/1.1.1-rc3/car started in .297s > Module 11/20 geronimo/j2ee-deployer/1.1.1-rc3/car started in .234s > Module 12/20 geronimo/openejb-deployer/1.1.1-rc3/carstarted in .266s > Module 13/20 geronimo/client-deployer/1.1.1-rc3/car started in .047s > Module 14/20 geronimo/axis-deployer/1.1.1-rc3/car started in .078s > Module 15/20 geronimo/sharedlib/1.1.1-rc3/car started in .016s > Module 16/20 geronimo/tomcat-deployer/1.1.1-rc3/car started in .093s > Module 17/20 geronimo/welcome-tomcat/1.1.1-rc3/car started in .266s > Module 18/20 geronimo/webconsole-tomcat/1.1.1-rc3/car started in 4.297s > Module 19/20 geronimo/remote-deploy-tomcat/1.1.1-rc3/carstarted in .234s > Module 20/20 geronimo/hot-deployer/1.1.1-rc3/carstarted in .343s > Startup completed in 16 seconds > Listening on Ports: > 1099 0.0.0.0 RMI Naming > 1527 0.0.0.0 Derby Connector > 4201 0.0.0.0 ActiveIO Connector EJB > 4242 0.0.0.0 Remote Login Listener > 8009 0.0.0.0 Tomcat Connector AJP > 8080 0.0.0.0 Tomcat Connector HTTP > 8443 0.0.0.0 Tomcat Connector HTTPS > 0.0.0.0 JMX Remoting Connector >61616 0.0.0.0 ActiveMQ Message Broker Connector > Started Application Modules: > EAR: geronimo/webconsole-tomcat/1.1.1-rc3/car > RAR: geronimo/activemq/1.1.1-rc3/car > WAR: geronimo/remote-deploy-tomcat/1.1.1-rc3/car > WAR: geronimo/welcome-tomcat/1.1.1-rc3/car > Web Applications: > http://RI150WS311:8080/ > http://RI150WS311:8080/console > http://RI150WS311:8080/console-standard > http://RI150WS311:8080/remote-deploy > Geronimo Application Server started > 11:15:15,111 INFO [Hot Deployer] Deploying Test.war > 11:15:15,423 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. > Deployed default/Test/1158074115142/war @ > http://RI150WS311:8080/Test > Examine the "deploy" directory. Note that it contains the application as > deployed. > Examine the "repository\default" directory. Note that it contains what I > refer to as the actually running deployed application. > If I were to expand this folder I would find that the WAR
[jira] Assigned: (GERONIMO-2555) Windows scripts don't work when used from different drive
[ http://issues.apache.org/jira/browse/GERONIMO-2555?page=all ] Dain Sundstrom reassigned GERONIMO-2555: Assignee: Dain Sundstrom > Windows scripts don't work when used from different drive > - > > Key: GERONIMO-2555 > URL: http://issues.apache.org/jira/browse/GERONIMO-2555 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: general >Affects Versions: 1.2, 1.1.2 > Environment: Windows XP >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.1.2, 1.2, 2.0 > > Attachments: GERONIMO-2555.patch > > > If the scripts: geronimo.bat, startup.bat, shutdown.bat, deploy.bat are > launched from a drive other than the one Geronimo is located the "cd" > portions do not work when trying to determine the script location. > In order for a cross drive CD to work, the /d option must be used. -- 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-1135) Keystore password in System.properties
[ http://issues.apache.org/jira/browse/GERONIMO-1135?page=all ] Vamsavardhana Reddy closed GERONIMO-1135. - Resolution: Fixed Removing the keystore related system properties did not seem to break anything. Removed "SystemProperties" GBean definition altogether from the plan since there are no properties to set. Fixed in rev 483612. > Keystore password in System.properties > -- > > Key: GERONIMO-1135 > URL: http://issues.apache.org/jira/browse/GERONIMO-1135 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.0-M5 >Reporter: Aaron Mulder > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 2.0-M1 > > > If you look at the System properties, the keystore and trust store passwords > are in there. I'm not sure who puts them in there, but we need to find a way > to stop that -- or else prevent applications from reading them? -- 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] Assigned: (GERONIMO-2551) Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR artifact maven-metadata doesn't exist
[ http://issues.apache.org/jira/browse/GERONIMO-2551?page=all ] Dain Sundstrom reassigned GERONIMO-2551: Assignee: Dain Sundstrom > Plugin hits NPE if maven-metadata listed artifact doesn't exist or JAR > artifact maven-metadata doesn't exist > > > Key: GERONIMO-2551 > URL: http://issues.apache.org/jira/browse/GERONIMO-2551 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.1.1, 1.1.x, 1.2 >Reporter: Donald Woods > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: G2551-1.1.1.patch > > > 1) If an artifact version listed in a repos maven-metadata.xml doesn't exist, > then the PluginInstallerGBean code takes a NPE. > 2) If a maven-metadat.xml doesn't exist for a dependent JAR file artifact the > selected repo, then the PluginInstallerGBean code takes a NPE. -- 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] Assigned: (GERONIMO-2549) NullPointerException: CommandListConfigurations
[ http://issues.apache.org/jira/browse/GERONIMO-2549?page=all ] Dain Sundstrom reassigned GERONIMO-2549: Assignee: Dain Sundstrom > NullPointerException: CommandListConfigurations > --- > > Key: GERONIMO-2549 > URL: http://issues.apache.org/jira/browse/GERONIMO-2549 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Plugins >Affects Versions: 1.2 > Environment: windows xp >Reporter: Mark DeLaFranier > Assigned To: Dain Sundstrom > Fix For: 1.2, 2.0 > > Attachments: GERONIMO-2549.patch > > > > deploy.bat search-plugins http://bogus-server/maven2 > Using GERONIMO_BASE: D:\geronimo\1.2 > Using GERONIMO_HOME: D:\geronimo\1.2 > Using GERONIMO_TMPDIR: D:\geronimo\1.2\var\temp > Using JRE_HOME:d:\dev\jdk142 > Username: system > Password: *** > Exception in thread "main" java.lang.NullPointerException > at > org.apache.geronimo.deployment.cli.CommandListConfigurations.execute(CommandListConfigurations.java:84) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:160) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:314) -- 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-1135) Keystore password in System.properties
[ http://issues.apache.org/jira/browse/GERONIMO-1135?page=all ] Vamsavardhana Reddy updated GERONIMO-1135: -- Fix Version/s: 2.0-M1 Assignee: Vamsavardhana Reddy > Keystore password in System.properties > -- > > Key: GERONIMO-1135 > URL: http://issues.apache.org/jira/browse/GERONIMO-1135 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.0-M5 >Reporter: Aaron Mulder > Assigned To: Vamsavardhana Reddy >Priority: Critical > Fix For: 1.2, 2.0-M1 > > > If you look at the System properties, the keystore and trust store passwords > are in there. I'm not sure who puts them in there, but we need to find a way > to stop that -- or else prevent applications from reading them? -- 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: Milestone versions in JIRA for G2.0
haha, nevermind, looks like Matt did this yesterday :) On Dec 7, 2006, at 1:58 PM, anita kulshreshtha wrote: +1 Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: Since we're breaking our 2.0 release into milestones, it seems appropriate for us to create some versions in JIRA for them so features and defects can be targeted to them. (ex. 2.0-M1, 2.0- M2...). If there aren't any objections, I'll go ahead and create them. -sachin __ __ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. -sachin
[jira] Updated: (GERONIMO-2493) Integrate Axis2 webservices
[ http://issues.apache.org/jira/browse/GERONIMO-2493?page=all ] Dain Sundstrom updated GERONIMO-2493: - Fix Version/s: (was: 1.2) Axis 2 will be integrated in 2.0 not 1.2 > Integrate Axis2 webservices > --- > > Key: GERONIMO-2493 > URL: http://issues.apache.org/jira/browse/GERONIMO-2493 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 1.2 >Reporter: David Jencks > Fix For: 2.0 > > > Integrate axis 2 for webservices. Probably at least 3 steps > - pojo ws > - ejb ws > - ws client -- 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: 1.2 Beta Tasks
On Dec 7, 2006, at 10:32 AM, Dain Sundstrom wrote: We have an exception being thrown in shutdown from GBeanBinding.removeBinding():159 and I'll fix that today. Looks like someone already fixed that :) -dain
[jira] Updated: (GERONIMO-2411) Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts
[ http://issues.apache.org/jira/browse/GERONIMO-2411?page=all ] Dain Sundstrom updated GERONIMO-2411: - Summary: Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts (was: CAR, WAR and EAR artifacts are missing NOTICE and LICENSE files.) Issue Type: Task (was: Bug) Assignee: Dain Sundstrom Priority: Blocker (was: Major) > Add NOTICE and LICENSE files to CAR, WAR and EAR artifacts > -- > > Key: GERONIMO-2411 > URL: http://issues.apache.org/jira/browse/GERONIMO-2411 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.0, 1.2, 1.x, 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: Matt Hogstrom > Assigned To: Dain Sundstrom >Priority: Blocker > Fix For: 2.0, 1.2 > > > For release of these artifacts they need to include the LICENSE and NOTICE > files. Currently the build does not automatically include them. The M2 > build needs to be updated to include these artifacts in the build process. -- 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-2559) cannot stop activemq via kernel shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-2559?page=all ] Dain Sundstrom closed GERONIMO-2559. Resolution: Fixed This was fixed some where in 1.2 :) > cannot stop activemq via kernel shutdown > > > Key: GERONIMO-2559 > URL: http://issues.apache.org/jira/browse/GERONIMO-2559 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 1.2 > Environment: sun j2se 1.5.0_07 >Reporter: Paul McMahan > Fix For: 1.2, 2.0 > > > Shutdown the server from the admin console. This ends up invoking > kernel.shutdown(). The following stack trace is generated: > 11:59:25,265 ERROR [JournalPersistenceAdapter] Could not stop service: > org.apach > [EMAIL PROTECTED] Reason: java.lang.Nul > lPointerException > java.lang.NullPointerException > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > rackingCoordinator.handleReleased(ConnectionTrackingCoordinator.java:127) > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > rackingCoordinator$$FastClassByCGLIB$$5d33aabf.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethod > Invoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperatio > n.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. > java:820) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 > 7) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat > ionInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro > xyMethodInterceptor.java:97) > at > org.apache.geronimo.connector.outbound.connectiontracking.ConnectionT > racker$$EnhancerByCGLIB$$c20afa50.handleReleased() > at > org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor. > returnConnection(ConnectionTrackingInterceptor.java:81) > at > org.apache.geronimo.connector.outbound.GeronimoConnectionEventListene > r.connectionClosed(GeronimoConnectionEventListener.java:67) > at > org.tranql.connector.AbstractManagedConnection.connectionClosed(Abstr > actManagedConnection.java:102) > at > org.tranql.connector.jdbc.ConnectionHandle.close(ConnectionHandle.jav > a:97) > at > org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultData > baseLocker.java:81) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersis > tenceAdapter.java:202) > at > org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(Jour > nalPersistenceAdapter.java:254) > at > org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) > at > org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) > at > org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerService > GBeanImpl.java:107) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBean > Instance.java:1146) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop( > GBeanInstanceState.java:337) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:188) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstan > ceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.ja > va:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.ja > va:423) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$Shutdown > Hook.run(KernelConfigurationManager.java:310) > at > org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(Basi > cKernel.java:668) > at > org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.jav > a:645) > at > org.apache.geronimo.console.servermanager.ServerManagerPortlet.doView > (ServerManagerPortlet.java:72) > at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247) > at javax.portlet.GenericPortlet.render(GenericPortlet.java:175) > at > org.
[jira] Commented: (GERONIMO-2439) add secure transport support to POP3 (i.e., SSL)
[ http://issues.apache.org/jira/browse/GERONIMO-2439?page=comments#action_12456540 ] Rick McGuire commented on GERONIMO-2439: Jason, there are a couple of problems here that need to be fixed: 1) Comments in the POP3 files still refer to smtp and smtps. This really should be cleaned up (nit picking here). 2) The default port for POP3Store and POP3SSLStore are different. This really needs to be handled the way SMTPTransport/SMTPSTransport do it, with the default port value specified on the constructor. Just attach a new patch when you have these things fixed. > add secure transport support to POP3 (i.e., SSL) > > > Key: GERONIMO-2439 > URL: http://issues.apache.org/jira/browse/GERONIMO-2439 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: mail >Reporter: Jason Warner > Assigned To: Rick McGuire >Priority: Minor > Attachments: POP3SSLConnection.patch > > > SSL authentication added to POP3 -- 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: svn commit: r483201 [1/2] - in /geronimo/server/trunk: applications/console/geronimo-console-framework/ applications/console/geronimo-console-standard/ applications/demo/ applications/geronimo-ca-
My understanding is that this will be done so that Geronimo can support more than one version of a third party artifact within a particular build tree, a la GERONIMO-2399. BTW, I'm holding off making any changes to the tomcat artifcatIds in trunk until this discussion winds down :-) Best wishes, Paul On 12/7/06, Joe Bohn <[EMAIL PROTECTED]> wrote: It seems like this will make upgrading to newer versions of projects more difficult. As the major version changes there will be changes that percolate across the geronimo modules, configs, assemblies, etc... It's not impossible to maintain by any means, but it is a little more difficult and error prone. We've already seen a little of this with jetty6 (initial jetty6 image including both jetty 5 & jetty 6 items, testsuite changes, etc...). Can you please summarize the rationale for this again and the benefits to be gained? Thanks, Joe David Jencks wrote: > I'm not sure who I've talked to about this or where but I think really > really strongly that we should include the major version number of the > projects we integrate in our artifactIds relating to those external > projects. > > A couple people have pointed out that something like jetty_6 or > geronimo-jetty6-builder is more consistent with our spec naming than > jetty6 or geronimo-jetty6-naming. > I don't really care about that, although I think the shorter tomcat6 is > perfectly clear and easier to type. > > Other stuff: > axis >> axis1 > cxf >> cxf1 > openjpa >> openjpa1 > > I think this will really reduce confusion about what is running in a > server. > > So, I'd like the tomcat modules to be renamed geronimo-tomcat6, > geronimo-tomcat6-builder, tomcat6, tomcat6-deployer. > > Can we discuss and settle this soon? > > thanks > david jencks > > > ps. I'm planning to remove the jetty[5] stuff from trunk soon.
[jira] Closed: (GERONIMO-1574) Spring integration with Geronimo Transaction Manager
[ http://issues.apache.org/jira/browse/GERONIMO-1574?page=all ] David Jencks closed GERONIMO-1574. -- Resolution: Won't Fix After the tx refactoring and global jndi, you should be able to access the geronimo tx manager in spring using the normal spring components. > Spring integration with Geronimo Transaction Manager > > > Key: GERONIMO-1574 > URL: http://issues.apache.org/jira/browse/GERONIMO-1574 > Project: Geronimo > Issue Type: New Feature > Security Level: public(Regular issues) > Components: transaction manager >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: Wish List > > > For a reasonable spring integration, we need to expose some of our components > wrapped in spring interfaces. The most obvious is the transaction manager. -- 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: Milestone versions in JIRA for G2.0
+1 Anita --- Sachin Patel <[EMAIL PROTECTED]> wrote: > Since we're breaking our 2.0 release into milestones, it seems > appropriate for us to create some versions in JIRA for them so > features and defects can be targeted to them. (ex. 2.0-M1, 2.0- > M2...). If there aren't any objections, I'll go ahead and create > them. > > -sachin > > > Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now.
[jira] Updated: (GERONIMO-1470) Our context root settings should take precedence over those from application.xml
[ http://issues.apache.org/jira/browse/GERONIMO-1470?page=all ] David Jencks updated GERONIMO-1470: --- Fix Version/s: 2.0 (was: 1.2) > Our context root settings should take precedence over those from > application.xml > > > Key: GERONIMO-1470 > URL: http://issues.apache.org/jira/browse/GERONIMO-1470 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0 > > > Someone on IRC pointed out that the context-root setting in application.xml > is an assembly-time setting and should be overridden by the deploy-time > setting in our web plans. At the moment the application.xml setting > overrides the web plan setting. This is a trivial change, but I want to make > sure there are no objections to it. -- 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] Assigned: (GERONIMO-1461) Unify virtual host settings for Tomcat & Jetty into generic web plan
[ http://issues.apache.org/jira/browse/GERONIMO-1461?page=all ] David Jencks reassigned GERONIMO-1461: -- Assignee: (was: David Jencks) I don't think it's practical to do this. > Unify virtual host settings for Tomcat & Jetty into generic web plan > > > Key: GERONIMO-1461 > URL: http://issues.apache.org/jira/browse/GERONIMO-1461 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: web >Affects Versions: 1.0 >Reporter: Aaron Mulder > Fix For: Wish List > > > The geronimo-web-1.0.xsd schema should include a 0-N element for virtual host > name, which both Tomcat and Jetty should use. Then the container-specific > virtual host settings can be removed from the Tomcat and Jetty specific > config formats, and replaced with the portable setting in the Tomcat and > Jetty specific plan formats. -- 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-1460) Tomcat web plan should take multiple hosts, create HostGBeans as necessary
[ http://issues.apache.org/jira/browse/GERONIMO-1460?page=all ] David Jencks updated GERONIMO-1460: --- Fix Version/s: Wish List (was: 1.2) Assignee: (was: David Jencks) I don't think this is practical to do and I don't think I'll have time to think about it in the forseeable future. > Tomcat web plan should take multiple hosts, create HostGBeans as necessary > -- > > Key: GERONIMO-1460 > URL: http://issues.apache.org/jira/browse/GERONIMO-1460 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Tomcat, web >Affects Versions: 1.0 >Reporter: Aaron Mulder > Fix For: Wish List > > > The Tomcat web plan should take multiple elements, and for each one: > - if a HostGBean is present, associate to that > - if a HostGBean is not present, create a default one and start it, and then > associate to that -- 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-383) xmlbeans magic allows us to accept some invalid deployment descriptors
[ http://issues.apache.org/jira/browse/GERONIMO-383?page=all ] David Jencks updated GERONIMO-383: -- Fix Version/s: Wish List (was: 1.x) Assignee: (was: David Jencks) I doubt I will have time to look into this in the forseeable future. > xmlbeans magic allows us to accept some invalid deployment descriptors > -- > > Key: GERONIMO-383 > URL: http://issues.apache.org/jira/browse/GERONIMO-383 > Project: Geronimo > Issue Type: Bug > Components: deployment >Affects Versions: 1.0-M2 >Reporter: David Jencks > Fix For: Wish List > > > The element reordering and other xmlbeans magic we do to convert pre-1.4 > deployment descriptors to 1.4 versions can have the unintended side effect of > converting invalid 1.4 descriptors to valid ones. This has been fixed in > SchemaConversionUtils.convertToServletSchema for servlet 1.3 web.xml. We > should apply this same fix of checking for namespace before conversion to > other modules (ejb etc) and extend the checking to: > 1. look for the DOCTYPE using xmlbeans > 2. converting to a made-up namespace for that dtd > 3. validating against xmlbeans objects for the schema corresponding to the > dtd. -- 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-268) Connection Error handling problems
[ http://issues.apache.org/jira/browse/GERONIMO-268?page=all ] David Jencks updated GERONIMO-268: -- Fix Version/s: 2.0 (was: 1.x) > Connection Error handling problems > -- > > Key: GERONIMO-268 > URL: http://issues.apache.org/jira/browse/GERONIMO-268 > Project: Geronimo > Issue Type: Bug > Components: connector >Affects Versions: 1.0-M2 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 2.0 > > > A managed connection that encounters a fatal error and calls > ConnectionErrorOccured on the GeronimoConnectionEventListener may not have > the resources held by geronimo cleaned up properly. > In particular, if several ejbs have handles to this mc, the connection > tracking won't work properly. Only the currently active component (ejb) will > have it's handle(s) removed from tracking. When the other handles are > disociated or closed, errors are likely, such as putting the destroyed > managed connection back into the pool. -- 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-250) Connector tries to commit after connection error
[ http://issues.apache.org/jira/browse/GERONIMO-250?page=all ] David Jencks updated GERONIMO-250: -- Fix Version/s: 2.0 (was: 1.x) > Connector tries to commit after connection error > > > Key: GERONIMO-250 > URL: http://issues.apache.org/jira/browse/GERONIMO-250 > Project: Geronimo > Issue Type: Bug > Components: connector >Affects Versions: 1.0-M2 >Reporter: Simon Godik > Assigned To: David Jencks > Fix For: 2.0 > > > If a resource adapter indicates a connection has had a fatal error, then the > connection manager destroys the managed connection but still attempts to > commit/rollback at transaction end. This is bad as the connection has already > been destroyed. -- 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-434) Connection factories extracted from conceptually wrong gbean
[ http://issues.apache.org/jira/browse/GERONIMO-434?page=all ] David Jencks updated GERONIMO-434: -- Fix Version/s: Wish List (was: 1.x) > Connection factories extracted from conceptually wrong gbean > > > Key: GERONIMO-434 > URL: http://issues.apache.org/jira/browse/GERONIMO-434 > Project: Geronimo > Issue Type: Improvement > Components: connector >Affects Versions: 1.0-M4 >Reporter: David Jencks > Assigned To: David Jencks > Fix For: Wish List > > > Currently connection factories/datasources (or their proxies) are obtained > from the JCAManagedConnectionFactory gbean. Since there is a > ConnectionFactory/Datasource gbean for the jsr-77 requirements, it would make > more sense to obtain the connection factory/datasource from there. This > would have the additional feature of allowing one to set up several > connection factories under different names that all use the same > ConnectionManager and ManagedConnectionFactory. This would for instance let > you set up separately named QueueConnectionFactory and TopicConnectionFactory > that share the same connections: named appropriately, this can let you leave > out resource-refs in plans for apps that call the factories different names. -- 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-1917) repository doesn't deal well with case insensitive file systems
[ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ] Dain Sundstrom updated GERONIMO-1917: - Fix Version/s: 2.0 (was: 1.2) This will not be fixed in 1.2 > repository doesn't deal well with case insensitive file systems > --- > > Key: GERONIMO-1917 > URL: http://issues.apache.org/jira/browse/GERONIMO-1917 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: David Jencks > Fix For: 1.1.2, 2.0 > > > If you've installed a configuration A/B/1/car and then look for a/b/1/car, > the repository will claim it's there on a case insensitive file system, but > then further logic in the config store/ manager blows up because those are > different artifacts. Solution appears to be to check when locating an > artifact that the case from the file system matches the case you are asking > for. -- 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
