Re: Pre processing of messages at runtime
The only way currently is to register a MessageListener (package org.apache.servicemix.event) on the JBIContainer. It will intercept all exchanges, so you would have to filter those of interest for you. What's your use case ? On 12/6/06, shravan [EMAIL PROTECTED] wrote: Does servicemix offer a way to pre process a MessageExchange received by an end point before the message is acted upon by a service unit? -- View this message in context: http://www.nabble.com/Pre-processing-of-messages-at-runtime-tf2767144s12049.html#a7716583 Sent from the ServiceMix - Dev mailing list archive at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Commented: (GERONIMO-646) Servlet calling HttpServletRequest.isUserInRole(null) causes NPE using Jetty container
[
http://issues.apache.org/jira/browse/GERONIMO-646?page=comments#action_12455911
]
Vamsavardhana Reddy commented on GERONIMO-646:
--
As of rev 482955 in branches\1.2
JAASJettyRealm.java
public boolean isUserInRole(Principal user, String role) { return
internalJAASJettyRealm.isUserInRole(user, role); }
InternalJAASJettyRealm.java
public boolean isUserInRole(Principal user, String role) {
if (user == null || role == null) { return false; }
...
}
JAASJettyRealm seems to have been fixed. Do we need to fix
WebRoleRefPermission too?
Servlet calling HttpServletRequest.isUserInRole(null) causes NPE using Jetty
container
--
Key: GERONIMO-646
URL: http://issues.apache.org/jira/browse/GERONIMO-646
Project: Geronimo
Issue Type: Bug
Components: web
Affects Versions: 1.0-M4
Environment: All
Reporter: Tom McQueeney
Assigned To: Alan Cabrera
Priority: Minor
Fix For: 1.2
Attachments: JAASJettyRealm-patch.txt,
WebRoleRefPermission-patch.txt, WebRoleRefPermissionTest-patch.txt
The servlet isUserInRole call eventually gets delegated to
org.apache.geronimo.jetty.JAASJettyRealm.isUserInRole, which causes a NPE in
javax.security.jacc.WebRoleRefPermission.hashCode().
JAASJettyRealm.isUserInRole creates a WebRoleRefPermission, passing it the
null role that it was passed, then delegates the role check to
java.security.AccessControlContext.checkPermission, passing it the
WebRoleRefPermission.
When the web role ref permission gets checked, eventually its hashcode method
is called,
which tries to compute the hash by getting the hashcode of the (null) role
name,
which throws the 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-1652) EJBModuleImpl.getEJBs() always return an empty array
[ http://issues.apache.org/jira/browse/GERONIMO-1652?page=all ] Christopher M. Cardona closed GERONIMO-1652. Resolution: Fixed EJBModuleImpl.getEJBs() always return an empty array Key: GERONIMO-1652 URL: http://issues.apache.org/jira/browse/GERONIMO-1652 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core, OpenEJB Affects Versions: 1.2 Reporter: Christopher M. Cardona Attachments: EJBModuleImpl.java Calling EJBModuleImpl.getEJBs() always returns an empty String[] because of a wrong generated query. Here is an example query: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=null,j2eeType=EntityBean,* The correct query should have been: geronimo.server:J2EEServer=geronimo,J2EEApplication=geronimo/daytrader-derby-tomcat/1.1-SNAPSHOT/car,EJBModule=daytrader-ejb-1.1-SNAPSHOT.jar,j2eeType=EntityBean,* -- 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
Unable to build jetty6 jee5 assembly
Hi, I am trying to build jetty6 assembly but it fails in modules-jetty6. [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mortbay.jetty -DartifactId=jetty \ -Dversion=6.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty6:jar:2.0-SNAPSHOT 2) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT I am not able to find jetty jar for 6.1-SNAPSHOT in the repos. Regards Krish
Re: Unable to build jetty6 jee5 assembly
Should jetty source be downloaded and built to get this jar. I tried jetty-6.1.0pre0.jar but it gives compilation errors during build of geronimo-jetty6 module. Regards Krish On 12/6/06, Krishnakumar B [EMAIL PROTECTED] wrote: Hi, I am trying to build jetty6 assembly but it fails in modules-jetty6. [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mortbay.jetty -DartifactId=jetty \ -Dversion=6.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty6:jar:2.0-SNAPSHOT 2) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT I am not able to find jetty jar for 6.1-SNAPSHOT in the repos. Regards Krish
Re: Unable to build jetty6 jee5 assembly
it's supposed to be at the codehaus snapshot repo, and I have found it there in the past. might be a temporary glitch david jencks On Dec 6, 2006, at 1:10 AM, Krishnakumar B wrote: Hi, I am trying to build jetty6 assembly but it fails in modules-jetty6. [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. Missing: -- 1) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mortbay.jetty - DartifactId=jetty \ -Dversion=6.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty6:jar:2.0-SNAPSHOT 2) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT I am not able to find jetty jar for 6.1-SNAPSHOT in the repos. Regards Krish
Pre processing of messages at runtime
Does servicemix offer a way to pre process a MessageExchange received by an end point before the message is acted upon by a service unit? -- View this message in context: http://www.nabble.com/Pre-processing-of-messages-at-runtime-tf2767144s12049.html#a7716583 Sent from the ServiceMix - Dev mailing list archive at Nabble.com.
[jira] Updated: (GERONIMO-2221) java.lang.ClassCastException while installing Servlet Examples
[ http://issues.apache.org/jira/browse/GERONIMO-2221?page=all ]
Gianny Damour updated GERONIMO-2221:
Summary: java.lang.ClassCastException while installing Servlet Examples
(was: java.lang.ClassCastException while installing Servlet Examples because
of Checksum file not found)
Component/s: (was: sample apps)
Description:
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
{code}
It happens on Jetty, too.
The config.ser file of this example contains a raw GBeanInfo instead of a
ConfigurationData wrapping a GBeanInfo. It seems to me that the car file format
of this example is incorrect. I will investigate further a potential root cause.
was:
http://localhost:8080/ - Servlet Examples - click here (i.e.
http://localhost:8080/servlets-examples/?install=true) -
{code}
# Installed configuration
# id = geronimo/servlets-examples-tomcat/1.0/car
# location =
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car
10:57:46,031 WARN [ConfigurationStoreUtil] Checksum file not found:
C:\geronimo-1.2-SNAPSHOT\repository\geronimo\servlets-examples-tomcat\1.0\servlets-examples-tomcat-1.0.car\META
-INF\config.ser.sha1
10:57:46,046 ERROR [[servlet_sample_installer]] Servlet.service() for servlet
servlet_sample_installer threw exception
java.lang.ClassCastException
at
org.apache.geronimo.kernel.config.SerializedConfigurationMarshaler.readConfigurationData(SerializedConfigurationMarshaler.java:57)
at
org.apache.geronimo.kernel.config.ConfigurationUtil.readConfigurationData(ConfigurationUtil.java:167)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore.loadConfiguration(RepositoryConfigurationStore.java:113)
at
org.apache.geronimo.system.configuration.RepositoryConfigurationStore$$FastClassByCGLIB$$968bf00c.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.kernel.config.ConfigurationStore$$EnhancerByCGLIB$$a45644d1.loadConfiguration(generated)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.downloadArtifact(PluginInstallerGBean.java:738)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:454)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:383)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCGLIB$$cebc327e.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
[jira] Resolved: (AMQ-1089) Warning when using multicast discoveryUri
[ https://issues.apache.org/activemq/browse/AMQ-1089?page=all ]
Jonas Lim resolved AMQ-1089.
Fix Version/s: 4.2.0
Resolution: Fixed
i believe this has already been resolved in the 4.2 trunk (r464216)
Warning when using multicast discoveryUri
--
Key: AMQ-1089
URL: https://issues.apache.org/activemq/browse/AMQ-1089
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0.1, 4.0.2
Environment: reproduced on Windows XP Pro and SuSE Linux Enterprise
9.1
Reporter: Olaf Brandt
Priority: Minor
Fix For: 4.2.0
When using a transportconnector with a multicast discoveryagent a warning is
shown.
config: transportConnector name=default uri=tcp://localhost:61616
discoveryUri=multicast://default/
WARN MulticastDiscoveryAgent -brokerName not set
This warning is generated by the MulticastDiscoveryAgent.start() method.
When the transportconnector is started the MulticastDiscoveryAgent is created
if it does not exist,
but the brokerName for this MulticastDiscoveryAgent is not set by the
transportconnector.
See the code and the suggested modification to prevent this warning:
org.apache.activemq.broker.TransportConnector.java
snip
public void start() throws Exception {
getServer().start();
DiscoveryAgent da = getDiscoveryAgent();
if( da!=null ) {
da.registerService(getConnectUri().toString());
//suggested modification start
if(da.getBrokerName() == null || da.getBrokerName().length == 0) {
da.setBrokerName(this.getBroker().getBrokerName());
}
//suggested modification end
da.start();
}
this.statusDector.start();
log.info(Connector +getName()+ Started);
}
snap
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=comments#action_12455960 ] David Jencks commented on GERONIMO-2583: I played around with this a bit and think we can solve it another way by moving the geronimo-deploy-tool dependency to hot-deployer and removing geronimo-deploy-tool and geronimo-deploy-config from geronimo-gbean-deployer. Deploy from the console and hot deploy appear to work with this, I still have to check that jsr88 and the online and offline deployers still work. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Assigned To: David Jencks Priority: Blocker Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- 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: (AMQ-1089) Warning when using multicast discoveryUri
[ https://issues.apache.org/activemq/browse/AMQ-1089?page=all ]
Jonas Lim updated AMQ-1089:
---
Fix Version/s: 4.1.1
4.1.2
Description:
When using a transportconnector with a multicast discoveryagent a warning is
shown.
config: transportConnector name=default uri=tcp://localhost:61616
discoveryUri=multicast://default/
WARN MulticastDiscoveryAgent -brokerName not set
When the transportconnector is started the MulticastDiscoveryAgent is created
if it does not exist,
but the brokerName for this MulticastDiscoveryAgent is not set by the
transportconnector.
See the code and the suggested modification to prevent this warning:
org.apache.activemq.broker.TransportConnector.java
snip
public void start() throws Exception {
getServer().start();
DiscoveryAgent da = getDiscoveryAgent();
if( da!=null ) {
da.registerService(getConnectUri().toString());
//suggested modification start
if(da.getBrokerName() == null || da.getBrokerName().length == 0) {
da.setBrokerName(this.getBroker().getBrokerName());
}
//suggested modification end
da.start();
}
this.statusDector.start();
log.info(Connector +getName()+ Started);
}
snap
was:
When using a transportconnector with a multicast discoveryagent a warning is
shown.
config: transportConnector name=default uri=tcp://localhost:61616
discoveryUri=multicast://default/
WARN MulticastDiscoveryAgent -brokerName not set
This warning is generated by the MulticastDiscoveryAgent.start() method.
When the transportconnector is started the MulticastDiscoveryAgent is created
if it does not exist,
but the brokerName for this MulticastDiscoveryAgent is not set by the
transportconnector.
See the code and the suggested modification to prevent this warning:
org.apache.activemq.broker.TransportConnector.java
snip
public void start() throws Exception {
getServer().start();
DiscoveryAgent da = getDiscoveryAgent();
if( da!=null ) {
da.registerService(getConnectUri().toString());
//suggested modification start
if(da.getBrokerName() == null || da.getBrokerName().length == 0) {
da.setBrokerName(this.getBroker().getBrokerName());
}
//suggested modification end
da.start();
}
this.statusDector.start();
log.info(Connector +getName()+ Started);
}
snap
btw, this issue has also been resolved in the 4.1.0 release
Warning when using multicast discoveryUri
--
Key: AMQ-1089
URL: https://issues.apache.org/activemq/browse/AMQ-1089
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 4.0.1, 4.0.2
Environment: reproduced on Windows XP Pro and SuSE Linux Enterprise
9.1
Reporter: Olaf Brandt
Priority: Minor
Fix For: 4.2.0, 4.1.1, 4.1.2
When using a transportconnector with a multicast discoveryagent a warning is
shown.
config: transportConnector name=default uri=tcp://localhost:61616
discoveryUri=multicast://default/
WARN MulticastDiscoveryAgent -brokerName not set
When the transportconnector is started the MulticastDiscoveryAgent is created
if it does not exist,
but the brokerName for this MulticastDiscoveryAgent is not set by the
transportconnector.
See the code and the suggested modification to prevent this warning:
org.apache.activemq.broker.TransportConnector.java
snip
public void start() throws Exception {
getServer().start();
DiscoveryAgent da = getDiscoveryAgent();
if( da!=null ) {
da.registerService(getConnectUri().toString());
//suggested modification start
if(da.getBrokerName() == null || da.getBrokerName().length == 0) {
da.setBrokerName(this.getBroker().getBrokerName());
}
//suggested modification end
da.start();
}
this.statusDector.start();
log.info(Connector +getName()+ Started);
}
snap
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r483034 - /geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml
Do we need this fix in branches\1.2 too? --vamsi On 12/6/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: gdamour Date: Wed Dec 6 03:11:05 2006 New Revision: 483034 URL: http://svn.apache.org/viewvc?view=revrev=483034 Log: Update module id name templates to reflect m2 re-organization: CARs have now a group id set to org.apache.geronimo.configs. I believe this fixes GERONIMO-222 - java.lang.ClassCastException while installing Servlet Examples, however I cannot test it as these CARS are not deployed to one of the configured plugin repo and http://people.apache.org/repo/m2-snapshot-repository/ is not a valid plugin repository. Modified: geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml Modified: geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml?view=diffrev=483034r1=483033r2=483034 == --- geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml (original) +++ geronimo/server/trunk/applications/geronimo-welcome/src/main/webapp/WEB-INF/web.xml Wed Dec 6 03:11:05 2006 @@ -31,7 +31,7 @@ servlet-classorg.apache.geronimo.welcome.AbsentSampleServlet /servlet-class init-param param-namemoduleId/param-name -param-valuegeronimo/jsp-examples-SERVER//car/param-value +param-valueorg.apache.geronimo.configs /jsp-examples-SERVER//car/param-value /init-param /servlet @@ -40,7 +40,7 @@ servlet-classorg.apache.geronimo.welcome.AbsentSampleServlet /servlet-class init-param param-namemoduleId/param-name -param-valuegeronimo/servlets-examples-SERVER//car/param-value +param-valueorg.apache.geronimo.configs /servlets-examples-SERVER//car/param-value /init-param /servlet @@ -49,7 +49,7 @@ servlet-classorg.apache.geronimo.welcome.AbsentSampleServlet /servlet-class init-param param-namemoduleId/param-name -param-valuegeronimo/ldap-demo-SERVER//car/param-value +param-valueorg.apache.geronimo.configs /ldap-demo-SERVER//car/param-value /init-param /servlet
[jira] Commented: (GERONIMO-2583) java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor
[ http://issues.apache.org/jira/browse/GERONIMO-2583?page=comments#action_12455990 ] Rakesh Midha commented on GERONIMO-2583: I think this should also work fine, there are number of ways in which we can solve it, I think what we need to focus on is what dependencies confuses the classloader least.(reduce complexity) The criterion I was using is the one which requires least number of dependency changes. (I assumed current dependency graph is proved to be working fine and should not be changed a lot, following if it is working done change unless required ) May not the best policy all the time, but works for me :-) I hope we can find generic way to solve classloader and depenencies (for future). I need to think, so for now dont ask me what generic way i am talking about. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor --- Key: GERONIMO-2583 URL: http://issues.apache.org/jira/browse/GERONIMO-2583 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Hot Deploy Dir Affects Versions: 1.2 Environment: Windows Xp, should be valid for all platforms Reporter: Rakesh Midha Assigned To: David Jencks Priority: Blocker Fix For: 1.2 Attachments: dependencyonlyjsr88.patch, hotdeploygbean.patch Hello This issue was discussed before in http://www.mail-archive.com/dev@geronimo.apache.org/msg28048.html and I think the patch was provided as a part of M2 migration in http://issues.apache.org/jira/browse/GERONIMO-2067#action_12423814 (It says any other issue open new JIRA, so opening this one) I downloaded latest trunk, and tried to use hot-deployer. Every time I try to use hot-deployer I get exception. java.lang.NoClassDefFoundError: org/apache/geronimo/deployment/plugin/ConfigIDExtractor at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:537) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12 3) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.access$200( JarFileClassLoader.java:52) at org.apache.geronimo.kernel.classloader.JarFileClassLoader$6.run(JarFi leClassLoader.java:298) at java.security.AccessController.doPrivileged(Native Method) at org.apache.geronimo.kernel.classloader.JarFileClassLoader.findClass(J arFileClassLoader.java:250) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:292) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at org.apache.geronimo.kernel.config.MultiParentClassLoader.loadClass(Mu ltiParentClassLoader.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:235) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:141) at org.apache.geronimo.deployment.hot.DirectoryMonitor.class$(DirectoryM onitor.java:47) at org.apache.geronimo.deployment.hot.DirectoryMonitor.calculateModuleId (DirectoryMonitor.java:369) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(Direct oryMonitor.java:238) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMoni tor.java:214) at java.lang.Thread.run(Thread.java:534) The class is in geronimo-deploy-jsr88, and hot-deploy pom.xml already shows hot-deploy to be dependent on geronimo-deploy-jsr88, which means the above class should be available. -- 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-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Rakesh Midha updated GERONIMO-1285: --- Attachment: consoleprint1285.patch Patch consoleprint1285.patch prints the same for console. It prints started, stopped, uninstalled and installed module names in console. Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M5 Reporter: Aaron Mulder Assigned To: Rakesh Midha Priority: Critical Fix For: 2.0 Attachments: consoleprint1285.patch, deploytooloutput.patch When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- 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
exclusions tag in geronimo-connector\pom.xml
I see the following xml fragment in modules\geronimo-connector\pom.xml dependency groupIdorg.tranql/groupId artifactIdtranql/artifactId scopetest/scope exclusions exclusion groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /exclusion /exclusions /dependency Can someone tell me the use of this exclusions tag. If I comment out the exclusions part, I am able to build this module using IBMJDK1.5.0. Otherwise it is giving compilation errors like the following. C:\G1.2\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\o utbound\ManagedConnectionFactoryWrapper.java:[33,34] package org.apache.commons. logging does not exist Or are these compilation errors due to a problem in IBMJDK1.5.0?
[jira] Updated: (GERONIMO-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Rakesh Midha updated GERONIMO-1285: --- Assignee: (was: Rakesh Midha) I did both the items I was thinking to do for this JIRA. Added patch for deploy tool as well as console to prnt all the module names stopped, started, uninstalled Marking patch available, unassigning so that someone can review and commit Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 2.0 Attachments: consoleprint1285.patch, deploytooloutput.patch When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- 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: Unable to build jetty6 jee5 assembly
Krish, I see it here: http://snapshots.repository.codehaus.org/org/mortbay/jetty/jetty/6.1-SNAPSHOT/ Joe Krishnakumar B wrote: I am not able to find this jar in codehaus. There is a jetty-6.1.0pre3.jar but this gives compilation errors when building. Any other suggestions. Regards Krish On 12/6/06, David Jencks [EMAIL PROTECTED] wrote: it's supposed to be at the codehaus snapshot repo, and I have found it there in the past. might be a temporary glitch david jencks On Dec 6, 2006, at 1:10 AM, Krishnakumar B wrote: Hi, I am trying to build jetty6 assembly but it fails in modules-jetty6. [ERROR] BUILD ERROR [INFO] -- -- [INFO] Failed to resolve artifact. Missing: -- 1) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.mortbay.jetty - DartifactId=jetty \ -Dversion=6.1-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-jetty6:jar:2.0-SNAPSHOT 2) org.mortbay.jetty:jetty:jar:6.1-SNAPSHOT I am not able to find jetty jar for 6.1-SNAPSHOT in the repos. Regards Krish
[jira] Commented: (GERONIMO-2594) Add xalan to endorsed directory
[ http://issues.apache.org/jira/browse/GERONIMO-2594?page=comments#action_12456001 ] Anita Kulshreshtha commented on GERONIMO-2594: -- Fixed in rev 483063. Mac users please verify that it works for you. Thnaks Joe and Kevan! for providing valuable input: http://www.nabble.com/Re%3A-Need-help-with-IBM-JDK-1.5-p7645190.html Add xalan to endorsed directory --- Key: GERONIMO-2594 URL: http://issues.apache.org/jira/browse/GERONIMO-2594 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 2.0 Attachments: geronimo.diff, geronimo.diff from a discussion on the list: http://www.nabble.com/Server-startup-fails-with-Sun-JDK-1.5%2C-xalan-missing-p7375349.html It is possible to use Sun's xalan packed with JDK1.5 by setting the property: -Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl http://www.nabble.com/Re%3A-Server-startup-fails-with-Sun-JDK-1.5%2C-xalan-missing-p7491438.html To make geronimo independent of Sun JVM add xalan to endorsed dir. If there are no comments/objections I will commit this on Monday 27th. -- 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: Latest official release
Is the latest offical version is 4.1 now? Just released this week? nabble615 wrote: Hi, may I know whether the latest official activemq release is 4.0.2? May I know when is the released date of it as well? Thanks -- View this message in context: http://www.nabble.com/Latest-official-release-tf2717760.html#a7719692 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: exclusions tag in geronimo-connector\pom.xml
Tranql uses an older version of commons-logging than the one used by the kernel. Maven gets confused about the versions if the same jar is used in two different scopes: http://www.nabble.com/Re%3A-Another-really-strange-mysterious-build-error-p6294043.html Thanks Anita --- Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I see the following xml fragment in modules\geronimo-connector\pom.xml dependency groupIdorg.tranql/groupId artifactIdtranql/artifactId scopetest/scope exclusions exclusion groupIdcommons-logging/groupId artifactIdcommons-logging/artifactId /exclusion /exclusions /dependency Can someone tell me the use of this exclusions tag. If I comment out the exclusions part, I am able to build this module using IBMJDK1.5.0. Otherwise it is giving compilation errors like the following. C:\G1.2\modules\geronimo-connector\src\main\java\org\apache\geronimo\connector\o utbound\ManagedConnectionFactoryWrapper.java:[33,34] package org.apache.commons. logging does not exist Or are these compilation errors due to a problem in IBMJDK1.5.0? Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
Error when building geronimo 2.0
hi, The build fails in jetty6 builder module with following error Time to build schema type system: 1.011 seconds BUILD FAILED [INFO] [ERROR] BUILD ERROR [INFO] [INFO] XmlBeans compile failed: xml ErrorLoading schema file C:\g20\modules\geronimo-jetty6-builder\src\main\sc hema\geronimo-jetty-1.2.xsd xml ErrorLoading schema file C:\g20\modules\geronimo-jetty6-builder\src\main\sch ema\geronimo-jetty-config-1.0.xsd xml ErrorLoading config file C:\g20\modules\geronimo-jetty6-builder\src\main\sch ema\xmlconfig.xml xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:32: error: java.io.FileNotFoundException: C:\g20\modules\geronimo-jetty6- builder\src\main\schema\geronimo-naming-1.2.xsd (The system cannot find the file specified) xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:34: error: java.io.FileNotFoundException: C:\g20\modules\geronimo-jetty6- builder\src\main\schema\geronimo-application-1.2.xsd (The system cannot find the file specified) xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:35: error: java.io.FileNotFoundException: C:\g20\modules\geronimo-jetty6- builder\src\main\schema\geronimo-module-1.2.xsd (The system cannot find the file specified) xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:42: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apache.org/x ml/ns/deployment-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:46: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apache.org/xm l/ns/j2ee/application-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:48: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apache.org /xml/ns/naming-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:54: error: src-resolve: model group '[EMAIL PROTECTED]://gero nimo.apache.org/xml/ns/naming-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:55: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apac he.org/xml/ns/naming-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:59: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apache.org/xml/ ns/j2ee/application-1.2' not found. xml ErrorC:\g20\modules\geronimo-jetty6-builder\src\main\schema\geronimo-jetty-1 .2.xsd:62: error: src-resolve: element '[EMAIL PROTECTED]://geronimo.apache.org/xml/n s/deployment-1.2' not found. Regards Krish
Re: Latest official release
On 12/6/06, bluedolphin [EMAIL PROTECTED] wrote: Is the latest offical version is 4.1 now? Just released this week? Yes. http://incubator.apache.org/activemq/download.html -- James --- http://radio.weblogs.com/0112098/
[jira] Assigned: (AMQCPP-14) CMSExpiration not handled properly in ActiveMQProducer
[ https://issues.apache.org/activemq/browse/AMQCPP-14?page=all ] Timothy Bish reassigned AMQCPP-14: -- Assignee: Timothy Bish (was: Nathan Mittler) CMSExpiration not handled properly in ActiveMQProducer -- Key: AMQCPP-14 URL: https://issues.apache.org/activemq/browse/AMQCPP-14 Project: ActiveMQ C++ Client Issue Type: Bug Components: CMS Impl Affects Versions: 1.0 Environment: All Reporter: Nathan Mittler Assigned To: Timothy Bish Priority: Minor Fix For: 1.1 Original Estimate: 1 day Remaining Estimate: 1 day ActiveMQProducer.send method is overwriting the CMSExpiration in the message with its default timeToLive value. This is incorrect - it should set the expiry to (expiry + timeToLive). An example of this is in ActiveMQ's ActiveMQSession: https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/ActiveMQSession.java A work-around is to specify the timeToLive value in the producer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2628) Upgrade to tomcat 6.0.2 beta
Upgrade to tomcat 6.0.2 beta Key: GERONIMO-2628 URL: http://issues.apache.org/jira/browse/GERONIMO-2628 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Components: Tomcat Affects Versions: 2.0 Reporter: Paul McMahan Assigned To: Paul McMahan Priority: Critical Fix For: 2.0 Geronimo's Java EE 5 implementation needs Servlet 2.5 and JSP 2.1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2402) Redeployment fails after third iteration.
[
http://issues.apache.org/jira/browse/GERONIMO-2402?page=comments#action_12456085
]
Vamsavardhana Reddy commented on GERONIMO-2402:
---
Rakesh, in the patch you submitted i see the following:
{code}
+if (modules != null) {
+if (modules.length == 1) {
+return modules[0].getModuleID();
+} else {
+return ;
+}
+} else if (modules != null) { //distribute completed but not start or
something like that
+return ;
+} else {
+return null;
+}
{code}
else if (modules != null) ... is redundant. Can you recheck your patch.
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
Priority: Critical
Fix For: 1.2
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
Tibco RV support?
I saw in the following link that James mentioned support for Tibco RV - did this get anywhere? I'd be interested in trying it out. http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200601.mbox/[EMAIL PROTECTED] Cheers, Mike -- View this message in context: http://www.nabble.com/Tibco-RV-support--tf2768656.html#a7721169 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: Tibco RV support?
On 12/6/06, Mike Roberts [EMAIL PROTECTED] wrote: I saw in the following link that James mentioned support for Tibco RV - did this get anywhere? I'd be interested in trying it out. http://mail-archives.apache.org/mod_mbox/geronimo-activemq-dev/200601.mbox/[EMAIL PROTECTED] Its a little rough and ready - we could check it into the sandbox and folks could play further. Am not 100% sure we'd be able to host it at Apache though due to the licensing on the RV client API -- James --- http://radio.weblogs.com/0112098/
Re: Tibco RV support?
James wrote: Its a little rough and ready - we could check it into the sandbox and folks could play further. Am not 100% sure we'd be able to host it at Apache though due to the licensing on the RV client API OK, don't do work on this on my part yet because I'm not quite ready to try it. I'll follow up here if I can be more committed to giving it a go. Thanks for the follow-up! Mike -- View this message in context: http://www.nabble.com/Tibco-RV-support--tf2768656.html#a7721363 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] G 2.0 M1 Content
Chris, For 2.0-M1 I am planning to upgrade geronimo modules/configs to use 1.1 specs. I could ask Jacek to apply an openejb patch for us. We need to upgrade tranql also eventually. Thanks Anita --- Christopher M. Cardona [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita Anita, I also started looking at J2EE management work and I'm just wondering what you plan to include specifically in M1 release. I think we should coordinate this work so we donÂ’t do the same thing. Thanks, chris Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: [DISCUSS] G 2.0 M1 Content
Chris, If you are setup to publish the specs, could you please publish j2ee_management 1.1 spec. Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: Chris, For 2.0-M1 I am planning to upgrade geronimo modules/configs to use 1.1 specs. I could ask Jacek to apply an openejb patch for us. We need to upgrade tranql also eventually. Thanks Anita --- Christopher M. Cardona [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita Anita, I also started looking at J2EE management work and I'm just wondering what you plan to include specifically in M1 release. I think we should coordinate this work so we donÂ’t do the same thing. Thanks, chris Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
Re: SVK
Hi Vamsavardhana, No they're certainly not causing any problems--I was just curious about them more than anything. I've been ignoring most of the smerge conflicts due to their omissions, but sounds like they should be kept in sync so I'll take care of them if they're missing. Also, to address your second question, it will make it easier for me if you commit related 1.2 and trunk changes simultaneously, but don't no one should feel obligated. That said though--I wouldn't try to dissuade you from doing so. Thanks much Tim Vamsavardhana Reddy wrote: Tim, I have been adding $Rev$ $Date$ to any of the files that are getting modified and that don't already have these tags. Is this causing any trouble? One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? --vamsi On 12/6/06, *Tim McConnell* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with -C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use --baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
offlist:Re: publishing snapshots
Paul, I can offer an antique fruitcake..., if you could publish the management 1.1 specs. I am trying to figure out why my mvn deploy did not go through. Without the SNAPSHOTs, the build is broken :(. Thanks Anita Got some help on irc (thanks djencks). Just add the server to ~/.m2/settings.xml as described here http://maven.apache.org/settings.html and then type mvn deploy. Best wishes, Paul On 12/4/06, Paul McMahan [EMAIL PROTECTED] wrote: I created two new modules in specs/trunk: geronimo-el_1.0_spec geronimo-jsp_2.1_spec Can someone help publish those to the snapshot repo? I have a nice fruit cake I can regift if necessary (it's from last Christmas but still looks exactly the same). Or I don't mind doing this myself if someone can point me in the right direction. Best wishes, Paul Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
Re: [DISCUSS] G 2.0 M1 Content
Anita, This sounds like an excellent plan! I'm getting the impression you've done a lot of stuff already so please let me know what other missing pieces you haven't covered so I can help. Best wishes, chris anita kulshreshtha wrote: Chris, For 2.0-M1 I am planning to upgrade geronimo modules/configs to use 1.1 specs. I could ask Jacek to apply an openejb patch for us. We need to upgrade tranql also eventually. Thanks Anita --- Christopher M. Cardona [EMAIL PROTECTED] wrote: anita kulshreshtha wrote: Content --- At this point M1 would contain: Java 1.5 as the base JDK Tomcat and Jetty for Servlet 2.5, JSP 2.1 and Debugging support. JTA 1.1 JSF (depending on where the MyFaces folks are at) JSTL (I think Joe was working on this) If there is interest, I could add j2ee management 1.1. Thanks Anita Anita, I also started looking at J2EE management work and I'm just wondering what you plan to include specifically in M1 release. I think we should coordinate this work so we don’t do the same thing. Thanks, chris Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: offlist:Re: publishing snapshots
That guide isn't too specific. Do you have a server entry similar to: server idapache.snapshots/id usernamedjencks/username passphrase***/passphrase directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server Also before uploading please be sure that umask on people.apache.org is set to 2, not any otherwise normal value such as 22, or no one will be able to update anything you deploy. If it's not already 2 you will need to update a file, I think .bash_profile so that non- shells get it set properly. Kevan and probably lots of other people know the actual file. If this doesn't help what's the error you get? thanks david jencks On Dec 6, 2006, at 8:42 AM, anita kulshreshtha wrote: Paul, I can offer an antique fruitcake..., if you could publish the management 1.1 specs. I am trying to figure out why my mvn deploy did not go through. Without the SNAPSHOTs, the build is broken :(. Thanks Anita Got some help on irc (thanks djencks). Just add the server to ~/.m2/settings.xml as described here http://maven.apache.org/settings.html and then type mvn deploy. Best wishes, Paul On 12/4/06, Paul McMahan [EMAIL PROTECTED] wrote: I created two new modules in specs/trunk: geronimo-el_1.0_spec geronimo-jsp_2.1_spec Can someone help publish those to the snapshot repo? I have a nice fruit cake I can regift if necessary (it's from last Christmas but still looks exactly the same). Or I don't mind doing this myself if someone can point me in the right direction. Best wishes, Paul __ __ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
[jira] Closed: (GERONIMO-2548) GBeanInfo should exclude attributes and operations of java.lang.Object class
[ http://issues.apache.org/jira/browse/GERONIMO-2548?page=all ] Anita Kulshreshtha closed GERONIMO-2548. Fix Version/s: 2.0 Resolution: Fixed GBeanInfo should exclude attributes and operations of java.lang.Object class Key: GERONIMO-2548 URL: http://issues.apache.org/jira/browse/GERONIMO-2548 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Anita Kulshreshtha Fix For: 2.0 Attachments: kernel.patch, operations.jpg GBeanInfo includes 8 methods of java.lang.Object as opertaions. The 9th method of java.lang.Object getClass is added as an attribute named class in GbeanInfo. These should be excluded from GBeanInfo -- 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: offlist:Re: publishing snapshots
Anita, I already published the management 1.1 spec for you. Please verify and let me know if you get any problems. Best wishes, chris anita kulshreshtha wrote: Paul, I can offer an antique fruitcake..., if you could publish the management 1.1 specs. I am trying to figure out why my mvn deploy did not go through. Without the SNAPSHOTs, the build is broken :(. Thanks Anita Got some help on irc (thanks djencks). Just add the server to ~/.m2/settings.xml as described here http://maven.apache.org/settings.html and then type mvn deploy. Best wishes, Paul On 12/4/06, Paul McMahan [EMAIL PROTECTED] wrote: I created two new modules in specs/trunk: geronimo-el_1.0_spec geronimo-jsp_2.1_spec Can someone help publish those to the snapshot repo? I have a nice fruit cake I can regift if necessary (it's from last Christmas but still looks exactly the same). Or I don't mind doing this myself if someone can point me in the right direction. Best wishes, Paul Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
[jira] Created: (GERONIMODEVTOOLS-118) Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml
Complete Editor Support for specifying Dependencies, Hidden Classes, Non Overridable Classes GBean References in geronimo-web.xml --- Key: GERONIMODEVTOOLS-118 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-118 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Shiva Kumar H R Please see the discussion going on about this at dev@geronimo.apache.org mailing list: http://www.mail-archive.com/dev@geronimo.apache.org/msg35865.html -- 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-2402) Redeployment fails after third iteration.
[ http://issues.apache.org/jira/browse/GERONIMO-2402?page=comments#action_12456122 ] Vamsavardhana Reddy commented on GERONIMO-2402: --- I have tried the fix on branches\1.1 (not 1.2) , excluding the redundant else if (modules != null)... part. The redeployment part after each file updation seems to work properly except that server tries to redeploy the app at each restart (I guess this is to addressed by GERONIMO-2584). 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 Priority: Critical Fix For: 1.2 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
[jira] Commented: (GERONIMO-2584) Hot deploy module/server restart, throws IllegalArgumentException if application deployed using hotdeployment
[ http://issues.apache.org/jira/browse/GERONIMO-2584?page=comments#action_12456145 ] Vamsavardhana Reddy commented on GERONIMO-2584: --- I have tried the patch on branches\1.1 (not 1.2) in combination with the fix for GERONIMO-2402. Verified that the fix works fine and no exceptions are thrown at startup. 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 Fix For: 1.2 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(generated) ... 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: Need Contributor Access to JIRA
Shiva, Please provide your JIRA id. --vamsi On 12/6/06, Shiva Kumar H R [EMAIL PROTECTED] wrote: Hello, I have been working on enhancing Geronimo Eclipse Plug-in for quite sometime now (http://www.mail-archive.com/dev@geronimo.apache.org/msg35865.html ) and want to start contributing to the source. Hence request to provide me with Contributor Access to JIRA. Thanks, Shiva
Re: offlist:Re: publishing snapshots
FYI... soon we will have our automated build system deploying nightly, as well as on demand. This will help reduce issues caused by deployment w/bad umasks and a few other issues (like accidentally using the wrong jdk, accidentially deploying uncommitted changes, etc). --jason On Dec 6, 2006, at 8:57 AM, David Jencks wrote: That guide isn't too specific. Do you have a server entry similar to: server idapache.snapshots/id usernamedjencks/username passphrase***/passphrase directoryPermissions775/directoryPermissions filePermissions664/filePermissions /server Also before uploading please be sure that umask on people.apache.org is set to 2, not any otherwise normal value such as 22, or no one will be able to update anything you deploy. If it's not already 2 you will need to update a file, I think .bash_profile so that non-shells get it set properly. Kevan and probably lots of other people know the actual file. If this doesn't help what's the error you get? thanks david jencks On Dec 6, 2006, at 8:42 AM, anita kulshreshtha wrote: Paul, I can offer an antique fruitcake..., if you could publish the management 1.1 specs. I am trying to figure out why my mvn deploy did not go through. Without the SNAPSHOTs, the build is broken :(. Thanks Anita Got some help on irc (thanks djencks). Just add the server to ~/.m2/settings.xml as described here http://maven.apache.org/settings.html and then type mvn deploy. Best wishes, Paul On 12/4/06, Paul McMahan [EMAIL PROTECTED] wrote: I created two new modules in specs/trunk: geronimo-el_1.0_spec geronimo-jsp_2.1_spec Can someone help publish those to the snapshot repo? I have a nice fruit cake I can regift if necessary (it's from last Christmas but still looks exactly the same). Or I don't mind doing this myself if someone can point me in the right direction. Best wishes, Paul _ ___ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
Re: offlist:Re: publishing snapshots
That will be sweet!! On 12/6/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI... soon we will have our automated build system deploying nightly, as well as on demand. This will help reduce issues caused by deployment w/bad umasks and a few other issues (like accidentally using the wrong jdk, accidentially deploying uncommitted changes, etc). --jason
versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-management/
opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason On Dec 6, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: Author: akulshreshtha Date: Wed Dec 6 07:46:42 2006 New Revision: 483121 URL: http://svn.apache.org/viewvc?view=revrev=483121 Log: GERONIMO-2629 Upgrade to J2EE Management 1.1 Modified: geronimo/server/trunk/configs/client-system/pom.xml geronimo/server/trunk/configs/jee-specs/pom.xml geronimo/server/trunk/modules/ge-activemq-rar/pom.xml geronimo/server/trunk/modules/geronimo-management/pom.xml geronimo/server/trunk/modules/geronimo-tomcat/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/configs/client-system/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ client-system/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/client-system/pom.xml (original) +++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 07:46:42 2006 @@ -44,7 +44,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/configs/jee-specs/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/jee- specs/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/jee-specs/pom.xml (original) +++ geronimo/server/trunk/configs/jee-specs/pom.xml Wed Dec 6 07:46:42 2006 @@ -58,7 +58,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency dependency Modified: geronimo/server/trunk/modules/ge-activemq-rar/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ge- activemq-rar/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/ge-activemq-rar/pom.xml (original) +++ geronimo/server/trunk/modules/ge-activemq-rar/pom.xml Wed Dec 6 07:46:42 2006 @@ -120,7 +120,7 @@ exclusion groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /exclusion exclusion Modified: geronimo/server/trunk/modules/geronimo-management/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-management/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/geronimo-management/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-management/pom.xml Wed Dec 6 07:46:42 2006 @@ -46,7 +46,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/modules/geronimo-tomcat/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-tomcat/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/geronimo-tomcat/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-tomcat/pom.xml Wed Dec 6 07:46:42 2006 @@ -54,7 +54,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId scopeprovided/scope /dependency Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?
Re: versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-managem
I agree. This practice has the feel of a shortcut around maven's versioning system that we may regret taking later. Best wishes, Paul On 12/6/06, Jason Dillon [EMAIL PROTECTED] wrote: opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason
Re: Need Contributor Access to JIRA
Done :) Welcome On Dec 6, 2006, at 12:24 PM, Shiva Kumar H R wrote: Hello, I have been working on enhancing Geronimo Eclipse Plug-in for quite sometime now (http://www.mail-archive.com/dev@geronimo.apache.org/ msg35865.html ) and want to start contributing to the source. Hence request to provide me with Contributor Access to JIRA. Thanks, Shiva Matt Hogstrom [EMAIL PROTECTED]
Re: versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-managem
I dunno... I kinda like the artifact_v.v-mavenVersion as artifact- v.v-mavenVersion seems more confusing. I'll have to noodle on it though. I think the _ in the name clearly identifies the version number as being related to the artifact content rather then the version of the specs. On Dec 6, 2006, at 1:44 PM, Jason Dillon wrote: opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason On Dec 6, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: Author: akulshreshtha Date: Wed Dec 6 07:46:42 2006 New Revision: 483121 URL: http://svn.apache.org/viewvc?view=revrev=483121 Log: GERONIMO-2629 Upgrade to J2EE Management 1.1 Modified: geronimo/server/trunk/configs/client-system/pom.xml geronimo/server/trunk/configs/jee-specs/pom.xml geronimo/server/trunk/modules/ge-activemq-rar/pom.xml geronimo/server/trunk/modules/geronimo-management/pom.xml geronimo/server/trunk/modules/geronimo-tomcat/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/configs/client-system/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ client-system/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/configs/client-system/pom.xml (original) +++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 07:46:42 2006 @@ -44,7 +44,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/configs/jee-specs/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ jee-specs/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/configs/jee-specs/pom.xml (original) +++ geronimo/server/trunk/configs/jee-specs/pom.xml Wed Dec 6 07:46:42 2006 @@ -58,7 +58,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency dependency Modified: geronimo/server/trunk/modules/ge-activemq-rar/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ge- activemq-rar/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/modules/ge-activemq-rar/pom.xml (original) +++ geronimo/server/trunk/modules/ge-activemq-rar/pom.xml Wed Dec 6 07:46:42 2006 @@ -120,7 +120,7 @@ exclusion groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee- management_1.0_spec/artifactId +artifactIdgeronimo-j2ee- management_1.1_spec/artifactId /exclusion exclusion Modified: geronimo/server/trunk/modules/geronimo-management/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-management/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/modules/geronimo-management/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-management/pom.xml Wed Dec 6 07:46:42 2006 @@ -46,7 +46,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/modules/geronimo-tomcat/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-tomcat/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/modules/geronimo-tomcat/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-tomcat/pom.xml Wed Dec 6 07:46:42 2006 @@ -54,7 +54,7 @@ dependency
Re: versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-managem
I think you missed the point sir :-P I was not talking about _ vs - ... I was suggesting that the v.v bits are you use below are whack, they should not be needed... all versioning should be in mavenVersion. --jason On Dec 6, 2006, at 11:01 AM, Matt Hogstrom wrote: I dunno... I kinda like the artifact_v.v-mavenVersion as artifact- v.v-mavenVersion seems more confusing. I'll have to noodle on it though. I think the _ in the name clearly identifies the version number as being related to the artifact content rather then the version of the specs. On Dec 6, 2006, at 1:44 PM, Jason Dillon wrote: opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason On Dec 6, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: Author: akulshreshtha Date: Wed Dec 6 07:46:42 2006 New Revision: 483121 URL: http://svn.apache.org/viewvc?view=revrev=483121 Log: GERONIMO-2629 Upgrade to J2EE Management 1.1 Modified: geronimo/server/trunk/configs/client-system/pom.xml geronimo/server/trunk/configs/jee-specs/pom.xml geronimo/server/trunk/modules/ge-activemq-rar/pom.xml geronimo/server/trunk/modules/geronimo-management/pom.xml geronimo/server/trunk/modules/geronimo-tomcat/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/configs/client-system/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ client-system/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/client-system/pom.xml (original) +++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 07:46:42 2006 @@ -44,7 +44,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/configs/jee-specs/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ jee-specs/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/jee-specs/pom.xml (original) +++ geronimo/server/trunk/configs/jee-specs/pom.xml Wed Dec 6 07:46:42 2006 @@ -58,7 +58,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency dependency Modified: geronimo/server/trunk/modules/ge-activemq-rar/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ ge-activemq-rar/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/ge-activemq-rar/pom.xml (original) +++ geronimo/server/trunk/modules/ge-activemq-rar/pom.xml Wed Dec 6 07:46:42 2006 @@ -120,7 +120,7 @@ exclusion groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee- management_1.0_spec/artifactId +artifactIdgeronimo-j2ee- management_1.1_spec/artifactId /exclusion exclusion Modified: geronimo/server/trunk/modules/geronimo-management/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-management/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/geronimo-management/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-management/pom.xml Wed Dec 6 07:46:42 2006 @@ -46,7 +46,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/modules/geronimo-tomcat/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-tomcat/pom.xml?view=diffrev=483121r1=483120r2=483121
Re: versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-managem
We discussed this pretty extensively when we adopted this naming scheme. I still think the current scheme is the best choice. My reasoning behind this is that for code that we control we should have a single version, such as 1.0, 1.1.2, 2.0, etc, but for code that is based on something we don't control such as specs, web containers, etc, something about the version of the external stuff should be reflected in the artifactId. Thus specs should get the spec rev in the artifactId, and the web containers should get their version in the artifactid. Thus the jetty modules and configs would be better named jetty5. The openejb configs should probably be openejb2-*. thanks david jencks On Dec 6, 2006, at 10:44 AM, Jason Dillon wrote: opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason On Dec 6, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: Author: akulshreshtha Date: Wed Dec 6 07:46:42 2006 New Revision: 483121 URL: http://svn.apache.org/viewvc?view=revrev=483121 Log: GERONIMO-2629 Upgrade to J2EE Management 1.1 Modified: geronimo/server/trunk/configs/client-system/pom.xml geronimo/server/trunk/configs/jee-specs/pom.xml geronimo/server/trunk/modules/ge-activemq-rar/pom.xml geronimo/server/trunk/modules/geronimo-management/pom.xml geronimo/server/trunk/modules/geronimo-tomcat/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/configs/client-system/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ client-system/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/configs/client-system/pom.xml (original) +++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 07:46:42 2006 @@ -44,7 +44,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/configs/jee-specs/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ jee-specs/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/configs/jee-specs/pom.xml (original) +++ geronimo/server/trunk/configs/jee-specs/pom.xml Wed Dec 6 07:46:42 2006 @@ -58,7 +58,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency dependency Modified: geronimo/server/trunk/modules/ge-activemq-rar/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ge- activemq-rar/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/modules/ge-activemq-rar/pom.xml (original) +++ geronimo/server/trunk/modules/ge-activemq-rar/pom.xml Wed Dec 6 07:46:42 2006 @@ -120,7 +120,7 @@ exclusion groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee- management_1.0_spec/artifactId +artifactIdgeronimo-j2ee- management_1.1_spec/artifactId /exclusion exclusion Modified: geronimo/server/trunk/modules/geronimo-management/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-management/pom.xml?view=diffrev=483121r1=483120r2=483121 = = --- geronimo/server/trunk/modules/geronimo-management/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-management/pom.xml Wed Dec 6 07:46:42 2006 @@ -46,7 +46,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/modules/geronimo-tomcat/pom.xml URL:
[jira] Created: (GERONIMO-2630) sun j2ee schemas are being redistributed in jsp and servlet specs
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 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
Re: versions in artifact ids (was: Re: svn commit: r483121 - in /geronimo/server/trunk: configs/client-system/pom.xml configs/jee-specs/pom.xml modules/ge-activemq-rar/pom.xml modules/geronimo-managem
I agree for the jetty bits and the openejb bits, but not really for the specs... especially with the per-module versioning of them. Though if you follow the naming scheme for the others, its more like jetty_5-* and openejb_2-* :-( --jason On Dec 6, 2006, at 11:07 AM, David Jencks wrote: We discussed this pretty extensively when we adopted this naming scheme. I still think the current scheme is the best choice. My reasoning behind this is that for code that we control we should have a single version, such as 1.0, 1.1.2, 2.0, etc, but for code that is based on something we don't control such as specs, web containers, etc, something about the version of the external stuff should be reflected in the artifactId. Thus specs should get the spec rev in the artifactId, and the web containers should get their version in the artifactid. Thus the jetty modules and configs would be better named jetty5. The openejb configs should probably be openejb2-*. thanks david jencks On Dec 6, 2006, at 10:44 AM, Jason Dillon wrote: opinion I think it is really loopy that we have version information in artifact ids. A few people outside of the group have mentioned this too me too. IMO it would be better if the artifact ids of the specs did not have any version muck, and the version of that module was based on the spec version + a revision number. So for example, the spec here would be: groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-j2ee-management/artifactId version1.1-1/version (or 1.1-1-SNAPSHOT for evil mvn snapshot muck) Anyways, I'm not going to do anything about this... but I will continue to point out that putting version information into artifactIds is a poor idea... and generally a bad one at that. /opinion --jason On Dec 6, 2006, at 7:46 AM, [EMAIL PROTECTED] wrote: Author: akulshreshtha Date: Wed Dec 6 07:46:42 2006 New Revision: 483121 URL: http://svn.apache.org/viewvc?view=revrev=483121 Log: GERONIMO-2629 Upgrade to J2EE Management 1.1 Modified: geronimo/server/trunk/configs/client-system/pom.xml geronimo/server/trunk/configs/jee-specs/pom.xml geronimo/server/trunk/modules/ge-activemq-rar/pom.xml geronimo/server/trunk/modules/geronimo-management/pom.xml geronimo/server/trunk/modules/geronimo-tomcat/pom.xml geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/configs/client-system/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ client-system/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/client-system/pom.xml (original) +++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 07:46:42 2006 @@ -44,7 +44,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency /dependencies Modified: geronimo/server/trunk/configs/jee-specs/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/ jee-specs/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/configs/jee-specs/pom.xml (original) +++ geronimo/server/trunk/configs/jee-specs/pom.xml Wed Dec 6 07:46:42 2006 @@ -58,7 +58,7 @@ dependency groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee-management_1.0_spec/ artifactId +artifactIdgeronimo-j2ee-management_1.1_spec/ artifactId /dependency dependency Modified: geronimo/server/trunk/modules/ge-activemq-rar/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ ge-activemq-rar/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/ge-activemq-rar/pom.xml (original) +++ geronimo/server/trunk/modules/ge-activemq-rar/pom.xml Wed Dec 6 07:46:42 2006 @@ -120,7 +120,7 @@ exclusion groupIdorg.apache.geronimo.specs/groupId -artifactIdgeronimo-j2ee- management_1.0_spec/artifactId +artifactIdgeronimo-j2ee- management_1.1_spec/artifactId /exclusion exclusion Modified: geronimo/server/trunk/modules/geronimo-management/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/modules/ geronimo-management/pom.xml?view=diffrev=483121r1=483120r2=483121 == --- geronimo/server/trunk/modules/geronimo-management/pom.xml (original) +++ geronimo/server/trunk/modules/geronimo-management/pom.xml Wed Dec 6 07:46:42 2006 @@ -46,7 +46,7 @@ dependency
Re: Error compiling Geronimo with Maven
Ok, but I still don't get the 'target' directories. Where is maven supposed to put the output binaries to? --- Jason Dillon [EMAIL PROTECTED] escribió: On Dec 5, 2006, at 9:18 PM, Diego L Espiñeira wrote: By the way, I'm on an Ubuntu Linux Desktop 6.10, which doesn't use bash but dash as its default shell. Does it have anything to do with my problems? I've not used dash before... but if it is sh compatible (like bash or zsh or ksh) then you should be fine. --jason __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar
Re: offlist:Re: publishing snapshots
I have got the latest code from SVN. My build fails with following error trace: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.geronimo.specs-DartifactId geronimo-j2ee-management_1.1_spec \ -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.geronimo.modules:geronimo-management:jar:2.0-SNAPSHOT 2) org.apache.geronimo.specs:geronimo-j2ee-management_1.1_spec:jar:1.0- NAPSHOT -- 1 required artifact is missing. for artifact: org.apache.geronimo.modules:geronimo-management:jar:2.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus (http://repository.codehaus.org), apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository), codehaus-snapshots (http://snapshots.repository.codehaus.org) On 12/6/06, Paul McMahan [EMAIL PROTECTED] wrote: That will be sweet!! On 12/6/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI... soon we will have our automated build system deploying nightly, as well as on demand. This will help reduce issues caused by deployment w/bad umasks and a few other issues (like accidentally using the wrong jdk, accidentially deploying uncommitted changes, etc). --jason
[jira] Created: (GERONIMODEVTOOLS-119) import simple hello.war results xml-fragment tag in geronimo-web.xml
import simple hello.war results xml-fragment tag in geronimo-web.xml
Key: GERONIMODEVTOOLS-119
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-119
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 1.2.0
Environment: patched created with latest trunk 480183
Reporter: Lin Sun
Tried to import a simple hello war file however after import the
geronimo-web.xml file contains xml-fragment tag which prevents the hello
project from being deployed to server. tried to print out the following var
plan in ImportDeploymentPlanOperation.java
plan = runtime.fixGeronimoWebSchema(planFile);
System.out.println(plan 1: + plan.toString());
Here's the printout:
plan 1: xml-fragment xmlns:nam=http://geronimo.apache.org/xml/ns/naming-1.1;
xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1;
xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1;
xmlns:web=http://geronimo.apache.org/xml/ns/j2ee/web-1.1;
sys:environment
sys:moduleId
sys:groupIdsamples/sys:groupId
sys:artifactIdcviewer/sys:artifactId
sys:version1.1/sys:version
sys:typewar/sys:type
/sys:moduleId
sys:dependencies/
sys:hidden-classes/
sys:non-overridable-classes/
/sys:environment
web:context-root/cviewer/web:context-root
/xml-fragment
Note this is not a valid plan.
I updated the following method in
org.apache.geronimo.st.v11.core.GeronimoRuntime and it is working now (for war
file).
public XmlObject fixGeronimoWebSchema(IFile plan) throws XmlException {
XmlObject xmlplan = getXmlObject(plan);
if (plan != null) {
SchemaConversionUtils.fixGeronimoSchema(xmlplan,
GerWebAppDocument.type.getDocumentElementName(),
GerWebAppType.type);
save(xmlplan, plan);
return xmlplan;
}
return null;
//return SchemaConversionUtils.fixGeronimoSchema(getXmlObject(plan),
GerWebAppDocument.type.getDocumentElementName(), GerWebAppType.type);
}
Also added the save method back from 1.0 to
org.apache.geronimo.st.v11.core.GeronimoRuntime:
private void save(XmlObject object, IFile file) {
try {
object.save(file.getLocation().toFile());
file.refreshLocal(IFile.DEPTH_ONE, null);
} catch (IOException e) {
e.printStackTrace();
} catch (CoreException e) {
e.printStackTrace();
}
}
Patch has been tested on importing war projects and worked well.
--
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: r483063 - in /geronimo/server/trunk: ./ assemblies/geronimo-boilerplate-minimal/ configs/client-system/ configs/j2ee-system/ configs/online-deployer/ configs/upgrade-cli/ maven-plugins
I think this may have removed a bit too much :-)
Now, when attempting to use the Web Console for any of the servers in
trunk we get a NoClassDefFoundError for a xerces class when we hit the
console welcome page. Paul avoided this on the tomcat 6 work by adding
a dependency in config\tomcat(6) on xercesImpl. I've verified that this
works for jetty too. I'll go ahead and check that change in for jetty
jetty6 (Paul is already covering tomcat with his checkin).
Joe
[EMAIL PROTECTED] wrote:
Author: akulshreshtha
Date: Wed Dec 6 05:05:35 2006
New Revision: 483063
URL: http://svn.apache.org/viewvc?view=revrev=483063
Log:
Upgrade xerces to 2.8.1, GERONIMO-2594 Remove xmlParserApis and xalan
Remove xerces from everywhere except console
Modified:
geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml
geronimo/server/trunk/configs/client-system/pom.xml
geronimo/server/trunk/configs/j2ee-system/pom.xml
geronimo/server/trunk/configs/online-deployer/pom.xml
geronimo/server/trunk/configs/upgrade-cli/pom.xml
geronimo/server/trunk/maven-plugins/car-maven-plugin/pom.xml
geronimo/server/trunk/modules/geronimo-system/pom.xml
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml?view=diffrev=483063r1=483062r2=483063
==
--- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml
(original)
+++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/pom.xml Wed
Dec 6 05:05:35 2006
@@ -156,16 +156,6 @@
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
/artifactItem
-
-artifactItem
-groupIdxerces/groupId
-artifactIdxmlParserAPIs/artifactId
-/artifactItem
-
-artifactItem
-groupIdxalan/groupId
-artifactIdxalan/artifactId
-/artifactItem
/artifactItems
outputDirectory${project.build.directory}/classes/lib/endorsed/outputDirectory
/configuration
Modified: geronimo/server/trunk/configs/client-system/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/configs/client-system/pom.xml?view=diffrev=483063r1=483062r2=483063
==
--- geronimo/server/trunk/configs/client-system/pom.xml (original)
+++ geronimo/server/trunk/configs/client-system/pom.xml Wed Dec 6 05:05:35 2006
@@ -47,16 +47,6 @@
artifactIdgeronimo-j2ee-management_1.0_spec/artifactId
/dependency
-dependency
-groupIdxerces/groupId
-artifactIdxercesImpl/artifactId
-/dependency
-
-dependency
-groupIdxerces/groupId
-artifactIdxmlParserAPIs/artifactId
-/dependency
-
/dependencies
build
@@ -142,16 +132,6 @@
element
groupIdxstream/groupId
artifactIdxstream/artifactId
-/element
-element
-groupIdxerces/groupId
-artifactIdxercesImpl/artifactId
-classpathPrefix../lib/endorsed/classpathPrefix
-/element
-element
-groupIdxerces/groupId
-artifactIdxmlParserAPIs/artifactId
-classpathPrefix../lib/endorsed/classpathPrefix
/element
/classpath
classpathPrefix../lib/classpathPrefix
Modified: geronimo/server/trunk/configs/j2ee-system/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/configs/j2ee-system/pom.xml?view=diffrev=483063r1=483062r2=483063
==
--- geronimo/server/trunk/configs/j2ee-system/pom.xml (original)
+++ geronimo/server/trunk/configs/j2ee-system/pom.xml Wed Dec 6 05:05:35 2006
@@ -143,16 +143,6 @@
groupIdbackport-util-concurrent/groupId
artifactIdbackport-util-concurrent/artifactId
/element
-element
-groupIdxerces/groupId
-artifactIdxercesImpl/artifactId
-
[jira] Updated: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=all ] Christopher James Blythe updated DAYTRADER-25: -- Attachment: daytrader-25.schema.patch Here is a patch to fix the schema files associated with DT-14 (built against the 1.2 branch). This updates the indexes and the decimal precision. Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: http://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-25.schema.patch While working with previous versions of Trade, I found that the monetary values stored in the database could overrun the decimal precision defined in the schema (10,2) if allowed to run for an extended period of time. This would result in SQL exceptions related to data conversion. To prevent this we increased the decimal presion to (14,2) We also found that some of the indexs were not necessary and that others should be added. In addition to the primary keys, here are the indexes we found to be the most useful... CREATE INDEX a.profile_userid on accountejb(profile_userid); CREATE INDEX h.account_accountid on holdingejb(account_accountid); CREATE INDEX o.account_accountid on orderejb(account_accountid); CREATE INDEX o.holding_holdingid on orderejb(holding_holdingid); CREATE INDEX o.closed_orders on orderejb(account_accountid,orderstatus); Will wait to submit a patch until the fate of Daytrader-14 is determined. -- 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: (DAYTRADER-25) Update decimal precision and indexes in ddl
[ http://issues.apache.org/jira/browse/DAYTRADER-25?page=all ] Christopher James Blythe updated DAYTRADER-25: -- Attachment: daytrader-25.code.patch This patch updates the quote price change algorithm to that described in my previous comments. The change factor varies between +/- 20% and if stock prices reach a value greater than $400, the price is cut in half. Update decimal precision and indexes in ddl --- Key: DAYTRADER-25 URL: http://issues.apache.org/jira/browse/DAYTRADER-25 Project: DayTrader Issue Type: Improvement Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-25.code.patch, daytrader-25.schema.patch While working with previous versions of Trade, I found that the monetary values stored in the database could overrun the decimal precision defined in the schema (10,2) if allowed to run for an extended period of time. This would result in SQL exceptions related to data conversion. To prevent this we increased the decimal presion to (14,2) We also found that some of the indexs were not necessary and that others should be added. In addition to the primary keys, here are the indexes we found to be the most useful... CREATE INDEX a.profile_userid on accountejb(profile_userid); CREATE INDEX h.account_accountid on holdingejb(account_accountid); CREATE INDEX o.account_accountid on orderejb(account_accountid); CREATE INDEX o.holding_holdingid on orderejb(holding_holdingid); CREATE INDEX o.closed_orders on orderejb(account_accountid,orderstatus); Will wait to submit a patch until the fate of Daytrader-14 is determined. -- 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
MyFaces 1.2 SNAPSHOT update
Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim
Re: Error compiling Geronimo with Maven
You ran `mvn -Dstage=bootstrap`... which does not build apps, configs or assemblies. Just run `mvn install`. --jason On Dec 6, 2006, at 11:24 AM, Diego Espineira wrote: Ok, but I still don't get the 'target' directories. Where is maven supposed to put the output binaries to? --- Jason Dillon [EMAIL PROTECTED] escribió: On Dec 5, 2006, at 9:18 PM, Diego L Espiñeira wrote: By the way, I'm on an Ubuntu Linux Desktop 6.10, which doesn't use bash but dash as its default shell. Does it have anything to do with my problems? I've not used dash before... but if it is sh compatible (like bash or zsh or ksh) then you should be fine. --jason __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar
Openjeb itests - 552 tests, 2 failures, 2 errors
Thanks to Rick, the pervasive NoClassDefFoundException in openejb itests were fixed. Tha plan openejb-jar.xml needed the ORBConfigAdapter gbean. It also needed a dependency on the j2ee-corba-yoko config. https://issues.apache.org/jira/browse/OPENEJB-399 fixes that issue. We are now down to just 2 failures and 2 errors on the Openejb-2.3 itests. The stack trace is here -- http://rifers.org/paste/show/2622 Cheers Prasad
Re: Error compiling Geronimo with Maven
Ok, thanks. Then the tutorial has to be modified. It is not that clear for a beginner. Or it wasn't just for me :´( Thanks for your attention --- Jason Dillon [EMAIL PROTECTED] escribió: You ran `mvn -Dstage=bootstrap`... which does not build apps, configs or assemblies. Just run `mvn install`. --jason On Dec 6, 2006, at 11:24 AM, Diego Espineira wrote: Ok, but I still don't get the 'target' directories. Where is maven supposed to put the output binaries to? --- Jason Dillon [EMAIL PROTECTED] escribió: On Dec 5, 2006, at 9:18 PM, Diego L Espiñeira wrote: By the way, I'm on an Ubuntu Linux Desktop 6.10, which doesn't use bash but dash as its default shell. Does it have anything to do with my problems? I've not used dash before... but if it is sh compatible (like bash or zsh or ksh) then you should be fine. --jason __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar
[jira] Updated: (DAYTRADER-28) Un-needed methods in TradeJDBC Remote Interface should be removed
[ http://issues.apache.org/jira/browse/DAYTRADER-28?page=all ] Christopher James Blythe updated DAYTRADER-28: -- Attachment: daytrader-28.patch Here is a patch to remove all of the methods from the TradeJDBC.java file. Un-needed methods in TradeJDBC Remote Interface should be removed - Key: DAYTRADER-28 URL: http://issues.apache.org/jira/browse/DAYTRADER-28 Project: DayTrader Issue Type: Bug Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Priority: Minor Attachments: daytrader-28.patch While developing the SLSB to JDBC mode, the interfaces for the original TradeBean SLSB where used as a template. The methods that are defined in the remote interface for TradeJDBC.java file should be removed since they are not used or implemented in the TradeJDBCBean class. -- 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: Geronimo 2.0 Milestone's and how were doing
On 12/5/06, Paul McMahan [EMAIL PROTECTED] wrote: On 12/5/06, Kevan Miller [EMAIL PROTECTED] wrote: Paul, Tomcat integration might have the most work to do for M1. How is that looking? I have the JSP 2.1 and EL 1.0 specs checked in and published to the snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's advice. The annotation 1.0 and servlet 2.5 specs were already available thanks to Joe and Greg. In my local build I have tc6 running the web console OK in a new tomcat-jee5 assembly and the default app in the tomcat-minimal assembly. Deploying a simple 2.4 WAR from the CLI works. I'm pretty confident that I'll be able to commit this first stage of tomcat integration this week. I just committed stage 2 of the tc6 update. As a reminder here's the wiki page for the overall game plan with progress indicated: http://cwiki.apache.org/GMOxDEV/tomcat-v6-game-plan.html If anyone sees problems then please let me know. Current issues: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy =2.4. servlets to. Turns out this works OK. I added a testcase to geronimo-tomcat that uses a 2.5 web.xml. Failing unit test- A unit tests in geronimo-tomcat fails intermittently apparently due to a change in how tc6 handles connections. Still investigating if its a bug in geronimo, tomcat or the unit test. For the initial checkin I may need to disable the unit test. I disabled the unit test and am investigating whether the problem is in geronimo, the test case, or in tomcat. Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Others were seeing this stack trace before I committed and it's in the jetty assembly as well so apparently not due to tc6. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. Tomcat is still logging INFO messages in the command window and I will fix that asap. I needed to go ahead and check in as-is so others with prereqs on tc6 can proceed with their work (plus I was going nuts keeping up with in trunk :-) Best wishes, Paul
Re: Error compiling Geronimo with Maven
http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with-maven-2.html It says Building for the first time mvn -Dstage=bootstrap and that's how I did. --- Jason Dillon [EMAIL PROTECTED] escribió: Which tutorial are you referring to? --jason On Dec 6, 2006, at 12:44 PM, Diego Espineira wrote: Ok, thanks. Then the tutorial has to be modified. It is not that clear for a beginner. Or it wasn't just for me :´( Thanks for your attention --- Jason Dillon [EMAIL PROTECTED] escribió: You ran `mvn -Dstage=bootstrap`... which does not build apps, configs or assemblies. Just run `mvn install`. --jason On Dec 6, 2006, at 11:24 AM, Diego Espineira wrote: Ok, but I still don't get the 'target' directories. Where is maven supposed to put the output binaries to? --- Jason Dillon [EMAIL PROTECTED] escribió: On Dec 5, 2006, at 9:18 PM, Diego L Espiñeira wrote: By the way, I'm on an Ubuntu Linux Desktop 6.10, which doesn't use bash but dash as its default shell. Does it have anything to do with my problems? I've not used dash before... but if it is sh compatible (like bash or zsh or ksh) then you should be fine. --jason __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar
Re: Error compiling Geronimo with Maven
I've fixed the docs and set this page to only be editable by members of geronimo-users. I also added a section under the default building bits to explain the sections. Folks, please take special care when making changes to guides like this. --jason On Dec 6, 2006, at 1:19 PM, Diego Espineira wrote: http://cwiki.apache.org/GMOxDEV/building-apache-geronimo-with- maven-2.html It says Building for the first time mvn -Dstage=bootstrap and that's how I did. --- Jason Dillon [EMAIL PROTECTED] escribió: Which tutorial are you referring to? --jason On Dec 6, 2006, at 12:44 PM, Diego Espineira wrote: Ok, thanks. Then the tutorial has to be modified. It is not that clear for a beginner. Or it wasn't just for me :´( Thanks for your attention --- Jason Dillon [EMAIL PROTECTED] escribió: You ran `mvn -Dstage=bootstrap`... which does not build apps, configs or assemblies. Just run `mvn install`. --jason On Dec 6, 2006, at 11:24 AM, Diego Espineira wrote: Ok, but I still don't get the 'target' directories. Where is maven supposed to put the output binaries to? --- Jason Dillon [EMAIL PROTECTED] escribió: On Dec 5, 2006, at 9:18 PM, Diego L Espiñeira wrote: By the way, I'm on an Ubuntu Linux Desktop 6.10, which doesn't use bash but dash as its default shell. Does it have anything to do with my problems? I've not used dash before... but if it is sh compatible (like bash or zsh or ksh) then you should be fine. --jason __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar __ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar
[jira] Created: (DAYTRADER-29) Asyc 1-Phase mode should be removed
Asyc 1-Phase mode should be removed --- Key: DAYTRADER-29 URL: http://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- 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: (DAYTRADER-29) Async 1-Phase mode should be removed
[ http://issues.apache.org/jira/browse/DAYTRADER-29?page=all ] Christopher James Blythe updated DAYTRADER-29: -- Summary: Async 1-Phase mode should be removed (was: Asyc 1-Phase mode should be removed) Async 1-Phase mode should be removed Key: DAYTRADER-29 URL: http://issues.apache.org/jira/browse/DAYTRADER-29 Project: DayTrader Issue Type: Improvement Components: EJB Tier Affects Versions: 1.2, 2.0 Reporter: Christopher James Blythe Here are some comments that I added to DT-22... Since my involvement with Daytrader (and Trade), we've never been all that concerned with the Async 1-phase mode. Here is the lay of the land to my understanding... Sync mode - Uses JMS topics and TradeTopicMDB to publish changes to the quote prices - There is flag in the DDs to disable this but it doesn't seem to apply to direct mode (only EJB mode) Async 2-phase mode - This mode uses a JMS queue and the TradeBroker to handle order processing - Specifically, the buy and sell operations call a queueOrder method to place a message on the queue - The queueOrder is part of an XA transaction because two resource managers (JMS and database) are involved to create the order in the databse and place a message on the queue - The MDB starts a new transaction when the message is read from the queue. The MDB then executes the completeOrder method which updates the order in the database inside the original MDB transaction context Async 1-phase mode - Does the same as above, but does not involve an UserTransaction to provide XA - Since the MDB is container-managed, TradeEJB is used to complete the order and create a new transaction (avoiding XA) My guess is that the Async 1-phase mode was added to messure the overhead associated with handling the XA transaction. I have never found that much value in Async 1-phase mode. If you are using two different resources as part of a logical transaction, you should always use XA to ensure proper rollback handling. Honestly, I see very little need to keep it around... However, there might be some possiblities I have not considered. As an added benefit of removing this option, we would remove a dependency between the TradeDirect and TradeBean code. I also like the idea of splitting up the modes by category and doing a little renaming to make them more descriptive. Persistence Run-time Modes (one has to be selected) 1) Direct (or JDBC) 2) Stateless Session Bean to Direct 3) Full EJB (Stateless Session Bean to Entity Beans) JMS Support Enablement (any can be selected) - Publish Quote Updates (Publish quote price changes to a JMS topic) - Process Buy/Sell Orders using XA (Asychronously process buy/sell orders by placing them on a JMS queue. An MDB is then responsible for reading a message form the queue and completing the order) Thoughts? -- 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: SVK
I'm not sure what you mean... you are seeing diffs or conflicts? Normally svk will handle trivial diffs like this... so while it will show up as a difference, there is no conflict, smerge should be able to resolve this with no user interaction. Or do you mean something else? --jason On Dec 5, 2006, at 6:26 PM, Tim McConnell wrote: Jason, since you've done this before make you can help me understand to what degree we should strive to keep these files in sync. I notice that many of the differences between Trunk and the new 1.2 Branch are related to omissions of $Rev and $Date in various java, js, jsp, and properties files. Are these entries being added automatically by either SVN or an IDE, and should we bother syncing files with only these differences ?? Thanks Tim Jason Dillon wrote: Yes, this is the best way... merge from 1.2 to trunk, as *most* of those changes will be fairly simple to apply, and automatic with SVK (well, up until the point when we rearrange trunk, but until then). But some minor changes may also need to go the other way. SVK should be able to handle this. When I was working with SVK for the m2 migration branch, I was keeping all svn notifications I got, then when they buffered up enough, I would use SVK to merge each change, limiting the path to either file or src/main/java for the modules affected to avoid pulling in unwanted changes. In the case of the m2 migration, unwanted changes would be stuff in a pom. You could do a merge from the branch root, then cherry pick the changes, but that is not much fun when there are a bunch of changes. Anyways... IMO its best to try to only merge from 1.2 to trunk, and if needed only merge from trunk to 1.2 on a per-file basis. That means if you are working on fixing a bug, its best to fix it in 1.2. But experience has shown that people will work off of trunk and merge into branches more often than desired. But, if you are careful about the merge then no major problems should pop up. I also recommend, when using svk smerge, that you first run with - C to see what it wants to do first. Limit the changes pulled in to one merge if possible to avoid picking up something you did not want. And when you do the merge, use the -I flag to include the original text of the commit into the merge automatically, this makes it easier to track... and more automated... as if there are not conflicts, the merge will not require any user interaction. When you initially setup the svk config you will need to use -- baseless on the first smerge, but only for the first... all afterwards SVK should have enough details to find the base, not sure what will happen if you keep using --baseless, so I don't recommend it. And if you run into anything strange, unlikely but might happen, hope in #svk on freenode and ask, they have been very helpful to me. --jason On Dec 4, 2006, at 4:03 PM, Tim McConnell wrote: Ok, I'm setting up SVK so that we can keep changes between the new 1.2 Branch and Trunk in sync. I don't mean to be too simplistic but I would like to verify these assumptions on my part are correct (before I do anything untoward): 1. The primary intent will be to ensure that changes made in the 1.2 Branch will get merged into Trunk. Ideally these will be fixes and/or enhancements that have been made to the 1.2 Branch that must also be ported into Trunk as well. 2. Changes made to Trunk will NOT be merged into the 1.2 Branch. This should pretty much be business as usual (it would be very difficult to try to identify just code fixes in Trunk that have to be retrofitted back into the 1.2 Branch). This seem reasonable to everyone ?? Thanks much Tim
Re: SVK
On Dec 5, 2006, at 8:34 PM, Vamsavardhana Reddy wrote: One other question... Is it better to commit related changes to branches\1.2 and trunk in a single revision? Does it help in any manner? From an svk perspective it does not matter. --jason
Re: Jetty 6 and JSP 2.1 support
Paul McMahan wrote: On 12/6/06, Joe Bohn [EMAIL PROTECTED] wrote: 2) I'm about to try using the new jasper with jetty. It seems like the web console works fine with the jsp 2.0 support provided by jasper. I think that it should equally do fine with the jsp 2.1 support from jasper. I like this approach because it has worked in the past and gives us some consistency between jetty and tomcat. If it works then that pretty much settles it for me for the 2.0-M1 delivery. However, longer term I'm concerned because it diverges from the path that jetty has taken which means we may be in for problems down the road even if things work fine now. Does anybody know if the current jetty approach is a long-term decision or just a temporary one based upon the lack of jasper 2.1 support when they needed it? If jasper 2.1 works with Jetty then IMO we should use it for 2.0-M1. While this may not match the standalone jetty distribution it gives us some consistency across geronimo assemblies. If someone develops a app using the tomcat assembly it should work on the jetty assembly. A good example is Geronimo's admin console which works on both assemblies (and I hope it stays that way :-) And like you say, now that tomcat has released 6.0.2 beta the jetty guys might be interested in using jasper from that release instead of JSP from glassfish. I just spoke with Greg on IRC and it appears that the jetty decision is a long term decision to use glassfish over jasper. They had concerns with the response (or lack there-of) from the jasper folks and were encouraged by the responses that they were getting from glassfish. He didn't think there would be any issues with using jasper with jetty if we choose to go that route. Joe
[jira] Created: (GERONIMO-2631) jetty5 builder needs to parameterize the jsp servlet class
jetty5 builder needs to parameterize the jsp servlet class -- Key: GERONIMO-2631 URL: http://issues.apache.org/jira/browse/GERONIMO-2631 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: deployment, Jetty Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 The jspServlet class name is hardcoded in the jetty builder gbean. It should be a configurable attribute. -- 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-2631) jetty5 builder needs to parameterize the jsp servlet class
[ http://issues.apache.org/jira/browse/GERONIMO-2631?page=all ] David Jencks closed GERONIMO-2631. -- Resolution: Fixed rev 483251 jetty5 builder needs to parameterize the jsp servlet class -- Key: GERONIMO-2631 URL: http://issues.apache.org/jira/browse/GERONIMO-2631 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment, Jetty Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 The jspServlet class name is hardcoded in the jetty builder gbean. It should be a configurable attribute. -- 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: Geronimo 2.0 Milestone's and how were doing
Hey Paul, I just gave it a quick look. Things went pretty smoothly. Build fine, ran fine, and the console seemed to work fine. As you already mentioned there are a lot of info messages and the stacktraces on terminating the server but these are not unique to tomcat at the moment. The one new thing I noticed was that when I deployed a simple web application (snoop without a plan) via the web console things looked like they went well but I couldn't connect to the application. The URL for the web app looked strange (//snoop rather than just /snoop). Regards, Joe Paul McMahan wrote: On 12/5/06, Paul McMahan [EMAIL PROTECTED] wrote: On 12/5/06, Kevan Miller [EMAIL PROTECTED] wrote: Paul, Tomcat integration might have the most work to do for M1. How is that looking? I have the JSP 2.1 and EL 1.0 specs checked in and published to the snapshot repo, reversioned to 1.0-SNAPSHOT this morning per Jason's advice. The annotation 1.0 and servlet 2.5 specs were already available thanks to Joe and Greg. In my local build I have tc6 running the web console OK in a new tomcat-jee5 assembly and the default app in the tomcat-minimal assembly. Deploying a simple 2.4 WAR from the CLI works. I'm pretty confident that I'll be able to commit this first stage of tomcat integration this week. I just committed stage 2 of the tc6 update. As a reminder here's the wiki page for the overall game plan with progress indicated: http://cwiki.apache.org/GMOxDEV/tomcat-v6-game-plan.html If anyone sees problems then please let me know. Current issues: Deploying 2.5 servlets While tc6 deploys and runs 2.4 WARs ok I haven't tried deploying a 2.5 WAR yet. All the webapps in the tc6 dist use 2.4 so I really hope I'm not the first one trying this :-S I googled up some JEE5 servlet samples but they are tightly coupled with other new JEE5 stuff like JPA, EJB 3.0, etc, so I need something simpler. I'll probably end up adding some 2.5 content to our unit test cases and cross my fingers. Worst case scenario is that for M1 we'll have a 2.5 servlet engine that you can only deploy =2.4. servlets to. Turns out this works OK. I added a testcase to geronimo-tomcat that uses a 2.5 web.xml. Failing unit test- A unit tests in geronimo-tomcat fails intermittently apparently due to a change in how tc6 handles connections. Still investigating if its a bug in geronimo, tomcat or the unit test. For the initial checkin I may need to disable the unit test. I disabled the unit test and am investigating whether the problem is in geronimo, the test case, or in tomcat. Noise factor- Shutdown of the JEE5 assemblies generates a huge stack trace. Looks like tranql/derby is the culpirt and not tomcat but I'm not 100% sure. I'll probably have to commit while the stack trace still appears so others can have a look. Others were seeing this stack trace before I committed and it's in the jetty assembly as well so apparently not due to tc6. Also I need to figure out how to avoid logging tomcat's INFO messages to the command window. Its really noisy right now. Tomcat is still logging INFO messages in the command window and I will fix that asap. I needed to go ahead and check in as-is so others with prereqs on tc6 can proceed with their work (plus I was going nuts keeping up with in trunk :-) Best wishes, Paul
Re: Latest official release
Sorry, i get confused. Currently yes. The 4.1 release is still in voting?. Is it mean that 4.1 still unofficially released? Thanks James.Strachan wrote: On 11/28/06, nabble615 [EMAIL PROTECTED] wrote: Hi, may I know whether the latest official activemq release is 4.0.2? Currently yes. The 4.1 release is still in voting; its looking good so hopefully should pass in the next day or so May I know when is the released date of it as well? Thanks It was released a few weeks ago http://www.nabble.com/-ANN--Apache-ActiveMQ-4.0.2-released%21-tf2627759.html -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Latest-official-release-tf2717760.html#a7729594 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Commented: (GERONIMO-2575) Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs
[ http://issues.apache.org/jira/browse/GERONIMO-2575?page=comments#action_12456249 ] Jay D. McHugh commented on GERONIMO-2575: - Someone please close this JIRA. It is no longer true - The server will now start with Java 1.5 without doing anything special. Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs - Key: GERONIMO-2575 URL: http://issues.apache.org/jira/browse/GERONIMO-2575 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.2 Environment: Sun Java 1.5 Starting the server using the startup scripts Reporter: Jay D. McHugh Starting the server using the scripts with Java 1.5 fails Here is the log: Using GERONIMO_BASE: /opt/geronimo Using GERONIMO_HOME: /opt/geronimo Using GERONIMO_TMPDIR: /opt/geronimo/var/temp Using JRE_HOME:/opt/jdk1.5.0_06/jre Using GERONIMO_OUT:/opt/geronimo/var/log/geronimo.out Geronimo started in background. PID: 5689 Booting Geronimo Kernel (in Java 1.5.0_06)... 21:40:50,620 INFO [root] -- 21:40:50,641 INFO [root] Started Logging Service 21:40:50,641 INFO [root] Runtime Information: 21:40:50,641 INFO [root] Install Directory = /opt/geronimo-tomcat-j2ee-1.2-SNAPSHOT 21:40:50,642 INFO [root] JVM in use = Sun Microsystems Inc. Java 1.5.0_06 21:40:50,642 INFO [root] Java Information: 21:40:50,642 INFO [root] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 21:40:50,643 INFO [root] System property [java.runtime.version] = 1.5.0_06-b05 21:40:50,643 INFO [root] System property [os.name] = Linux 21:40:50,643 INFO [root] System property [os.version] = 2.6.15.1 21:40:50,644 INFO [root] System property [sun.os.patch.level] = unknown 21:40:50,644 INFO [root] System property [os.arch] = i386 21:40:50,644 INFO [root] System property [java.class.version] = 49.0 21:40:50,644 INFO [root] System property [locale] = en_US 21:40:50,645 INFO [root] System property [unicode.encoding]= UnicodeLittle 21:40:50,645 INFO [root] System property [file.encoding] = ANSI_X3.4-1968 21:40:50,645 INFO [root] System property [java.vm.name]= Java HotSpot(TM) Client VM 21:40:50,646 INFO [root] System property [java.vm.vendor] = Sun Microsystems Inc. 21:40:50,646 INFO [root] System property [java.vm.version] = 1.5.0_06-b05 21:40:50,646 INFO [root] System property [java.vm.info]= mixed mode 21:40:50,647 INFO [root] System property [java.home] = /opt/jdk1.5.0_06/jre 21:40:50,647 INFO [root] System property [java.classpath] = null 21:40:50,647 INFO [root] System property [java.library.path] = /opt/jdk1.5.0_06/jre/lib/i386/client:/opt/jdk1.5.0_06/jre/lib/i386:/opt/jdk1.5.0_06/jre/../lib/i386 21:40:50,647 INFO [root] System property [java.endorsed.dirs] = /opt/jdk1.5.0_06/jre/lib/endorsed:/opt/geronimo/lib/endorsed 21:40:50,648 INFO [root] System property [java.ext.dirs] = /opt/jdk1.5.0_06/jre/lib/ext:/opt/geronimo/lib/ext 21:40:50,648 INFO [root] System property [sun.boot.class.path] = /opt/geronimo/lib/endorsed/yoko-spec-corba-1.0-incubating-M1-SNAPSHOT.jar:/opt/geronimo/lib/endorsed/xercesImpl-2.6.2.jar:/opt/geronimo/lib/endorsed/yoko-rmi-1.0-incubating-M1-SNAPSHOT.jar:/opt/geronimo/lib/endorsed/xmlParserAPIs-2.6.2.jar:/opt/jdk1.5.0_06/jre/lib/rt.jar:/opt/jdk1.5.0_06/jre/lib/i18n.jar:/opt/jdk1.5.0_06/jre/lib/sunrsasign.jar:/opt/jdk1.5.0_06/jre/lib/jsse.jar:/opt/jdk1.5.0_06/jre/lib/jce.jar:/opt/jdk1.5.0_06/jre/lib/charsets.jar:/opt/jdk1.5.0_06/jre/classes 21:40:50,648 INFO [root] -- Module 1/23 org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car started in 1.187s Module 2/23 org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/car started in .540s Module 3/23 org.apache.geronimo.configs/transaction/1.2-SNAPSHOT/car started in 1.066s Module 4/23 org.apache.geronimo.configs/j2ee-security/1.2-SNAPSHOT/car started in 1.904s Module 5/23 org.apache.geronimo.configs/axis/1.2-SNAPSHOT/car started in .309s Module 6/23 org.apache.geronimo.configs/openejb/1.2-SNAPSHOT/car Exception in thread Timer-0 javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found at javax.xml.transform.TransformerFactory.newInstance(Unknown Source) at org.apache.geronimo.kernel.util.XmlUtil.newTransformerFactory(XmlUtil.java:95) at
steps to publish to a topic for BrokerFilter-based classes?
Hello, I'm working on a Broker interceptor class that extends BrokerFilter. After processing an incoming message, I would like to publish to a topic that is determined from the content of the message. My question is: is there a quicker way to publish to a topic from a Broker than the standard method a client uses to publish (getting connection, TopicSession, TopicPublisher, and then using the TopicPublisher to publish)? Thanks! -- J. Patrick Bedell [EMAIL PROTECTED] http://infoeng.sourceforge.net http://rothbardix.blogspot.com
Re: [jira] Commented: (GERONIMO-2575) Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs
done. --jason On Dec 6, 2006, at 3:02 PM, Jay D. McHugh (JIRA) wrote: [ http://issues.apache.org/jira/browse/GERONIMO-2575? page=comments#action_12456249 ] Jay D. McHugh commented on GERONIMO-2575: - Someone please close this JIRA. It is no longer true - The server will now start with Java 1.5 without doing anything special. Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs - Key: GERONIMO-2575 URL: http://issues.apache.org/jira/browse/ GERONIMO-2575 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.2 Environment: Sun Java 1.5 Starting the server using the startup scripts Reporter: Jay D. McHugh Starting the server using the scripts with Java 1.5 fails Here is the log: Using GERONIMO_BASE: /opt/geronimo Using GERONIMO_HOME: /opt/geronimo Using GERONIMO_TMPDIR: /opt/geronimo/var/temp Using JRE_HOME:/opt/jdk1.5.0_06/jre Using GERONIMO_OUT:/opt/geronimo/var/log/geronimo.out Geronimo started in background. PID: 5689 Booting Geronimo Kernel (in Java 1.5.0_06)... 21:40:50,620 INFO [root] -- 21:40:50,641 INFO [root] Started Logging Service 21:40:50,641 INFO [root] Runtime Information: 21:40:50,641 INFO [root] Install Directory = /opt/geronimo- tomcat-j2ee-1.2-SNAPSHOT 21:40:50,642 INFO [root] JVM in use = Sun Microsystems Inc. Java 1.5.0_06 21:40:50,642 INFO [root] Java Information: 21:40:50,642 INFO [root] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 21:40:50,643 INFO [root] System property [java.runtime.version] = 1.5.0_06-b05 21:40:50,643 INFO [root] System property [os.name] = Linux 21:40:50,643 INFO [root] System property [os.version] = 2.6.15.1 21:40:50,644 INFO [root] System property [sun.os.patch.level] = unknown 21:40:50,644 INFO [root] System property [os.arch] = i386 21:40:50,644 INFO [root] System property [java.class.version] = 49.0 21:40:50,644 INFO [root] System property [locale] = en_US 21:40:50,645 INFO [root] System property [unicode.encoding] = UnicodeLittle 21:40:50,645 INFO [root] System property [file.encoding] = ANSI_X3.4-1968 21:40:50,645 INFO [root] System property [java.vm.name] = Java HotSpot(TM) Client VM 21:40:50,646 INFO [root] System property [java.vm.vendor] = Sun Microsystems Inc. 21:40:50,646 INFO [root] System property [java.vm.version] = 1.5.0_06-b05 21:40:50,646 INFO [root] System property [java.vm.info] = mixed mode 21:40:50,647 INFO [root] System property [java.home] = /opt/jdk1.5.0_06/jre 21:40:50,647 INFO [root] System property [java.classpath] = null 21:40:50,647 INFO [root] System property [java.library.path] = /opt/jdk1.5.0_06/jre/lib/i386/client:/opt/jdk1.5.0_06/jre/lib/ i386:/opt/jdk1.5.0_06/jre/../lib/i386 21:40:50,647 INFO [root] System property [java.endorsed.dirs] = /opt/jdk1.5.0_06/jre/lib/endorsed:/opt/geronimo/lib/endorsed 21:40:50,648 INFO [root] System property [java.ext.dirs] = /opt/jdk1.5.0_06/jre/lib/ext:/opt/geronimo/lib/ext 21:40:50,648 INFO [root] System property [sun.boot.class.path] = /opt/geronimo/lib/endorsed/yoko-spec-corba-1.0-incubating-M1- SNAPSHOT.jar:/opt/geronimo/lib/endorsed/xercesImpl-2.6.2.jar:/opt/ geronimo/lib/endorsed/yoko-rmi-1.0-incubating-M1-SNAPSHOT.jar:/opt/ geronimo/lib/endorsed/xmlParserAPIs-2.6.2.jar:/opt/jdk1.5.0_06/jre/ lib/rt.jar:/opt/jdk1.5.0_06/jre/lib/i18n.jar:/opt/jdk1.5.0_06/jre/ lib/sunrsasign.jar:/opt/jdk1.5.0_06/jre/lib/jsse.jar:/opt/ jdk1.5.0_06/jre/lib/jce.jar:/opt/jdk1.5.0_06/jre/lib/charsets.jar:/ opt/jdk1.5.0_06/jre/classes 21:40:50,648 INFO [root] -- Module 1/23 org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car started in 1.187s Module 2/23 org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/ carstarted in .540s Module 3/23 org.apache.geronimo.configs/transaction/1.2-SNAPSHOT/ carstarted in 1.066s Module 4/23 org.apache.geronimo.configs/j2ee-security/1.2- SNAPSHOT/car started in 1.904s Module 5/23 org.apache.geronimo.configs/axis/1.2-SNAPSHOT/ car started in .309s Module 6/23 org.apache.geronimo.configs/openejb/1.2-SNAPSHOT/ car Exception in thread Timer-0 javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found at javax.xml.transform.TransformerFactory.newInstance (Unknown Source) at
[jira] Closed: (GERONIMO-2575) Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs
[ http://issues.apache.org/jira/browse/GERONIMO-2575?page=all ] Jason Dillon closed GERONIMO-2575. -- Resolution: Invalid Server will now boot with 1.5 just fine Starting Geronimo using Java 1.5 fails - Issue with xmlParserAPIs - Key: GERONIMO-2575 URL: http://issues.apache.org/jira/browse/GERONIMO-2575 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Affects Versions: 1.2 Environment: Sun Java 1.5 Starting the server using the startup scripts Reporter: Jay D. McHugh Starting the server using the scripts with Java 1.5 fails Here is the log: Using GERONIMO_BASE: /opt/geronimo Using GERONIMO_HOME: /opt/geronimo Using GERONIMO_TMPDIR: /opt/geronimo/var/temp Using JRE_HOME:/opt/jdk1.5.0_06/jre Using GERONIMO_OUT:/opt/geronimo/var/log/geronimo.out Geronimo started in background. PID: 5689 Booting Geronimo Kernel (in Java 1.5.0_06)... 21:40:50,620 INFO [root] -- 21:40:50,641 INFO [root] Started Logging Service 21:40:50,641 INFO [root] Runtime Information: 21:40:50,641 INFO [root] Install Directory = /opt/geronimo-tomcat-j2ee-1.2-SNAPSHOT 21:40:50,642 INFO [root] JVM in use = Sun Microsystems Inc. Java 1.5.0_06 21:40:50,642 INFO [root] Java Information: 21:40:50,642 INFO [root] System property [java.runtime.name] = Java(TM) 2 Runtime Environment, Standard Edition 21:40:50,643 INFO [root] System property [java.runtime.version] = 1.5.0_06-b05 21:40:50,643 INFO [root] System property [os.name] = Linux 21:40:50,643 INFO [root] System property [os.version] = 2.6.15.1 21:40:50,644 INFO [root] System property [sun.os.patch.level] = unknown 21:40:50,644 INFO [root] System property [os.arch] = i386 21:40:50,644 INFO [root] System property [java.class.version] = 49.0 21:40:50,644 INFO [root] System property [locale] = en_US 21:40:50,645 INFO [root] System property [unicode.encoding]= UnicodeLittle 21:40:50,645 INFO [root] System property [file.encoding] = ANSI_X3.4-1968 21:40:50,645 INFO [root] System property [java.vm.name]= Java HotSpot(TM) Client VM 21:40:50,646 INFO [root] System property [java.vm.vendor] = Sun Microsystems Inc. 21:40:50,646 INFO [root] System property [java.vm.version] = 1.5.0_06-b05 21:40:50,646 INFO [root] System property [java.vm.info]= mixed mode 21:40:50,647 INFO [root] System property [java.home] = /opt/jdk1.5.0_06/jre 21:40:50,647 INFO [root] System property [java.classpath] = null 21:40:50,647 INFO [root] System property [java.library.path] = /opt/jdk1.5.0_06/jre/lib/i386/client:/opt/jdk1.5.0_06/jre/lib/i386:/opt/jdk1.5.0_06/jre/../lib/i386 21:40:50,647 INFO [root] System property [java.endorsed.dirs] = /opt/jdk1.5.0_06/jre/lib/endorsed:/opt/geronimo/lib/endorsed 21:40:50,648 INFO [root] System property [java.ext.dirs] = /opt/jdk1.5.0_06/jre/lib/ext:/opt/geronimo/lib/ext 21:40:50,648 INFO [root] System property [sun.boot.class.path] = /opt/geronimo/lib/endorsed/yoko-spec-corba-1.0-incubating-M1-SNAPSHOT.jar:/opt/geronimo/lib/endorsed/xercesImpl-2.6.2.jar:/opt/geronimo/lib/endorsed/yoko-rmi-1.0-incubating-M1-SNAPSHOT.jar:/opt/geronimo/lib/endorsed/xmlParserAPIs-2.6.2.jar:/opt/jdk1.5.0_06/jre/lib/rt.jar:/opt/jdk1.5.0_06/jre/lib/i18n.jar:/opt/jdk1.5.0_06/jre/lib/sunrsasign.jar:/opt/jdk1.5.0_06/jre/lib/jsse.jar:/opt/jdk1.5.0_06/jre/lib/jce.jar:/opt/jdk1.5.0_06/jre/lib/charsets.jar:/opt/jdk1.5.0_06/jre/classes 21:40:50,648 INFO [root] -- Module 1/23 org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car started in 1.187s Module 2/23 org.apache.geronimo.configs/j2ee-server/1.2-SNAPSHOT/car started in .540s Module 3/23 org.apache.geronimo.configs/transaction/1.2-SNAPSHOT/car started in 1.066s Module 4/23 org.apache.geronimo.configs/j2ee-security/1.2-SNAPSHOT/car started in 1.904s Module 5/23 org.apache.geronimo.configs/axis/1.2-SNAPSHOT/car started in .309s Module 6/23 org.apache.geronimo.configs/openejb/1.2-SNAPSHOT/car Exception in thread Timer-0 javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found at javax.xml.transform.TransformerFactory.newInstance(Unknown Source) at org.apache.geronimo.kernel.util.XmlUtil.newTransformerFactory(XmlUtil.java:95) at org.apache.geronimo.kernel.util.XmlUtil.newTransformerFactory(XmlUtil.java:79) at
How to build devtools/eclipse-plugin?
Is there any special requirements to build this puppy? Does Eclipse need to be installed or something? I'm asking first... have not actually tried yet... but would like to hook this up to automatically build if possible. --jason
[jira] Assigned: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Jeff Puro reassigned SM-762: Assignee: Jeff Puro Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Work on SM-762 started by Jeff Puro. Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Jeff Puro updated SM-762: - Attachment: servicemix-http-host-port-scheme.patch This patch uses the request.getScheme() method to determine the protocol. I have attached an alternative that uses request.isSecure() since that is used elsewhere in the servicemix-http component. Either one should work. Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=all ] Jeff Puro updated SM-762: - Attachment: servicemix-http-host-port-is-secure.patch The attached patch uses the isSecure() method to determine the protocol (http or https) as used in other places in servicemix-http. Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-762) Address in WSDL is incorrectly adding the protocol information in the begining of the URL
[ https://issues.apache.org/activemq/browse/SM-762?page=comments#action_37640 ] Jeff Puro commented on SM-762: -- I have attached two different patches. Either one will resolve the issue. It is up to the commiter to decide which to use: 1) The first one uses the request.getScheme() method to determine the protocol. 2) The second one uses the isSecure() method to determine the protocol (http or https) as used in other places in servicemix-http. Address in WSDL is incorrectly adding the protocol information in the begining of the URL - Key: SM-762 URL: https://issues.apache.org/activemq/browse/SM-762 Project: ServiceMix Issue Type: Bug Components: servicemix-http Affects Versions: 3.0.1 Reporter: Jeff Puro Assigned To: Jeff Puro Fix For: 3.0.1 Attachments: servicemix-http-host-port-is-secure.patch, servicemix-http-host-port-scheme.patch Original Estimate: 30 minutes Remaining Estimate: 30 minutes Here is an example of the error when generating the WSDL: service name=HttpService port binding=tns:nullBinding wsdlsoap:address location=HTTP/1.1://10.0.102.12:8080/servicemix-web/jbi/tracker// /port /service -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
CMP failures in 2.3 (was: Openjeb itests - 552 tests, 2 failures, 2 errors)
On Dec 6, 2006, at 12:38 PM, Prasad Kashyap wrote: We are now down to just 2 failures and 2 errors on the Openejb-2.3 itests. The stack trace is here -- http://rifers.org/paste/show/2622 org.apache.openejb.test.TestFailureException : null; nested exception is: junit.framework.AssertionFailedError: Should have thrown DuplicateKeyException at junit.framework.Assert.fail(Assert.java:47) at org.apache.openejb.test.entity.cmp.CmpTransactionTests.testInvokeCreateC reateSameCMP(CmpTransactionTests.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Transaction.testInvokeCreateFindForceCacheFlush Time elapsed: 0.32 sec FAILURE! junit.framework.AssertionFailedError: Received Exception class org.apache.openejb.test.TestFailureException : null; nested exception is: junit.framework.AssertionFailedError: expected:1 but was:0 at junit.framework.Assert.fail(Assert.java:47) at org.apache.openejb.test.entity.cmp.CmpTransactionTests.testInvokeCreateF indForceCacheFlush(CmpTransactionTests.java:83) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 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.test OneToManyDoNotSetCMR(CMRMappingFacadeBean.java:245) at org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean$ $FastClassByCGLIB$$9687c6d6.invoke(generated) 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.test OneToOneDoNotSetCMR(CMRMappingFacadeBean.java:137) at org.apache.openejb.test.entity.cmp2.cmrmapping.CMRMappingFacadeBean$ $FastClassByCGLIB$$9687c6d6.invoke(generated) 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
[jira] Created: (GERONIMO-2632) Connection errors can result in infinite loop
Connection errors can result in infinite loop - Key: GERONIMO-2632 URL: http://issues.apache.org/jira/browse/GERONIMO-2632 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: connector Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 We have a GeronimoConnectionEventListener that always tries to return the connection with a DESTROY action. Well, if the connection is sufficiently broken, trying to close it might cause another ConnectionError event.. leading to infinite recursion. I'm putting in a flag so only the first ConnectionError event causes the connection to get destroyed. Also, there isn't really any point in calling cleanup on a managed connection we're about to destroy. Just another way to try to provoke another connection error. -- 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: Latest official release
4.1.0 has been officially released :-) -Brian On Dec 6, 2006, at 2:40 PM, bluedolphin wrote: Sorry, i get confused. Currently yes. The 4.1 release is still in voting?. Is it mean that 4.1 still unofficially released? Thanks James.Strachan wrote: On 11/28/06, nabble615 [EMAIL PROTECTED] wrote: Hi, may I know whether the latest official activemq release is 4.0.2? Currently yes. The 4.1 release is still in voting; its looking good so hopefully should pass in the next day or so May I know when is the released date of it as well? Thanks It was released a few weeks ago http://www.nabble.com/-ANN--Apache-ActiveMQ-4.0.2-released%21- tf2627759.html -- James --- http://radio.weblogs.com/0112098/ -- View this message in context: http://www.nabble.com/Latest-official- release-tf2717760.html#a7729594 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] Closed: (GERONIMO-2632) Connection errors can result in infinite loop
[ http://issues.apache.org/jira/browse/GERONIMO-2632?page=all ] David Jencks closed GERONIMO-2632. -- Resolution: Fixed Fixed in rev 483310. in trunk only Connection errors can result in infinite loop - Key: GERONIMO-2632 URL: http://issues.apache.org/jira/browse/GERONIMO-2632 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 2.0 We have a GeronimoConnectionEventListener that always tries to return the connection with a DESTROY action. Well, if the connection is sufficiently broken, trying to close it might cause another ConnectionError event.. leading to infinite recursion. I'm putting in a flag so only the first ConnectionError event causes the connection to get destroyed. Also, there isn't really any point in calling cleanup on a managed connection we're about to destroy. Just another way to try to provoke another connection error. -- 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-2633) SVK synchronization patch for 12-06-2006
SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor -- 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-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Attachment: GERONIMO-2633.patch SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.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-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Description: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.xml SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.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] Created: (GERONIMO-2634) Switch to activemq 4.1.0-incubator: include apache incubator repo in our repo list.
Switch to activemq 4.1.0-incubator: include apache incubator repo in our repo list. --- Key: GERONIMO-2634 URL: http://issues.apache.org/jira/browse/GERONIMO-2634 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.2, 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 2.0 Activemq 4.1.0-incubator is released. To pull it in we need to add the apache incubator repo to our repo list. -- 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-2634) Switch to activemq 4.1.0-incubator: include apache incubator repo in our repo list.
[ http://issues.apache.org/jira/browse/GERONIMO-2634?page=all ] David Jencks closed GERONIMO-2634. -- Resolution: Fixed trunk rev 483315 1.2 rev 483318 Switch to activemq 4.1.0-incubator: include apache incubator repo in our repo list. --- Key: GERONIMO-2634 URL: http://issues.apache.org/jira/browse/GERONIMO-2634 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2, 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 2.0 Activemq 4.1.0-incubator is released. To pull it in we need to add the apache incubator repo to our repo list. -- 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-2635) Upgrade to JavaMail 1.4 and JavaBeans Activation Framework 1.1
Upgrade to JavaMail 1.4 and JavaBeans Activation Framework 1.1 -- Key: GERONIMO-2635 URL: http://issues.apache.org/jira/browse/GERONIMO-2635 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: mail Affects Versions: 2.0 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Fix For: 2.0 Need to upgrade to JavaMail 1.4 (JSR 919) and JavaBeans Activation Framework 1.1 (JSR 925) for JEE 5 compliance. -- 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: How to build devtools/eclipse-plugin?
Hi Jason, it builds fine for me just using the mvn clean install command. I have Eclipse installed but don't think that matters... Tim Jason Dillon wrote: Is there any special requirements to build this puppy? Does Eclipse need to be installed or something? I'm asking first... have not actually tried yet... but would like to hook this up to automatically build if possible. --jason
[jira] Commented: (GERONIMO-2635) Upgrade to JavaMail 1.4 and JavaBeans Activation Framework 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-2635?page=comments#action_12456283 ] Christopher M. Cardona commented on GERONIMO-2635: -- trunk - Revision: 483324 Upgrade to JavaMail 1.4 and JavaBeans Activation Framework 1.1 -- Key: GERONIMO-2635 URL: http://issues.apache.org/jira/browse/GERONIMO-2635 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: mail Affects Versions: 2.0 Reporter: Christopher M. Cardona Assigned To: Christopher M. Cardona Fix For: 2.0 Need to upgrade to JavaMail 1.4 (JSR 919) and JavaBeans Activation Framework 1.1 (JSR 925) for JEE 5 compliance. -- 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-2633) SVK synchronization patch for 12-06-2006
[ http://issues.apache.org/jira/browse/GERONIMO-2633?page=all ] Tim McConnell updated GERONIMO-2633: Description: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties: -- $Rev added Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- xalan, xerces artifactItems added was: Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties Index: assemblies/geronimo-boilerplate-minimal/pom.xml SVK synchronization patch for 12-06-2006 Key: GERONIMO-2633 URL: http://issues.apache.org/jira/browse/GERONIMO-2633 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Tim McConnell Assigned To: Tim McConnell Priority: Minor Attachments: GERONIMO-2633.patch Minor synchronization updates to the following files to keep Branch 1.2 and Trunk in synch: Index: applications/console/geronimo-console-standard/src/main/webapp/WEB-INF/classes/login-modules.properties: -- $Rev added Index: assemblies/geronimo-boilerplate-minimal/pom.xml -- xalan, xerces artifactItems added -- 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: steps to publish to a topic for BrokerFilter-based classes?
Hi Patrick,
What I could suggest is to use JmsTemplate to send messages and possibly
Spring based configurations. See unit test SpringTest.java and
SpringProducer.java located in
${activemq.source.home}\activemq-core\src\test\java\org\apache\activemq\spring\
for reference.
Regards,
Fritz
- Original Message -
From: J. Patrick Bedell [EMAIL PROTECTED]
To: activemq-dev@geronimo.apache.org
Sent: Thursday, December 07, 2006 7:04 AM
Subject: steps to publish to a topic for BrokerFilter-based classes?
Hello,
I'm working on a Broker interceptor class that extends BrokerFilter.
After processing an incoming message, I would like to publish to a
topic that is determined from the content of the message.
My question is: is there a quicker way to publish to a topic from a
Broker than the standard method a client uses to publish (getting
connection, TopicSession, TopicPublisher, and then using the
TopicPublisher to publish)?
Thanks!
--
J. Patrick Bedell
[EMAIL PROTECTED]
http://infoeng.sourceforge.net
http://rothbardix.blogspot.com
Re: Jetty 6 and JSP 2.1 support
David Jencks wrote: On Dec 6, 2006, at 1:27 PM, David Jencks wrote: On Dec 6, 2006, at 1:01 PM, Joe Bohn wrote: Jetty 6 as currently integrated in trunk is still using the JSP 2.0 support from jasper (tomcat 5.5.15). To support jetty for the 2.0-M1 milestone we will need a JSP 2.1 implementation. I half thought about just shipping with the jsp 2.0 for jetty in 2.0- M1 but the console and other jsp apps. will break when I update the assemblies to include JSTL 1.2 from glassfish which requires a JSP 2.1 implementation. There are a few choices here (details below): 1) Use the JSP supported provided by jetty. 2) Use jasper from tomcat 6 3) Don't deliver jetty with 2.0-M1 1) I gate the JSP support in jetty a try. AFAIK, jetty is actually picking up modules from glassfish and repackaging these in their build (can anybody confirm or deny this?). I may have a few things wrong but my initial attempt to use the jsp 2.1 jars delivered by jetty didn't go well. You can see the stack traces in the attached file. I haven't dug into the method errors yet and I'm not sure if it is worth the effort (see #2). I think the problem might be the jetty 6 module builder line 983 where the jasper servlet name is hardcoded: servletData.setAttribute(servletClass, org.apache.jasper.servlet.JspServlet); This should be an attribute on the builder. I'll fix it shortly. Also the default jsp servlet in the jetty6-deployer plan.xml most likely needs the same change: gbean name=JSPServlet class=org.apache.geronimo.jetty6.JettyDefaultServletHolder attribute name=servletNamejsp/attribute attribute name=servletClassorg.apache.jasper.servlet.JspServlet/attribute attribute name=loadOnStartup0/attribute attribute name=initParams development=false fork=false logVerbosityLevel=DEBUG xpoweredBy=false /attribute attribute name=servletMappings*.jsp,*.jspf,*.jspx,*.xsp/attribute /gbean Done, see GERONIMO-2631 and rev 483251. Thanks David. I think having this as a parameter is great but I'm not sure if it was the cause of the problem. The jsp-2.1.jar from jetty includes many of the same classes from jasper including org.apache.jasper.servlet.JspServlet so I was assuming this didn't have to change. 2) I'm about to try using the new jasper with jetty. It seems like the web console works fine with the jsp 2.0 support provided by jasper. I think that it should equally do fine with the jsp 2.1 support from jasper. I like this approach because it has worked in the past and gives us some consistency between jetty and tomcat. If it works then that pretty much settles it for me for the 2.0-M1 delivery. However, longer term I'm concerned because it diverges from the path that jetty has taken which means we may be in for problems down the road even if things work fine now. Does anybody know if the current jetty approach is a long-term decision or just a temporary one based upon the lack of jasper 2.1 support when they needed it? We'll have to ping greg. See my response to Paul for what I learned from Greg on IRC. I had a lot more success with my quick attempt to get jetty 6 working with jasper from tomcat 6. I may check this in as an initial approach so that I can go ahead an try out the glassfish jstl. Do you have any objections to that? I'll dig into the jetty errors some more after I get a warm fuzzy on JSTL. 3) It is certainly the easiest approach to only deliver tomcat for 2.0-M1. I'm not sure how others feel about it. I don't want to open the whole multiple-container can of worms ... but it sure does complicate things trying to support both tomcat and jetty. OK, lets drop tomcat :-) The easiest approach is to deliver only jetty6 for 2.0-M1, it's already implemented. Please let me know your thoughts. I think we should continue to support both servlet containers. I also think we should put the jsp support jars (jasper/ glassfish equivalent) into a configuration so we can swap them in a server without rebuilding e.g the jetty_6 configuration to change its dependencies. I'll look into this as well. Thanks! Joe
Re: MyFaces 1.2 SNAPSHOT update
Question: Does anyone have an example of a either a new JAR or an updated JAR that is being integrated in this first Milestone ?? Reason I ask is that I have the JSF jars integrated fine in the build, but just want to verify that I have changed everything that should be changed before I try to deploy (and use) a simple web application which uses JSF. An example for reference might be useful for that verification/validation. Thanks Tim Tim McConnell wrote: Looks like the MyFaces build 1.2 is using Continuum to automate their builds. It's supposed to automatically publish their snapshots but they have discovered after my query that it's doing a 'mvn install' instead of an 'mvn deploy'. So that's been fixed. Unfortunately though the MyFaces 1.2 build on Continuum isn't working although I can build it fine. More information to follow Thanks. Tim
[STATUS] (geronimo) Wed Dec 6 23:47:12 2006
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2006-11-05 18:03:59 -0500 (Sun, 05 Nov 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS Upcoming Releases: Geronimo 1.2 -- geronimo/server/trunk/ Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: Q4 2006 RELEASE SHOWSTOPPERS: Certification - Historically certification has been the most time consuming portion of a release, and there is no reason to expect it to be any different for this release. To make matters worse, the certification test suite was not run for several months while major changes were made to the build, EJB, Transaction, Connector and Servlet Session. In the last two weeks we have gotten the TCK running and using Maven 2, and have made good progress on the test suite. Additionally, the GBuild servers are back online and processing some tests. There are stability issues with GBuild but we are hopeful it will be fully running soon. Currently, the biggest concerns for the TCK are ActiveMQ 4 and Yoko. Both of these are new libraries and may take a considerable amount of effort to certify. Also, there are few people that understand these new libraries, the geronimo integrations, and the TCK. In the case of ActiveMQ, the one person that understands that can certify the code, is unavailable for the next two weeks. Fit and Finish - This is another item that has historically taken a significant amount of time to complete. A process has been started to tie up the loose ends in the software so it can be released. Dead 1.2 - There are still 26 unmerged commits the dead 1.2 branch. These commits must be merged before the 1.2 release. The current status of the dead-1.2 changes can be found at http://svn.apache.org/repos/asf/geronimo/server/trunk/all_changes.log PENDING PATCHES: GERONIMO-2485 PersistenceUnitGBean needs a NamespaceDrivenDeployer GERONIMO-1277 Change group-id to org.apache.geronimo Status: New proposal by Jason Dillon to change base the groupId to org.apache.geronimo.server GERONIMO-2015 Let's replace JKS to PKCS12 key store type - Opened Status: No active discussion GERONIMO-2409 Provide config/module aliasing ability Status: 3 +1 votes GERONIMO-2413 Add a Certification Authority (CA) portlet to Geronimo console Status: Not reviewed RELEASE HISTORY: 2006-09-18 Geronimo 1.1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
