rename the "configuration" element in config.xml file ?
I noticed we still have a "configuration" element in the config.xml file. I am thinking of doing the following for 1.1: * most importantly, change the "configuration" element name to "module" to have consistent terminology considering the recent configId changes. * update cmd line help for --override option in Daemon to use "module" terminology. * update the wording in the var\config\README.txt to use the "module" terminology. * change the --long startup output to use the word "Module" instead of "Configuration" - also give us a bit more room on each line. Any objections? John
Re: XA_RDONLY optimization - question
David, 1. there's only one resource in the transaction. Well, you can just call 1pc commit on it. As a special case, if there are lots of resources, but all but the last one says it's read-only, you can just call 1pc commit on the last one (skipping prepare). I think it's sort of obvious this works, and doesn't introduce any risks of data loss. I agree on this but running the prepare calls in parallel voids the special case of the last resource returning read-only. 2. if your last resource only supports 1pc (it's not xa) some people think you can just call commit on it, and then write the prepare record for the other participants: you use the result of this 1pc commit to decide whether to proceed or roll back the other participants. A little thought shows that the time between the completion of the 1pc commit and writing the prepare record to the log is vulnerable and can result in inconsistency. (many people don't seem to realize this). This is what Mike calls 'Last Resource Gambit'. It's main usage is to allow non-XA resources to participate in 2PC, it has very little to do with transaction speed optimization. I personally refuse to use that trick since it's not ACID. However, there's a trick that can make it work :-) If you store the transaction log in the 1pc resource, and only do the commit as a part of writing the prepare record to the log (ignoring the 1pc commit call directly to the resource) then the semantics work out properly. AFAIK Jeremy Boynes thought this up, and I've implemented it in geronimo, but so far there is no testing of it. BEA implemented this in Weblogic 9 and called it 'Logging Last Resource' (http://edocs.bea.com/wls/docs90/jta/llr.html). The good points of this technique are that you can use a non-XA resource in 2PC while staying 100% ACID and you get a slight performance boost if you only use 2 resources in the transaction. The bad points are that if you use more than 2 resources this method is slower than using a file based tx log and also it messes up a bit your DB schema since you have to create some tx log table(s) in the same DB schema. It also can only work if the resource is a database. So if I properly deciphered your email, the XA_RDONLY vote is pretty much useless since it only allows a 1PC optimization on the last resource to be prepared and only if your don't run prepare calls in parallel. Am I right ? Thank you, Ludovic
[jira] Updated: (GERONIMO-1786) JMS Listeners for protocols activeio, peer and openwire fail to start
[ http://issues.apache.org/jira/browse/GERONIMO-1786?page=all ] Donald Woods updated GERONIMO-1786: --- Fix Version: 1.2 Need ActiveMQ v4 to fix this... > JMS Listeners for protocols activeio, peer and openwire fail to start > - > > Key: GERONIMO-1786 > URL: http://issues.apache.org/jira/browse/GERONIMO-1786 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: ActiveMQ, console > Versions: 1.0, 1.2, 1.1 > Environment: Geronimo 1.0.0 > Reporter: Donald Woods > Fix For: 1.2 > > Even though addition of JMS Listeners for activeio, peer and openwire > protocols is successful, the listeners fail to > start with the following exceptions. > activeio --- java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > openwire --- javax.jms.JMSException: Could not load protocol: openwire. > Reason: java.lang.ClassNotFoundException: > org.activemq.transport.openwire.OpenWireTransportServerChannelFactory > peer --- javax.jms.JMSException: Could not load protocol: peer. Reason: > java.lang.ClassNotFoundException: > org.activemq.transport.peer.PeerTransportServerChannelFactory > Stack trace of the same. > 192: 14:17:49,499 ERROR [GBeanInstanceState] Error while starting; GBean is > now in the FAILED state: > objectName="geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.0/car,J2EEServer=geronimo,br > oker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.12340-aio" > 193: java.lang.NoSuchMethodError: org.activeio.ChannelFactory: method > bindAsynchChannel(Ljava/net/URI;)Lorg/activeio/AsynchChannelServer; not found > 194: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.createAsynchChannelServer(ActiveIOTranspo > rtServerChannelFactory.java:60) > 195: at > org.activemq.transport.activeio.ActiveIOTransportServerChannelFactory.create(ActiveIOTransportServerChannelFact > ory.java:49) > 196: at > org.activemq.transport.TransportServerChannelProvider.create(TransportServerChannelProvider.java:45) > 197: at > org.activemq.broker.impl.BrokerConnectorImpl.createTransportServerChannel(BrokerConnectorImpl.java:425) > 198: at > org.activemq.broker.impl.BrokerConnectorImpl.(BrokerConnectorImpl.java:69) > 199: at > org.activemq.gbean.ActiveMQConnectorGBean.createBrokerConnector(ActiveMQConnectorGBean.java:161) > 200: at > org.activemq.gbean.ActiveMQConnectorGBean.doStart(ActiveMQConnectorGBean.java:129) > 201: at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java(Compiled > Code)) > 202: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) > 203: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) > 204: at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) > 205: at > org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) > 206: at > org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) > 207: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor$StartRecursiveInvoke.invoke(ProxyMethodInterceptor.java > :365) > 208: at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > 209: at > org.activemq.gbean.ActiveMQConnector$$EnhancerByCGLIB$$2b4c85ae.startRecursive() > 210: at > org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:79) > 211: at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) > 212: at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > 213: at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > 214: at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > 215: at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > 216: at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) > 217: at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) > 218: at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) > 219: at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574) > 220: at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) > 221: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) > 222: at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) > 223: at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) > 224:
[jira] Updated: (GERONIMO-1762) Create a derby network /embedded XA datasource via admin console fail
[ http://issues.apache.org/jira/browse/GERONIMO-1762?page=all ] Donald Woods updated GERONIMO-1762: --- Fix Version: 1.1 Version: 1.0 1.1 > Create a derby network /embedded XA datasource via admin console fail > - > > Key: GERONIMO-1762 > URL: http://issues.apache.org/jira/browse/GERONIMO-1762 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.0, 1.1 > Environment: winXP > Reporter: Lin Sun > Fix For: 1.1 > Attachments: G1762.patch > > Wehn tried to deploy a derby embedded or network XA datasource via console, > got a class not found error and failed. > This is caused by the plan generated by the console not declaring the > dependency elements correctly (for example derbyclient.jar is needed as > dependency for derby network XA). > The fix adds a jar selection for XA resource adapters, thus the dependency > URI element can be set correctly with user's selection. With the fix, I am > able to create database connection pools using either derby embedded XA or > network XA. -- 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-1475) Configs needing updated to not include Xerces files in the Repository as duplicates to lib\endorsed
[ http://issues.apache.org/jira/browse/GERONIMO-1475?page=all ] Donald Woods closed GERONIMO-1475: -- Fix Version: (was: 1.2) Resolution: Invalid (Visible to jira-users) > Configs needing updated to not include Xerces files in the Repository as > duplicates to lib\endorsed > --- > > Key: GERONIMO-1475 > URL: http://issues.apache.org/jira/browse/GERONIMO-1475 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: common > Versions: 1.0 > Environment: AG 1.0 on WinXP w/ Sun 1.4.2_08 > Reporter: Donald Woods > Assignee: Donald Woods > Priority: Trivial > Fix For: 1.1 > Attachments: Geronimo-1475.patch > > The following Configs need to be updated so Xerces is not duplicated into the > repository, since is already included under lib\endorsed - >client-system >j2ee-system > by removing the following from the 2 Xerces dependencies - > > true > -- 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: JavaOne BOF
I'll provide some info on the release schedule (can you say end of month :)? Unfortunately, I'm leaving Thursday morning I think so I won't be there at the BOF. Any volunteers to present the material ? Aaron Mulder wrote: Someone (cough, Matt, cough) needs to discuss the release schedule. We should cover the new moduleId syntax (Dain or David J?). I'd like to spend 10 minutes or so talking about plugins. We should be prepared with our initial thoughts on Java EE 5 integration. As for what users want to see, we should probably ask on the user@ list. It would be great to spend some time soliciting feature ideas/requests. Thanks, Aaron On 5/10/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Geir, It looks like we now have a BOF, care of you ;-) Is this correct?: Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921 If so, should we talk a bit about what we should present, etc? Anything out there the users would like to have covered? Thanks, Jeff
Re: New Feature Wednesday
Wonderful! Thanks!! david jencks On May 10, 2006, at 6:26 AM, David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest+Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Offline deployer is almost ready :-)
After looking at Toby Cabot's patch (GERONIMO-1507) and thinking some more I've come up with an offline deployer. What I do is basically start only the configurations in config.xml whose artifacts match .*- deployer/.* This is quite easy and seems to work. There are 2 possible problems at the moment: 1. pattern matching is a bit fragile. For instance, there's the hot- deployer which can't start in this environment. We could slip around this problem for now by a lot of renaming, such as calling the builder modules *-builder. It might be better to have a different solution. We can't really use a different config.xml since one goal of the deployer is to modify the config.xml. I guess we could have an explicit list in var/config but that will introduce it's own set of maintenance headaches. 2. In order to get the j2ee-system gbeans in place I copied the plan into online-deployer. This doesn't have an effect on online deployment. I'd prefer to find a way to get the config.set out of server.jar rather than deployer.jar but I'm not sure how to do that. Any suggestions? thanks david jencks
Re: New Feature Wednesday
David, This is excellent. I think the users will appreciate being able to see new items more quickly. Not sure if this makes sense but you might do the build at 0300 PT. That way Aaron won't be up early hammering the build :) David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest+Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: XA_RDONLY optimization - question
On May 10, 2006, at 1:17 PM, ludovic orban wrote: Hi, I carefully read Mike Spille's XA Exposed articles but there was something I could never properly understand. I hope somebody here will be able and kind enough to help me understand what I missed. The question I have lies in "The 1PC Optimization..." paragraph of XA Exposed - Part II (http://jroller.com/page/pyrasun?entry=xa_exposed_part_ii_schwartz). Quoting Mike : ...only 1 XAResource has actually done any useful work. Here are some reasons why this can happen: * Only one transaction ever got enlisted. There are a number of combinations of configuration and/or application logic that can lead to this condition. * Every resource but one returned XA_RDONLY from its prepare() call The 1PC optimization itself is very simple: the Transaction Manager skips writing a "Committing..." record, it skips the prepare() call, and calls commit() on the lone XA Resource directly. Now I believe that the second point Mike enumerated (Every resource but one returned XA_RDONLY from its prepare() call) is not consistent with the ending sentence (writing a "Committing..." record, ==> it skips the prepare() call <==). How can you trigger 1PC with the XA_RDONLY vote ? You will only know the result of that vote after the prepare call and then it's too late to commit with the 1PC optimization ! The best you can do is skip the COMMITTING log record force while still calling commit with 1PC boolean flag set to false on the sole resource that returned XA_OK. You end up with 2 disk forces in that case instead of the single one you would get with a plain 1PC optimization. I'd really appreciate if anyone could comment on this. I don't think mike explained it very well, and there are 2 things called 1pc optimization. I haven't checked what he wrote recently, but unless you are misquoting him I agree with you that there's a contradiction. Here's my attempt to explain the 2 scenarios: 1. there's only one resource in the transaction. Well, you can just call 1pc commit on it. As a special case, if there are lots of resources, but all but the last one says it's read-only, you can just call 1pc commit on the last one (skipping prepare). I think it's sort of obvious this works, and doesn't introduce any risks of data loss. 2. if your last resource only supports 1pc (it's not xa) some people think you can just call commit on it, and then write the prepare record for the other participants: you use the result of this 1pc commit to decide whether to proceed or roll back the other participants. A little thought shows that the time between the completion of the 1pc commit and writing the prepare record to the log is vulnerable and can result in inconsistency. (many people don't seem to realize this). However, there's a trick that can make it work :-) If you store the transaction log in the 1pc resource, and only do the commit as a part of writing the prepare record to the log (ignoring the 1pc commit call directly to the resource) then the semantics work out properly. AFAIK Jeremy Boynes thought this up, and I've implemented it in geronimo, but so far there is no testing of it. Hope this helps david jencks Thank you in advance, Ludovic
Master/Slave in 4.0
Hi, I am playing with Master/Slave recently, it seems when Slave starts up, it will talk to a Master and the Master starts to send msg/cmd etc. to the Slave, but when the Slave is down, the Master only deregister the slave, write an error message like "ERROR MasterBroker - Slave Failed" and continue going. When Slave comes up again, it can still successfully register with Master, and start to backup msgs from the Master again, and it will replace the Master when the Master is down, but they are already out of sync. This make the admin work really hard. Any suggestions? Thanks Erin -- View this message in context: http://www.nabble.com/Master-Slave-in-4.0-t1596345.html#a4331007 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Assigned: (GERONIMO-2008) Deployment of war with config file on classpath root fails due to '!' in url
[ http://issues.apache.org/jira/browse/GERONIMO-2008?page=all ]
Jeff Genender reassigned GERONIMO-2008:
---
Assign To: Dain Sundstrom
> Deployment of war with config file on classpath root fails due to '!' in url
>
>
> Key: GERONIMO-2008
> URL: http://issues.apache.org/jira/browse/GERONIMO-2008
> Project: Geronimo
> Type: Bug
> Security: public(Regular issues)
> Components: deployment
> Versions: 1.1
> Environment: Windows XP - Geronimo 1.1 SNAPSHOT
> Reporter: Bryan Noll
> Assignee: Dain Sundstrom
> Priority: Blocker
>
> Geronimo fails to properly deploy a webapp that uses Hibernate due to a
> configuration file named 'ehcache.xml' that lives on the root of the
> classpath. See the following for details. The most likely cause of the
> issue is the existence of a '!' in the url... but the fact that a directory
> named '!' does not actually exist on the file system under
> 'repository/default/...'.
> logging output:
>
> DEBUG [Configurator] Configuring ehcache from ehcache.xml found in the
> classpath:
> jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
>
> I think the thing to notice there is the directory named '!'.
> It doesn't actually exist on the file system.
> The root exception I'm getting says:
>
> org.hibernate.cache.CacheException: net.sf.ehcache.CacheException: Cannot
> configure CacheManager: Access is denied
>
>
>
> ehcache code:
>
> public void configure(final Object bean)
> throws Exception {
> final SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
> final BeanHandler handler = new BeanHandler(bean);
> URL url = getClass().getResource(DEFAULT_CLASSPATH_CONFIGURATION_FILE);
> if (url != null) {
> if (LOG.isDebugEnabled()) {
> LOG.debug("Configuring ehcache from ehcache.xml found in the
> classpath: " + url);
> }
> } else {
> url = getClass().getResource(FAILSAFE_CLASSPATH_CONFIGURATION_FILE);
> if (LOG.isWarnEnabled()) {
> LOG.warn("No configuration found. Configuring ehcache from
> ehcache-failsafe.xml"
> + " found in the classpath: " + url);
> }
> }
> parser.parse(url.toExternalForm(), handler);
> }
> ...
> where DEFAULT_CLASSPATH_CONFIGURATION_FILE is:
> private static final String DEFAULT_CLASSPATH_CONFIGURATION_FILE =
> "/ehcache.xml";
> ...
> A previous snapshot (had from the last week of April sometime) WORKED and
> produced this debug msg.
> 15:49:26,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
> in the classpath:
> file:/C:/good/repository/default/equinox-jsf/1/equinox-jsf-1.car/WEB-INF/classes/ehcache.xml
>
>
>
> A snapshot had from 5/8/06 (give or take a day or two... sorry for the lack
> of precision here) produced this debug msg... and this is the one that DOES
> NOT WORK. Notice the '!'
> 15:17:36,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found
> in the classpath:
> jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.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-2008) Deployment of war with config file on classpath root fails due to '!' in url
Deployment of war with config file on classpath root fails due to '!' in url
Key: GERONIMO-2008
URL: http://issues.apache.org/jira/browse/GERONIMO-2008
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: deployment
Versions: 1.1
Environment: Windows XP - Geronimo 1.1 SNAPSHOT
Reporter: Bryan Noll
Priority: Blocker
Geronimo fails to properly deploy a webapp that uses Hibernate due to a
configuration file named 'ehcache.xml' that lives on the root of the classpath.
See the following for details. The most likely cause of the issue is the
existence of a '!' in the url... but the fact that a directory named '!' does
not actually exist on the file system under 'repository/default/...'.
logging output:
DEBUG [Configurator] Configuring ehcache from ehcache.xml found in the
classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.xml
I think the thing to notice there is the directory named '!'.
It doesn't actually exist on the file system.
The root exception I'm getting says:
org.hibernate.cache.CacheException: net.sf.ehcache.CacheException: Cannot
configure CacheManager: Access is denied
ehcache code:
public void configure(final Object bean)
throws Exception {
final SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
final BeanHandler handler = new BeanHandler(bean);
URL url = getClass().getResource(DEFAULT_CLASSPATH_CONFIGURATION_FILE);
if (url != null) {
if (LOG.isDebugEnabled()) {
LOG.debug("Configuring ehcache from ehcache.xml found in the
classpath: " + url);
}
} else {
url = getClass().getResource(FAILSAFE_CLASSPATH_CONFIGURATION_FILE);
if (LOG.isWarnEnabled()) {
LOG.warn("No configuration found. Configuring ehcache from
ehcache-failsafe.xml"
+ " found in the classpath: " + url);
}
}
parser.parse(url.toExternalForm(), handler);
}
...
where DEFAULT_CLASSPATH_CONFIGURATION_FILE is:
private static final String DEFAULT_CLASSPATH_CONFIGURATION_FILE =
"/ehcache.xml";
...
A previous snapshot (had from the last week of April sometime) WORKED and
produced this debug msg.
15:49:26,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found in
the classpath:
file:/C:/good/repository/default/equinox-jsf/1/equinox-jsf-1.car/WEB-INF/classes/ehcache.xml
A snapshot had from 5/8/06 (give or take a day or two... sorry for the lack of
precision here) produced this debug msg... and this is the one that DOES NOT
WORK. Notice the '!'
15:17:36,765 DEBUG [Configurator] Configuring ehcache from ehcache.xml found in
the classpath:
jar:file:/C:/go11/repository/default/equinox-jsf/1147295851453/equinox-jsf-1147295851453.war/WEB-INF/classes/!/ehcache.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] Resolved: (GERONIMO-436) JSR-88: Targets Ignored
[ http://issues.apache.org/jira/browse/GERONIMO-436?page=all ] Sachin Patel resolved GERONIMO-436: --- Resolution: Fixed This should work now. > JSR-88: Targets Ignored > --- > > Key: GERONIMO-436 > URL: http://issues.apache.org/jira/browse/GERONIMO-436 > Project: Geronimo > Type: Bug > Components: deployment > Versions: 1.0-M2 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > The current JSR-88 deployer (JMXDeploymentManager) may potentially provide a > list of targets for getTargets() -- one per config store. > However, all the methods that take an array of Target or TargetModuleID > objects ignore the specified Targets. -- 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-1740) Plugin migration to Maven 2: geronimo-packaging-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1740?page=all ] Anita Kulshreshtha updated GERONIMO-1740: - Attachment: geronimo.patch Guillaume, This patch contains pom.xmls for modules and configs and parent-poms. This is for 1.1. Lot of new things were added in 1.1, they have not yet been incorporated. The following remains to be done - 1. Find a way to represent packaging.config.order. The HEAD had DeployConfig string. It would have worked better in M2. 2. At one point I had thought of using type 'car' to distinguish between imports and dependency. We still need something for reference. 3. The ConfigCopier will need to use groupIds of the form o.a.g.configs. 4. Some more dependency pruning in modules. I will post a cleaner version of the patch. Most of this is needed just to pack the geronimo-gbean-deployer, which is used by the packaging plugin! To package anything meaningful more basic configurations will be needed, which means more module jars and the list goes on..Good Luck :) > Plugin migration to Maven 2: geronimo-packaging-plugin > -- > > Key: GERONIMO-1740 > URL: http://issues.apache.org/jira/browse/GERONIMO-1740 > Project: Geronimo > Type: Sub-task > Security: public(Regular issues) > Components: buildsystem > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: configs.patch, geronimo.patch, geronimo.patch, > m2-plugins.patch, m2-plugins.patch > > It's a task to keep track of the progress of the plugin build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1666) Console issues resulting from configID changes
[ http://issues.apache.org/jira/browse/GERONIMO-1666?page=all ] Paul McMahan resolved GERONIMO-1666: Fix Version: 1.1 (was: 1.2) Resolution: Duplicate dup of GERONIMO-1802 > Console issues resulting from configID changes > -- > > Key: GERONIMO-1666 > URL: http://issues.apache.org/jira/browse/GERONIMO-1666 > Project: Geronimo > Type: Task > Security: public(Regular issues) > Components: console > Versions: 1.2 > Reporter: Paul McMahan > Fix For: 1.1 > > This JIRA tracks what areas of the console need attention as a result of the > configID changes. > At Revision 382401: > - Classloader for classes loaded from geronimo-console-core-1.1-SNAPSHOT.jar >can't load classes from geronimo-jetty-1.1-SNAPSHOT.jar. This prevents >BasicProxyManager from being able to create proxies needed by the Server >Logs and Web Server portlets. > - J2EEServerImpl.getRepositories() returns an empty String[]. This prevents > the >the Common Libraries portlet and the DB Pool Wizard from listing out the >available jars in the repository. Also prevents the JMS Resource portlet >from being able to create new JMS Resource groups for ActiveMQ. > - Trying to delete a new activeio listener I created results in the > following ST. > BTW, it failed to start too but I see that problem in Geronimo-1.0 > 16:19:56,029 WARN [Util] No parents found for > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,J2EEServer=geronimo,broker=ActiveMQ,j2eeType=JMSConnector,name=ActiveMQ.activeio.0.0.0.0.9123-asdf > 16:19:56,030 ERROR [ActiveMQManagerGBean] Unable to remove GBean > java.lang.NullPointerException > at > org.apache.geronimo.kernel.basic.BasicKernel.createGBeanName(BasicKernel.java:427) > at > org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) > at > org.activemq.gbean.management.ActiveMQManagerGBean.removeConnector(ActiveMQManagerGBean.java:247) > at > org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke() > - ConfigurationManager.listStores() returns an empty list for the storeName: > geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-system/1.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=ConfigurationStore,name=Local > This prevents the user from being able to start/stop/undeploy/etc their > components from the EAR, WAR, EJB, Connector, App Client, and System > Modules portlets > - Deploying a simple WAR fails with an external plan fails with the error > message: > org.apache.geronimo.kernel.config.InvalidConfigException: Source is not > readable > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war > Source is not readable > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/repository/test/test/1.1/test-1.1.war >I checked and the .../repository/test/test/1.1 directory is present but it > is empty > - Creating and then deploying a new security realm fails with the >following ST: > 17:20:06,704 ERROR [Deployer] Deployment failed due to > java.lang.NullPointerException > at > org.apache.geronimo.kernel.repository.Version.parseVersion(Version.java:115) > at org.apache.geronimo.kernel.repository.Version.(Version.java:40) > at > org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:38) > at > org.apache.geronimo.deployment.service.EnvironmentBuilder.toArtifact(EnvironmentBuilder.java:229) > at > org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:56) > at > org.apache.geronimo.deployment.service.EnvironmentBuilder.buildEnvironment(EnvironmentBuilder.java:125) > at > org.apache.geronimo.deployment.service.ServiceConfigBuilder.getConfigurationID(ServiceConfigBuilder.java:147) > The relevant part of the plan (which was generated by the wizard) > looks like: > > > Unspecified > test > > -- 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
XA_RDONLY optimization - question
Hi, I carefully read Mike Spille's XA Exposed articles but there was something I could never properly understand. I hope somebody here will be able and kind enough to help me understand what I missed. The question I have lies in "The 1PC Optimization..." paragraph of XA Exposed - Part II (http://jroller.com/page/pyrasun?entry=xa_exposed_part_ii_schwartz). Quoting Mike : ...only 1 XAResource has actually done any useful work. Here are some reasons why this can happen: * Only one transaction ever got enlisted. There are a number of combinations of configuration and/or application logic that can lead to this condition. * Every resource but one returned XA_RDONLY from its prepare() call The 1PC optimization itself is very simple: the Transaction Manager skips writing a "Committing..." record, it skips the prepare() call, and calls commit() on the lone XA Resource directly. Now I believe that the second point Mike enumerated (Every resource but one returned XA_RDONLY from its prepare() call) is not consistent with the ending sentence (writing a "Committing..." record, ==> it skips the prepare() call <==). How can you trigger 1PC with the XA_RDONLY vote ? You will only know the result of that vote after the prepare call and then it's too late to commit with the 1PC optimization ! The best you can do is skip the COMMITTING log record force while still calling commit with 1PC boolean flag set to false on the sole resource that returned XA_OK. You end up with 2 disk forces in that case instead of the single one you would get with a plain 1PC optimization. I'd really appreciate if anyone could comment on this. Thank you in advance, Ludovic
[jira] Resolved: (GERONIMO-1902) Console does not allow editing of Tomcat Connector Attributes
[ http://issues.apache.org/jira/browse/GERONIMO-1902?page=all ] Paul McMahan resolved GERONIMO-1902: Resolution: Fixed This problem was fixed by a patch already committed for GERONIMO-1802. > Console does not allow editing of Tomcat Connector Attributes > - > > Key: GERONIMO-1902 > URL: http://issues.apache.org/jira/browse/GERONIMO-1902 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Environment: All > Reporter: Matt Hogstrom > Assignee: Aaron Mulder > Priority: Critical > Fix For: 1.1 > > When attempting to edit the Tomcat Connectors the following messages are > generated: > 08:56:26,315 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > 08:56:26,318 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > 08:56:26,566 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > 08:56:26,587 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > 08:56:26,593 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatManagerImpl in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebManager -- 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: test
Welcome to the list, Sachin ;-) Cheers Prasad On 5/10/06, Sachin Patel <[EMAIL PROTECTED]> wrote: test:ignore -sachin
[jira] Assigned: (GERONIMO-2007) Avoid Classloader warnings generated by BasicProxyManager
[ http://issues.apache.org/jira/browse/GERONIMO-2007?page=all ] Paul McMahan reassigned GERONIMO-2007: -- Assign To: Aaron Mulder Please take a look at the patch when you get a chance. > Avoid Classloader warnings generated by BasicProxyManager > - > > Key: GERONIMO-2007 > URL: http://issues.apache.org/jira/browse/GERONIMO-2007 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Paul McMahan > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.1 > Attachments: GERONIMO-2007.patch > > Several views in the console create proxies for objects that implement > interfaces not available in the console's classloader. The warning messages > look like: > 08:56:26,315 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > This warning message can be avoided by getting the classloader for the > proxied object from the kernel and then using it to create the proxy. -- 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-2007) Avoid Classloader warnings generated by BasicProxyManager
[ http://issues.apache.org/jira/browse/GERONIMO-2007?page=all ] Paul McMahan updated GERONIMO-2007: --- Attachment: GERONIMO-2007.patch > Avoid Classloader warnings generated by BasicProxyManager > - > > Key: GERONIMO-2007 > URL: http://issues.apache.org/jira/browse/GERONIMO-2007 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Paul McMahan > Priority: Minor > Fix For: 1.1 > Attachments: GERONIMO-2007.patch > > Several views in the console create proxies for objects that implement > interfaces not available in the console's classloader. The warning messages > look like: > 08:56:26,315 WARN [BasicProxyManager] Could not load interface > org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for > geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer > This warning message can be avoided by getting the classloader for the > proxied object from the kernel and then using it to create the proxy. -- 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-2007) Avoid Classloader warnings generated by BasicProxyManager
Avoid Classloader warnings generated by BasicProxyManager - Key: GERONIMO-2007 URL: http://issues.apache.org/jira/browse/GERONIMO-2007 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Paul McMahan Priority: Minor Fix For: 1.1 Several views in the console create proxies for objects that implement interfaces not available in the console's classloader. The warning messages look like: 08:56:26,315 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer This warning message can be avoided by getting the classloader for the proxied object from the kernel and then using it to create the proxy. -- 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-2006) Deploying an application with an incorrect deployment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Summary: Deploying an application with an incorrect deployment plan results in non-functional admin console panel (was: Deploying an application with an incorrect depolyment plan results in non-functional admin console panel) > Deploying an application with an incorrect deployment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Attachment: badPlan2.xml Here is another bad plan (badPlan2) that results in a slightly different error (i.e the deploy panel doesn't refresh and returns a blank page). > Deploying an application with an incorrect depolyment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, badPlan2.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
[ http://issues.apache.org/jira/browse/GERONIMO-2006?page=all ] Dave Colasurdo updated GERONIMO-2006: - Attachment: stackTrace.log badPlan.xml Myapp.war > Deploying an application with an incorrect depolyment plan results in > non-functional admin console panel > > > Key: GERONIMO-2006 > URL: http://issues.apache.org/jira/browse/GERONIMO-2006 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Dave Colasurdo > Attachments: Myapp.war, badPlan.xml, stackTrace.log > > Deploying myApp.war using badPlan.xml (both attached) results in a > non-functioning "Show Web App Wars" panel. > The console "Deploy Applications" panel reports "application installed and > started successfully". However, the application did not startup succesfully. > The badPlan file is actually missing tcpListenerAddress=auto which causes > TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the > JIRA. > From then on, the "Web App Wars" console panel shows "portlet error" and > there is no way to uninstall the bad application via the console. The server > must be stopped and restarted in order to have the "Web App War" panel > function correctly. > The console should be able to report the true status of the "deploy/start" > and recover from deploying a bad plan. -- 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-2006) Deploying an application with an incorrect depolyment plan results in non-functional admin console panel
Deploying an application with an incorrect depolyment plan results in non-functional admin console panel Key: GERONIMO-2006 URL: http://issues.apache.org/jira/browse/GERONIMO-2006 Project: Geronimo Type: Bug Security: public (Regular issues) Components: console Versions: 1.1 Reporter: Dave Colasurdo Deploying myApp.war using badPlan.xml (both attached) results in a non-functioning "Show Web App Wars" panel. The console "Deploy Applications" panel reports "application installed and started successfully". However, the application did not startup succesfully. The badPlan file is actually missing tcpListenerAddress=auto which causes TomcatReceiver Gbean to fail startup. I've attached the stacktrace to the JIRA. >From then on, the "Web App Wars" console panel shows "portlet error" and there >is no way to uninstall the bad application via the console. The server must >be stopped and restarted in order to have the "Web App War" panel function >correctly. The console should be able to report the true status of the "deploy/start" and recover from deploying a bad plan. -- 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: JavaOne BOF
On May 10, 2006, at 10:58 AM, Bruce Snyder wrote: On 5/10/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Geir, It looks like we now have a BOF, care of you ;-) Is this correct?: Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921 Where will the BOF take place? And when someone finds out, can you add it to the events page and send out an [event] email? -dain
Re: 1.1 Package Upgrade List
Comments inline... --- Aaron Mulder <[EMAIL PROTECTED]> wrote: > So my understanding of things is that we have the full set of G 1.1 > plugins for Maven 1, and it would be nice to also have at least a G > 1.1 packaging plugin for Maven 2 (though we'll need them all in due > course). > > For the Maven 1 plugin, it looks like we have some Jelly code and a > Java implementation class. > > For a Maven 2 plugin, I wonder if we could use the same (or a very > similar) Java class, and migrate the Jelly logic either into that > class or into some Ant code. I haven't done much plugin porting, but > superficially it doesn't seem like it should be that hard. These are the issues : 1. Maven1 allows use of properties in the dependency element, i.e. 2 . There are many such properties geronimo.reference, geronimo.dependency, geronimo.import etc being used. M2 does not allow properties! 2. The groupIds for basic configurations needed to do the packaging are of the form o.a.g.configs in M2. The new (M2 based) configuration store in 1.1. should be able to handle these. These ids have not been tried yet. Thanks Anita > > Thanks, > Aaron > > On 5/10/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > Plugins are quite independant of the build afaik (even if they are > used > > by the main build). > > They could be written for G 1.1 and updated for G 1.x and have > their > > lifecycle decorrelated from Geronimo. > > As they will be very useful for people creating plugins, I think it > > could be interesting to write them for 1.1 before of the m2 switch. > > Is there any beginning of implementation available somewhere ? > > > > Cheers, > > Guillaume Nodet > > > > > > anita kulshreshtha wrote: > > > > >All work related to M2 was halted until the trunk was merged. > M2 > > >packaging plugin would require transferring all M2 work to 1.1. I > do > > >not think there are any plans to do it before the merge or at > least the > > >1.1. release. I think using Maven1 will be best at this time. > Let's > > >hear from Jacek.. > > > > > >Thanks > > >Anita > > > > > >--- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >>I haven't seen any geronimo plugin for m2 in head. > > >>That whould be very usefull, especially because Geronimo plugins > have > > >>to > > >>be in a m2 layout, but the only tools to create a car is a m1 > plugin. > > >>Any idea ? > > >> > > >>Cheers, > > >>Guillaume Nodet > > >> > > >>Aaron Mulder wrote: > > >> > > >> > > >> > > >>>I'd rather handle the ApacheDS integration separately from the > 1.1 > > >>>release. Fortunately, the plugins work with the Maven 2 > > >>> > > >>> > > >>repository, > > >> > > >> > > >>>so that issue should be easier. > > >>> > > >>>The main question is how to do the build and packaging. If the > API > > >>> > > >>> > > >>is > > >> > > >> > > >>>unchanged, we can build our integration module using our Maven 1 > > >>>packaging plugin against ADS 0.9.2 and just have it apply the > 1.0.x > > >>>JARs at installation time. If the API is different, it may make > > >>> > > >>> > > >>the > > >> > > >> > > >>>most sense to try to split out our directory integration and do > the > > >>>build and packaging under Maven 2 (I'm assuming that Geronimo > HEAD > > >>> > > >>> > > >>has > > >> > > >> > > >>>a Maven 2 packaging plugin, but if not, I guess we can work on > > >>> > > >>> > > >>one). > > >> > > >> > > >>>Thanks, > > >>> Aaron > > >>> > > >>>On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > >>> > > >>> > > >>> > > ApacheDS0.9.2 to 1.0-RC2 ? > > I have a patch to port the Geronimo part to 1.0-RC2. However, > > currently ADS 1.0 jars propagated to maven2 repo only. > > > > 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > > > > > > >Consolidated list so far is: > > > > > >Axis from 1.4-356167 to 1.4 > > >commons-fileupload 1.1-dev to 1.1 > > >jasper from 5.5.9 to 5.5.15 > > >Jetty from 5.1.9 to 5.1.10 > > >stax from 1.1.1-dev to 1.1.2 > > >Tomcat 5.5.9 to 5.5.15 > > >tranql from1.2.1 to 1.3-SNAPSHOT > > >tranql-connector from 1.1 to 1.2-SNAPSHOT > > > > > >Keep 'em coming. > > > > > >Matt > > > > > >Aaron Mulder wrote: > > > > > > > > >>That issue has a great list. > > >> > > >>We definitely need to try updating commons-fileupload (from > > >> > > >> > > 1.1-dev to > > > > > > >>1.1). I think there may even be a separate Jira for that. > > >> > > >> > > >>But the > > >> > > >> > > >>old one occasionally hangs, so it's definitely worth trying > > >> > > >> > > >>the new > > >> > > >> > > >>one. > > >> > > >>Thanks, > > >
Re: New Feature Wednesday
David, --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > On May 10, 2006, at 7:13 AM, Prasad Kashyap wrote: > > > Oh David.. this is really coool ! > > > > Now explain the significance of 405734. :-) > > > > Hope it's not some random number. It'd be nice if that was the tied > to > > the revision number or the timestamp or such significant thing. > > It is the svn revision number of the checkout used to create the > build. This is WONDERFUL. Thnaks Anita > > -dain > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Resolved: (GERONIMO-2005) redeploying console EAR fails
[ http://issues.apache.org/jira/browse/GERONIMO-2005?page=all ] Paul McMahan resolved GERONIMO-2005: Resolution: Fixed ConfigIdExtractor was still looking for 'configId' when scanning a plan. Fixed by svn commit: r405784. > redeploying console EAR fails > - > > Key: GERONIMO-2005 > URL: http://issues.apache.org/jira/browse/GERONIMO-2005 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: revision 405752 (tomcat version) running on linux > Reporter: Paul McMahan > Priority: Critical > > The following redeploy command no longer works: > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager redeploy > ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear > ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the plan. > Attempting to use ModuleID '///' > Exception in thread "main" java.lang.NullPointerException: artifactId is null > at > org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:39) > at > org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:35) > at > org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:56) > at > org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:176) > at > org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:130) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:312) > Undeploying and then deploying using the same EAR and plan works (see below), > so I assume the problem is somewhere in the redeploy logic. > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager undeploy > geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car unloaded. > Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car uninstalled. > Undeployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > `-> standard.war > `-> framework.war > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager deploy > ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear > ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > Deployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > `-> standard.war @ > http://frylock.raleigh.ibm.com:8080/console-standard > `-> framework.war @ http://frylock.raleigh.ibm.com:8080/console > [EMAIL PROTECTED] bin]$ -- 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-2005) redeploying console EAR fails
[ http://issues.apache.org/jira/browse/GERONIMO-2005?page=all ] Paul McMahan closed GERONIMO-2005: -- > redeploying console EAR fails > - > > Key: GERONIMO-2005 > URL: http://issues.apache.org/jira/browse/GERONIMO-2005 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: revision 405752 (tomcat version) running on linux > Reporter: Paul McMahan > Priority: Critical > > The following redeploy command no longer works: > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager redeploy > ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear > ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > No ModuleID or TargetModuleID provided. Attempting to guess based > on the content of the plan. > Attempting to use ModuleID '///' > Exception in thread "main" java.lang.NullPointerException: artifactId is null > at > org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:39) > at > org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:35) > at > org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:56) > at > org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:176) > at > org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:130) > at > org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) > at > org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:312) > Undeploying and then deploying using the same EAR and plan works (see below), > so I assume the problem is somewhere in the redeploy logic. > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager undeploy > geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car unloaded. > Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car uninstalled. > Undeployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > `-> standard.war > `-> framework.war > [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager deploy > ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear > ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml > Using GERONIMO_BASE: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_HOME: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT > Using GERONIMO_TMPDIR: > /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp > Using JRE_HOME:/usr/java/j2sdk1.4.2_10 > Deployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car > `-> standard.war @ > http://frylock.raleigh.ibm.com:8080/console-standard > `-> framework.war @ http://frylock.raleigh.ibm.com:8080/console > [EMAIL PROTECTED] bin]$ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1 Package Upgrade List
svn is still down... Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Yes, please, upload your code. > I will try to update them for 1.1. > > Thanks, > Guillaume Nodet > > anita kulshreshtha wrote: > > >Comments inline.. > > > >--- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > > >>Plugins are quite independant of the build afaik (even if they are > >>used > >>by the main build). > >>They could be written for G 1.1 and updated for G 1.x and have > their > >>lifecycle decorrelated from Geronimo. > >> > >> > > Usually they are and will be in the future... The change from > HEAD > >to 1.1 is so drastic that there was no point in continuing the > >development of packaging and other plugins in the HEAD. > > > > > >>As they will be very useful for people creating plugins, I think it > > >>could be interesting to write them for 1.1 before of the m2 switch. > >>Is there any beginning of implementation available somewhere ? > >> > >> > >I have some code for packaging plugin for 1.1 that compiles but > you > >would need M2 geronimo-* jars for that. There is no point using the > >HEAD for anything now. Please let me know if you want me upload a > patch > >to the jira. > > > >Thanks > >Anita > > > > > >>Cheers, > >>Guillaume Nodet > >> > >> > >>anita kulshreshtha wrote: > >> > >> > >> > >>> All work related to M2 was halted until the trunk was merged. > M2 > >>>packaging plugin would require transferring all M2 work to 1.1. I > do > >>>not think there are any plans to do it before the merge or at > least > >>> > >>> > >>the > >> > >> > >>>1.1. release. I think using Maven1 will be best at this time. > Let's > >>>hear from Jacek.. > >>> > >>>Thanks > >>>Anita > >>> > >>>--- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>> > >>> > I haven't seen any geronimo plugin for m2 in head. > That whould be very usefull, especially because Geronimo plugins > > > >>have > >> > >> > to > be in a m2 layout, but the only tools to create a car is a m1 > > > >>plugin. > >> > >> > Any idea ? > > Cheers, > Guillaume Nodet > > Aaron Mulder wrote: > > > > > > >I'd rather handle the ApacheDS integration separately from the > 1.1 > >release. Fortunately, the plugins work with the Maven 2 > > > > > > > > > repository, > > > > > >so that issue should be easier. > > > >The main question is how to do the build and packaging. If the > > > > > >>API > >> > >> > > > > > > > > > is > > > > > >unchanged, we can build our integration module using our Maven 1 > >packaging plugin against ADS 0.9.2 and just have it apply the > > > > > >>1.0.x > >> > >> > >JARs at installation time. If the API is different, it may make > > > > > > > > > the > > > > > >most sense to try to split out our directory integration and do > > > > > >>the > >> > >> > >build and packaging under Maven 2 (I'm assuming that Geronimo > HEAD > > > > > > > > > has > > > > > >a Maven 2 packaging plugin, but if not, I guess we can work on > > > > > > > > > one). > > > > > >Thanks, > > Aaron > > > >On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > >>ApacheDS0.9.2 to 1.0-RC2 ? > >>I have a patch to port the Geronimo part to 1.0-RC2. However, > >>currently ADS 1.0 jars propagated to maven2 repo only. > >> > >>2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > >> > >> > >> > >> > >>>Consolidated list so far is: > >>> > >>>Axis from 1.4-356167 to 1.4 > >>>commons-fileupload 1.1-dev to 1.1 > >>>jasper from 5.5.9 to 5.5.15 > >>>Jetty from 5.1.9 to 5.1.10 > >>>stax from 1.1.1-dev to 1.1.2 > >>>Tomcat 5.5.9 to 5.5.15 > === message truncated === __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
G1.1 Tomcat Clustering - Good news
Now that we have officially upgraded to TC 5.5.15, I've gone back and retried the clustering tests and it looks like G1.1 clustering is now working with TC5.5.15!! The "Unable to send message through cluster sender" exception that was being thrown was caused by a problem in the application deployment plan. Specifically, the tcpListen address had extra whitespace on the end that creates this problem. Seems this should be trimmed automatically. name="className">org.apache.catalina.cluster.tcp.ReplicationListener tcpListenAddress=192.168.0.1 tcpListenPort=4001 tcpSelectorTimeout=100 tcpThreadCount=6 Anyway, it seems that we can change this value to auto (e.g. tcpListenAddress=auto) for TC 5.5.15 and all works well. -Dave-
Re: 1.1 Package Upgrade List
Yes, please, upload your code. I will try to update them for 1.1. Thanks, Guillaume Nodet anita kulshreshtha wrote: Comments inline.. --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: Plugins are quite independant of the build afaik (even if they are used by the main build). They could be written for G 1.1 and updated for G 1.x and have their lifecycle decorrelated from Geronimo. Usually they are and will be in the future... The change from HEAD to 1.1 is so drastic that there was no point in continuing the development of packaging and other plugins in the HEAD. As they will be very useful for people creating plugins, I think it could be interesting to write them for 1.1 before of the m2 switch. Is there any beginning of implementation available somewhere ? I have some code for packaging plugin for 1.1 that compiles but you would need M2 geronimo-* jars for that. There is no point using the HEAD for anything now. Please let me know if you want me upload a patch to the jira. Thanks Anita Cheers, Guillaume Nodet anita kulshreshtha wrote: All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins have to be in a m2 layout, but the only tools to create a car is a m1 plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: JavaOne BOF
On 5/10/06, Jeff Genender <[EMAIL PROTECTED]> wrote:
Geir,
It looks like we now have a BOF, care of you ;-) Is this correct?:
Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921
Where will the BOF take place?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: 1.1 Package Upgrade List
Comments inline.. --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Plugins are quite independant of the build afaik (even if they are > used > by the main build). > They could be written for G 1.1 and updated for G 1.x and have their > lifecycle decorrelated from Geronimo. Usually they are and will be in the future... The change from HEAD to 1.1 is so drastic that there was no point in continuing the development of packaging and other plugins in the HEAD. > As they will be very useful for people creating plugins, I think it > could be interesting to write them for 1.1 before of the m2 switch. > Is there any beginning of implementation available somewhere ? I have some code for packaging plugin for 1.1 that compiles but you would need M2 geronimo-* jars for that. There is no point using the HEAD for anything now. Please let me know if you want me upload a patch to the jira. Thanks Anita > > Cheers, > Guillaume Nodet > > > anita kulshreshtha wrote: > > >All work related to M2 was halted until the trunk was merged. M2 > >packaging plugin would require transferring all M2 work to 1.1. I do > >not think there are any plans to do it before the merge or at least > the > >1.1. release. I think using Maven1 will be best at this time. Let's > >hear from Jacek.. > > > >Thanks > >Anita > > > >--- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > > >>I haven't seen any geronimo plugin for m2 in head. > >>That whould be very usefull, especially because Geronimo plugins > have > >>to > >>be in a m2 layout, but the only tools to create a car is a m1 > plugin. > >>Any idea ? > >> > >>Cheers, > >>Guillaume Nodet > >> > >>Aaron Mulder wrote: > >> > >> > >> > >>>I'd rather handle the ApacheDS integration separately from the 1.1 > >>>release. Fortunately, the plugins work with the Maven 2 > >>> > >>> > >>repository, > >> > >> > >>>so that issue should be easier. > >>> > >>>The main question is how to do the build and packaging. If the > API > >>> > >>> > >>is > >> > >> > >>>unchanged, we can build our integration module using our Maven 1 > >>>packaging plugin against ADS 0.9.2 and just have it apply the > 1.0.x > >>>JARs at installation time. If the API is different, it may make > >>> > >>> > >>the > >> > >> > >>>most sense to try to split out our directory integration and do > the > >>>build and packaging under Maven 2 (I'm assuming that Geronimo HEAD > >>> > >>> > >>has > >> > >> > >>>a Maven 2 packaging plugin, but if not, I guess we can work on > >>> > >>> > >>one). > >> > >> > >>>Thanks, > >>> Aaron > >>> > >>>On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > ApacheDS0.9.2 to 1.0-RC2 ? > I have a patch to port the Geronimo part to 1.0-RC2. However, > currently ADS 1.0 jars propagated to maven2 repo only. > > 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > > > >Consolidated list so far is: > > > >Axis from 1.4-356167 to 1.4 > >commons-fileupload 1.1-dev to 1.1 > >jasper from 5.5.9 to 5.5.15 > >Jetty from 5.1.9 to 5.1.10 > >stax from 1.1.1-dev to 1.1.2 > >Tomcat 5.5.9 to 5.5.15 > >tranql from1.2.1 to 1.3-SNAPSHOT > >tranql-connector from 1.1 to 1.2-SNAPSHOT > > > >Keep 'em coming. > > > >Matt > > > >Aaron Mulder wrote: > > > > > >>That issue has a great list. > >> > >>We definitely need to try updating commons-fileupload (from > >> > >> > 1.1-dev to > > > >>1.1). I think there may even be a separate Jira for that. > >> > >> > >>But the > >> > >> > >>old one occasionally hangs, so it's definitely worth trying > >> > >> > >>the new > >> > >> > >>one. > >> > >>Thanks, > >> Aaron > >> > >>On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> > >> > >>>Here are the packages I'm recommending for 1.1. If I missed > >>> > >>> > >>one > >> > >> > >>>please chime in. > >>> > >>>Axis from 1.4-356167 to 1.4 > >>>jasper from 5.5.9 to 5.5.15 > >>>Jetty from 5.1.9 to 5.1.10 > >>>stax from 1.1.1-dev to 1.1.2 > >>>tranql from1.2.1 to 1.3-SNAPSHOT > >>>tranql-connector from 1.1 to 1.2-SNAPSHOT > >>> > >>>This is the list so far...I've updated > >>> > >>> > >>> > >http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > > > > > >>>with this information. > >>
[jira] Closed: (GERONIMO-1405) support more than one config-store
[ http://issues.apache.org/jira/browse/GERONIMO-1405?page=all ] David Jencks closed GERONIMO-1405: -- Fix Version: 1.1 Resolution: Fixed Assign To: David Jencks I believe we have reimplemented everything in this patch, and wish we'd applied it before getting so far in 1.1. > support more than one config-store > -- > > Key: GERONIMO-1405 > URL: http://issues.apache.org/jira/browse/GERONIMO-1405 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: deployment > Environment: fedora core 2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) > Reporter: toby cabot > Assignee: David Jencks > Fix For: 1.1 > Attachments: geronimo-2configstores.txt > > Most of the code needed to support multiple config-stores is in place, but > Deployer assumes only one. -- 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: What is the console startup soooo slow?
Preprocessed jsps add tons of new servlets. Each servlet takes a long time to start. I don't know why they take so long to start but they do. Actually it isn't Servlets specifically, it is a problem with GBeans themselves. -dain On May 10, 2006, at 10:14 AM, Aaron Mulder wrote: I just started with --long, and I've noticed that the console is taking longer to start than it used to, but this made it darn obvious. The second highest module startup time is the system database taking 2.1 seconds. The console takes over 11 seconds. Any ideas what's taking it so long? Thanks, Aaron
What is the console startup soooo slow?
I just started with --long, and I've noticed that the console is taking longer to start than it used to, but this made it darn obvious. The second highest module startup time is the system database taking 2.1 seconds. The console takes over 11 seconds. Any ideas what's taking it so long? Thanks, Aaron
Re: Problem with DataBase Connection
Hi Thibault, you should still be able to access the data if you specify the schema in your query (schema.table) The id for connection does not necessarily need to be the same that created data/schema in the db. HTH Cheers! Hernan Hamelin, Thibault wrote: Hello, I'm currently developping an application with EJB, and I have a big problem with the connection to the DB2 DataBase. In the Resource Adapter, I defined correctly the user/pwd for my connection but when I try to get data with my EJB, the database schema used is set with my username. I want to use of course a data base schema different from my user name. I tried to create a schema with a name equals to my username, and of course I succeed to get my data. How can I set a different schema name to use ? Unfortunately, I have constraints with the usernames which can be created. Cordialement, Thibault HAMELIN
Re: JavaOne BOF
Someone (cough, Matt, cough) needs to discuss the release schedule. We should cover the new moduleId syntax (Dain or David J?). I'd like to spend 10 minutes or so talking about plugins. We should be prepared with our initial thoughts on Java EE 5 integration. As for what users want to see, we should probably ask on the user@ list. It would be great to spend some time soliciting feature ideas/requests. Thanks, Aaron On 5/10/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Geir, It looks like we now have a BOF, care of you ;-) Is this correct?: Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921 If so, should we talk a bit about what we should present, etc? Anything out there the users would like to have covered? Thanks, Jeff
Re: 1.1 Package Upgrade List
So my understanding of things is that we have the full set of G 1.1 plugins for Maven 1, and it would be nice to also have at least a G 1.1 packaging plugin for Maven 2 (though we'll need them all in due course). For the Maven 1 plugin, it looks like we have some Jelly code and a Java implementation class. For a Maven 2 plugin, I wonder if we could use the same (or a very similar) Java class, and migrate the Jelly logic either into that class or into some Ant code. I haven't done much plugin porting, but superficially it doesn't seem like it should be that hard. Thanks, Aaron On 5/10/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Plugins are quite independant of the build afaik (even if they are used by the main build). They could be written for G 1.1 and updated for G 1.x and have their lifecycle decorrelated from Geronimo. As they will be very useful for people creating plugins, I think it could be interesting to write them for 1.1 before of the m2 switch. Is there any beginning of implementation available somewhere ? Cheers, Guillaume Nodet anita kulshreshtha wrote: >All work related to M2 was halted until the trunk was merged. M2 >packaging plugin would require transferring all M2 work to 1.1. I do >not think there are any plans to do it before the merge or at least the >1.1. release. I think using Maven1 will be best at this time. Let's >hear from Jacek.. > >Thanks >Anita > >--- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > >>I haven't seen any geronimo plugin for m2 in head. >>That whould be very usefull, especially because Geronimo plugins have >>to >>be in a m2 layout, but the only tools to create a car is a m1 plugin. >>Any idea ? >> >>Cheers, >>Guillaume Nodet >> >>Aaron Mulder wrote: >> >> >> >>>I'd rather handle the ApacheDS integration separately from the 1.1 >>>release. Fortunately, the plugins work with the Maven 2 >>> >>> >>repository, >> >> >>>so that issue should be easier. >>> >>>The main question is how to do the build and packaging. If the API >>> >>> >>is >> >> >>>unchanged, we can build our integration module using our Maven 1 >>>packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x >>>JARs at installation time. If the API is different, it may make >>> >>> >>the >> >> >>>most sense to try to split out our directory integration and do the >>>build and packaging under Maven 2 (I'm assuming that Geronimo HEAD >>> >>> >>has >> >> >>>a Maven 2 packaging plugin, but if not, I guess we can work on >>> >>> >>one). >> >> >>>Thanks, >>> Aaron >>> >>>On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: >>> >>> >>> ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: >Consolidated list so far is: > >Axis from 1.4-356167 to 1.4 >commons-fileupload 1.1-dev to 1.1 >jasper from 5.5.9 to 5.5.15 >Jetty from 5.1.9 to 5.1.10 >stax from 1.1.1-dev to 1.1.2 >Tomcat 5.5.9 to 5.5.15 >tranql from1.2.1 to 1.3-SNAPSHOT >tranql-connector from 1.1 to 1.2-SNAPSHOT > >Keep 'em coming. > >Matt > >Aaron Mulder wrote: > > >>That issue has a great list. >> >>We definitely need to try updating commons-fileupload (from >> >> 1.1-dev to >>1.1). I think there may even be a separate Jira for that. >> >> >>But the >> >> >>old one occasionally hangs, so it's definitely worth trying >> >> >>the new >> >> >>one. >> >>Thanks, >> Aaron >> >>On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> >> >>>Here are the packages I'm recommending for 1.1. If I missed >>> >>> >>one >> >> >>>please chime in. >>> >>>Axis from 1.4-356167 to 1.4 >>>jasper from 5.5.9 to 5.5.15 >>>Jetty from 5.1.9 to 5.1.10 >>>stax from 1.1.1-dev to 1.1.2 >>>tranql from1.2.1 to 1.3-SNAPSHOT >>>tranql-connector from 1.1 to 1.2-SNAPSHOT >>> >>>This is the list so far...I've updated >>> >>> >>> >http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > > >>>with this information. >>> >>>Was mentioned on the list: >>>Howl- Researching this >>> >>> -- Alexei Zakharov, Intel Middleware Product Division >>> >>> > > >__ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > > >
Re: New Feature Wednesday
On May 10, 2006, at 7:13 AM, Prasad Kashyap wrote: Oh David.. this is really coool ! Now explain the significance of 405734. :-) Hope it's not some random number. It'd be nice if that was the tied to the revision number or the timestamp or such significant thing. It is the svn revision number of the checkout used to create the build. -dain
Re: 1.1 Package Upgrade List
Plugins are quite independant of the build afaik (even if they are used by the main build). They could be written for G 1.1 and updated for G 1.x and have their lifecycle decorrelated from Geronimo. As they will be very useful for people creating plugins, I think it could be interesting to write them for 1.1 before of the m2 switch. Is there any beginning of implementation available somewhere ? Cheers, Guillaume Nodet anita kulshreshtha wrote: All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins have to be in a m2 layout, but the only tools to create a car is a m1 plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Problem with DataBase Connection
Title: Problem with DataBase Connection Hello, I'm currently developping an application with EJB, and I have a big problem with the connection to the DB2 DataBase. In the Resource Adapter, I defined correctly the user/pwd for my connection but when I try to get data with my EJB, the database schema used is set with my username. I want to use of course a data base schema different from my user name. I tried to create a schema with a name equals to my username, and of course I succeed to get my data. How can I set a different schema name to use ? Unfortunately, I have constraints with the usernames which can be created. Cordialement, Thibault HAMELIN
JavaOne BOF
Geir, It looks like we now have a BOF, care of you ;-) Is this correct?: Thursday, 5/18 from 10:30pm to 11:20pm - BOF 9921 If so, should we talk a bit about what we should present, etc? Anything out there the users would like to have covered? Thanks, Jeff
Re: 1.1 Package Upgrade List
All work related to M2 was halted until the trunk was merged. M2 packaging plugin would require transferring all M2 work to 1.1. I do not think there are any plans to do it before the merge or at least the 1.1. release. I think using Maven1 will be best at this time. Let's hear from Jacek.. Thanks Anita --- Guillaume Nodet <[EMAIL PROTECTED]> wrote: > I haven't seen any geronimo plugin for m2 in head. > That whould be very usefull, especially because Geronimo plugins have > to > be in a m2 layout, but the only tools to create a car is a m1 plugin. > Any idea ? > > Cheers, > Guillaume Nodet > > Aaron Mulder wrote: > > > I'd rather handle the ApacheDS integration separately from the 1.1 > > release. Fortunately, the plugins work with the Maven 2 > repository, > > so that issue should be easier. > > > > The main question is how to do the build and packaging. If the API > is > > unchanged, we can build our integration module using our Maven 1 > > packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x > > JARs at installation time. If the API is different, it may make > the > > most sense to try to split out our directory integration and do the > > build and packaging under Maven 2 (I'm assuming that Geronimo HEAD > has > > a Maven 2 packaging plugin, but if not, I guess we can work on > one). > > > > Thanks, > >Aaron > > > > On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > > > >> ApacheDS0.9.2 to 1.0-RC2 ? > >> I have a patch to port the Geronimo part to 1.0-RC2. However, > >> currently ADS 1.0 jars propagated to maven2 repo only. > >> > >> 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > >> > Consolidated list so far is: > >> > > >> > Axis from 1.4-356167 to 1.4 > >> > commons-fileupload 1.1-dev to 1.1 > >> > jasper from 5.5.9 to 5.5.15 > >> > Jetty from 5.1.9 to 5.1.10 > >> > stax from 1.1.1-dev to 1.1.2 > >> > Tomcat 5.5.9 to 5.5.15 > >> > tranql from1.2.1 to 1.3-SNAPSHOT > >> > tranql-connector from 1.1 to 1.2-SNAPSHOT > >> > > >> > Keep 'em coming. > >> > > >> > Matt > >> > > >> > Aaron Mulder wrote: > >> > > That issue has a great list. > >> > > > >> > > We definitely need to try updating commons-fileupload (from > >> 1.1-dev to > >> > > 1.1). I think there may even be a separate Jira for that. > But the > >> > > old one occasionally hangs, so it's definitely worth trying > the new > >> > > one. > >> > > > >> > > Thanks, > >> > >Aaron > >> > > > >> > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> > >> Here are the packages I'm recommending for 1.1. If I missed > one > >> > >> please chime in. > >> > >> > >> > >> Axis from 1.4-356167 to 1.4 > >> > >> jasper from 5.5.9 to 5.5.15 > >> > >> Jetty from 5.1.9 to 5.1.10 > >> > >> stax from 1.1.1-dev to 1.1.2 > >> > >> tranql from1.2.1 to 1.3-SNAPSHOT > >> > >> tranql-connector from 1.1 to 1.2-SNAPSHOT > >> > >> > >> > >> This is the list so far...I've updated > >> > >> > >> > http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > > >> > >> > >> > >> > >> with this information. > >> > >> > >> > >> Was mentioned on the list: > >> > >> Howl- Researching this > >> > >> > >> -- > >> Alexei Zakharov, > >> Intel Middleware Product Division > >> > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Corba tss and css examples
I think this is reasonable. However, PLEASE keep MagicGBall up to date and working. I like a working CORBA sample, with both security and no security. Ted Kirby
[jira] Created: (SM-429) Add an aggregator pattern
Add an aggregator pattern - Key: SM-429 URL: https://issues.apache.org/activemq/browse/SM-429 Project: ServiceMix Type: New Feature Components: servicemix-eip Reporter: Guillaume Nodet -- 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-2005) redeploying console EAR fails
redeploying console EAR fails - Key: GERONIMO-2005 URL: http://issues.apache.org/jira/browse/GERONIMO-2005 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Environment: revision 405752 (tomcat version) running on linux Reporter: Paul McMahan Priority: Critical The following redeploy command no longer works: [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager redeploy ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml Using GERONIMO_BASE: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/java/j2sdk1.4.2_10 No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the plan. Attempting to use ModuleID '///' Exception in thread "main" java.lang.NullPointerException: artifactId is null at org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:39) at org.apache.geronimo.kernel.repository.Artifact.(Artifact.java:35) at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:56) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:176) at org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:130) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:312) Undeploying and then deploying using the same EAR and plan works (see below), so I assume the problem is somewhere in the redeploy logic. [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager undeploy geronimo/webconsole-tomcat/1.1-SNAPSHOT/car Using GERONIMO_BASE: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/java/j2sdk1.4.2_10 Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car unloaded. Module geronimo/webconsole-tomcat/1.1-SNAPSHOT/car uninstalled. Undeployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car `-> standard.war `-> framework.war [EMAIL PROTECTED] bin]$ ./deploy.sh --user system --password manager deploy ~/src/geronimo/1.1/applications/console-ear/target/geronimo-console-1.1-SNAPSHOT.ear ~/src/geronimo/1.1/configs/console-tomcat/target/plan/plan.xml Using GERONIMO_BASE: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_HOME: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT Using GERONIMO_TMPDIR: /home/pmcmahan/src/geronimo/1.1/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/var/temp Using JRE_HOME:/usr/java/j2sdk1.4.2_10 Deployed geronimo/webconsole-tomcat/1.1-SNAPSHOT/car `-> standard.war @ http://frylock.raleigh.ibm.com:8080/console-standard `-> framework.war @ http://frylock.raleigh.ibm.com:8080/console [EMAIL PROTECTED] bin]$ -- 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
test
test:ignore -sachin
Re: 1.1 Package Upgrade List
FYI: ADS API has changed significantly since 0.9.2. 2006/5/10, Aaron Mulder <[EMAIL PROTECTED]>: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: > ApacheDS0.9.2 to 1.0-RC2 ? > I have a patch to port the Geronimo part to 1.0-RC2. However, > currently ADS 1.0 jars propagated to maven2 repo only. > > 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > > Consolidated list so far is: > > > > Axis from 1.4-356167 to 1.4 > > commons-fileupload 1.1-dev to 1.1 > > jasper from 5.5.9 to 5.5.15 > > Jetty from 5.1.9 to 5.1.10 > > stax from 1.1.1-dev to 1.1.2 > > Tomcat 5.5.9 to 5.5.15 > > tranql from1.2.1 to 1.3-SNAPSHOT > > tranql-connector from 1.1 to 1.2-SNAPSHOT > > > > Keep 'em coming. > > > > Matt > > > > Aaron Mulder wrote: > > > That issue has a great list. > > > > > > We definitely need to try updating commons-fileupload (from 1.1-dev to > > > 1.1). I think there may even be a separate Jira for that. But the > > > old one occasionally hangs, so it's definitely worth trying the new > > > one. > > > > > > Thanks, > > >Aaron > > > > > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > >> Here are the packages I'm recommending for 1.1. If I missed one > > >> please chime in. > > >> > > >> Axis from 1.4-356167 to 1.4 > > >> jasper from 5.5.9 to 5.5.15 > > >> Jetty from 5.1.9 to 5.1.10 > > >> stax from 1.1.1-dev to 1.1.2 > > >> tranql from1.2.1 to 1.3-SNAPSHOT > > >> tranql-connector from 1.1 to 1.2-SNAPSHOT > > >> > > >> This is the list so far...I've updated > > >> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > > >> > > >> with this information. > > >> > > >> Was mentioned on the list: > > >> Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division
Re: New Feature Wednesday
David, Great job! We have been needing this for a while. Thanks for towing the line on this. Jeff David Blevins wrote: > All, > > I've revived our script that creates unstable builds. Further, I've > hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it > gives developers a couple days into the week to try and get features in > that they'd like people to try out. It also gives a couple days in the > week for users to give feedback. > > The goal is to have a nice steady drum beat of content reaching the > community to add more iterations to what is inherently an iterative > process. More iterations means more interactions which means a > healthier community economy. I could spend forever counting out the > benefits to the community and overall quality of the software > produced/consumed. > > Here is the info for the very latest build: > > Geronimo 1.1-405734 - May 10, 2006 > http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ > > geronimo-1.1-405734-src.tar.gz > geronimo-1.1-405734-src.zip > geronimo-jetty-j2ee-1.1-405734.tar.gz > geronimo-jetty-j2ee-1.1-405734.zip > geronimo-jetty-minimal-1.1-405734.tar.gz > geronimo-jetty-minimal-1.1-405734.zip > geronimo-tomcat-j2ee-1.1-405734.tar.gz > geronimo-tomcat-j2ee-1.1-405734.zip > geronimo-tomcat-minimal-1.1-405734.tar.gz > geronimo-tomcat-minimal-1.1-405734.zip > > Changelog: > > http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest+Unstable > > > The changelog is automatically generated along with the unstable build, > so keep an eye on that page for future updates! > > > All the best, > David
Re: New Feature Wednesday
Oh David.. this is really coool ! Now explain the significance of 405734. :-) Hope it's not some random number. It'd be nice if that was the tied to the revision number or the timestamp or such significant thing. Cheers Prasad. On 5/10/06, Sachin Patel <[EMAIL PROTECTED]> wrote: Awesome! We've needed this for a while. It would be great if we could auto link the build and the changelog to the download site. On May 10, 2006, at 9:26 AM, David Blevins wrote: > All, > > I've revived our script that creates unstable builds. Further, > I've hooked it up to run every Wednesday at 6am PST. I chose > Wednesday as it gives developers a couple days into the week to try > and get features in that they'd like people to try out. It also > gives a couple days in the week for users to give feedback. > > The goal is to have a nice steady drum beat of content reaching the > community to add more iterations to what is inherently an iterative > process. More iterations means more interactions which means a > healthier community economy. I could spend forever counting out > the benefits to the community and overall quality of the software > produced/consumed. > > Here is the info for the very latest build: > > Geronimo 1.1-405734 - May 10, 2006 > http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ > > geronimo-1.1-405734-src.tar.gz > geronimo-1.1-405734-src.zip > geronimo-jetty-j2ee-1.1-405734.tar.gz > geronimo-jetty-j2ee-1.1-405734.zip > geronimo-jetty-minimal-1.1-405734.tar.gz > geronimo-jetty-minimal-1.1-405734.zip > geronimo-tomcat-j2ee-1.1-405734.tar.gz > geronimo-tomcat-j2ee-1.1-405734.zip > geronimo-tomcat-minimal-1.1-405734.tar.gz > geronimo-tomcat-minimal-1.1-405734.zip > > Changelog: > > http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ > Latest+Unstable > > The changelog is automatically generated along with the unstable > build, so keep an eye on that page for future updates! > > > All the best, > David -sachin
Re: 1.1 Package Upgrade List
I haven't seen any geronimo plugin for m2 in head. That whould be very usefull, especially because Geronimo plugins have to be in a m2 layout, but the only tools to create a car is a m1 plugin. Any idea ? Cheers, Guillaume Nodet Aaron Mulder wrote: I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > Consolidated list so far is: > > Axis from 1.4-356167 to 1.4 > commons-fileupload 1.1-dev to 1.1 > jasper from 5.5.9 to 5.5.15 > Jetty from 5.1.9 to 5.1.10 > stax from 1.1.1-dev to 1.1.2 > Tomcat 5.5.9 to 5.5.15 > tranql from1.2.1 to 1.3-SNAPSHOT > tranql-connector from 1.1 to 1.2-SNAPSHOT > > Keep 'em coming. > > Matt > > Aaron Mulder wrote: > > That issue has a great list. > > > > We definitely need to try updating commons-fileupload (from 1.1-dev to > > 1.1). I think there may even be a separate Jira for that. But the > > old one occasionally hangs, so it's definitely worth trying the new > > one. > > > > Thanks, > >Aaron > > > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> Here are the packages I'm recommending for 1.1. If I missed one > >> please chime in. > >> > >> Axis from 1.4-356167 to 1.4 > >> jasper from 5.5.9 to 5.5.15 > >> Jetty from 5.1.9 to 5.1.10 > >> stax from 1.1.1-dev to 1.1.2 > >> tranql from1.2.1 to 1.3-SNAPSHOT > >> tranql-connector from 1.1 to 1.2-SNAPSHOT > >> > >> This is the list so far...I've updated > >> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > >> > >> with this information. > >> > >> Was mentioned on the list: > >> Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division
[jira] Resolved: (GERONIMO-2003) Remove geronimo-config-1.1.xsd
[ http://issues.apache.org/jira/browse/GERONIMO-2003?page=all ] Sachin Patel resolved GERONIMO-2003: Resolution: Invalid My bad, no longer in image after a clean rebuild > Remove geronimo-config-1.1.xsd > -- > > Key: GERONIMO-2003 > URL: http://issues.apache.org/jira/browse/GERONIMO-2003 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Sachin Patel > Fix For: 1.1 > > Remove geronimo-config-1.1.xsd atleast out of the distribution in the schemas > directory as this will lead to confusion since it has been replaced by > geronimo-module-1.1.xsd -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1 Package Upgrade List
I'd rather handle the ApacheDS integration separately from the 1.1 release. Fortunately, the plugins work with the Maven 2 repository, so that issue should be easier. The main question is how to do the build and packaging. If the API is unchanged, we can build our integration module using our Maven 1 packaging plugin against ADS 0.9.2 and just have it apply the 1.0.x JARs at installation time. If the API is different, it may make the most sense to try to split out our directory integration and do the build and packaging under Maven 2 (I'm assuming that Geronimo HEAD has a Maven 2 packaging plugin, but if not, I guess we can work on one). Thanks, Aaron On 5/10/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote: ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: > Consolidated list so far is: > > Axis from 1.4-356167 to 1.4 > commons-fileupload 1.1-dev to 1.1 > jasper from 5.5.9 to 5.5.15 > Jetty from 5.1.9 to 5.1.10 > stax from 1.1.1-dev to 1.1.2 > Tomcat 5.5.9 to 5.5.15 > tranql from1.2.1 to 1.3-SNAPSHOT > tranql-connector from 1.1 to 1.2-SNAPSHOT > > Keep 'em coming. > > Matt > > Aaron Mulder wrote: > > That issue has a great list. > > > > We definitely need to try updating commons-fileupload (from 1.1-dev to > > 1.1). I think there may even be a separate Jira for that. But the > > old one occasionally hangs, so it's definitely worth trying the new > > one. > > > > Thanks, > >Aaron > > > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > >> Here are the packages I'm recommending for 1.1. If I missed one > >> please chime in. > >> > >> Axis from 1.4-356167 to 1.4 > >> jasper from 5.5.9 to 5.5.15 > >> Jetty from 5.1.9 to 5.1.10 > >> stax from 1.1.1-dev to 1.1.2 > >> tranql from1.2.1 to 1.3-SNAPSHOT > >> tranql-connector from 1.1 to 1.2-SNAPSHOT > >> > >> This is the list so far...I've updated > >> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking > >> > >> with this information. > >> > >> Was mentioned on the list: > >> Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division
Re: New Feature Wednesday
Awesome! We've needed this for a while. It would be great if we could auto link the build and the changelog to the download site. On May 10, 2006, at 9:26 AM, David Blevins wrote: All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Latest+Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David -sachin
patch for geronimo integration
While working on a patch for GERONIMO-1896 I noticed that hostname and port changes I made to the activemq connectors via the geronimo admin console don't get persisted in geronimo's config.xml, causing them to revert to their original values when the server restarts. To fix this problem ActiveMQConnectorGBean needs to declare the host and port attributes as manageable when it creates its gbeaninfo. After creating a patch I went to open an activemq JIRA but I can't select ACTIVEMQ for the project. I can only select ActiveSOAP, ActiveSpace, etc. Maybe I'm looking in the wrong place. Anyway, the patch is attached to this email. Let me know if you need this in a JIRA instead. Best wishes, Paul
New Feature Wednesday
All, I've revived our script that creates unstable builds. Further, I've hooked it up to run every Wednesday at 6am PST. I chose Wednesday as it gives developers a couple days into the week to try and get features in that they'd like people to try out. It also gives a couple days in the week for users to give feedback. The goal is to have a nice steady drum beat of content reaching the community to add more iterations to what is inherently an iterative process. More iterations means more interactions which means a healthier community economy. I could spend forever counting out the benefits to the community and overall quality of the software produced/consumed. Here is the info for the very latest build: Geronimo 1.1-405734 - May 10, 2006 http://cvs.apache.org/dist/geronimo/unstable/1.1-405734/ geronimo-1.1-405734-src.tar.gz geronimo-1.1-405734-src.zip geronimo-jetty-j2ee-1.1-405734.tar.gz geronimo-jetty-j2ee-1.1-405734.zip geronimo-jetty-minimal-1.1-405734.tar.gz geronimo-jetty-minimal-1.1-405734.zip geronimo-tomcat-j2ee-1.1-405734.tar.gz geronimo-tomcat-j2ee-1.1-405734.zip geronimo-tomcat-minimal-1.1-405734.tar.gz geronimo-tomcat-minimal-1.1-405734.zip Changelog: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Latest +Unstable The changelog is automatically generated along with the unstable build, so keep an eye on that page for future updates! All the best, David
Re: 1.1 Package Upgrade List
ApacheDS0.9.2 to 1.0-RC2 ? I have a patch to port the Geronimo part to 1.0-RC2. However, currently ADS 1.0 jars propagated to maven2 repo only. 2006/5/9, Matt Hogstrom <[EMAIL PROTECTED]>: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: > That issue has a great list. > > We definitely need to try updating commons-fileupload (from 1.1-dev to > 1.1). I think there may even be a separate Jira for that. But the > old one occasionally hangs, so it's definitely worth trying the new > one. > > Thanks, >Aaron > > On 5/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: >> Here are the packages I'm recommending for 1.1. If I missed one >> please chime in. >> >> Axis from 1.4-356167 to 1.4 >> jasper from 5.5.9 to 5.5.15 >> Jetty from 5.1.9 to 5.1.10 >> stax from 1.1.1-dev to 1.1.2 >> tranql from1.2.1 to 1.3-SNAPSHOT >> tranql-connector from 1.1 to 1.2-SNAPSHOT >> >> This is the list so far...I've updated >> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking >> >> with this information. >> >> Was mentioned on the list: >> Howl- Researching this -- Alexei Zakharov, Intel Middleware Product Division
[jira] Updated: (GERONIMO-1518) Installer - only copy jars needed by selected configuration
[ http://issues.apache.org/jira/browse/GERONIMO-1518?page=all ] erik daughtrey updated GERONIMO-1518: - Attachment: installer_dev_notes.jar Unfortunately, I will no longer be able to work on the installer. I need to move to other, more pressing projects. Hopefully, someone will be able to pick up the work. I'm not sure if the plan would be to continue with IzPack, but if so, then the attached document will help someone come up to speed on the changes I made. The document was originally intended as a way to start a dialog with the IzPack folks so that we could come to an understanding on how best to move forward with IzPack. I hope that if the work is continued that interaction with the IzPack team will proceed so that both projects may benefit. Good luck to all. Erik > Installer - only copy jars needed by selected configuration > --- > > Key: GERONIMO-1518 > URL: http://issues.apache.org/jira/browse/GERONIMO-1518 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: installer > Versions: 1.2, 1.1 > Reporter: erik daughtrey > Attachments: installer-G1518.patch.gz, installer-jar-refactor-1.0.1.patch, > installer-jar-refactor.patch, installer.G1518-2.patch.gz, > installer_dev_notes.jar > > Install configuration using installer jar as source repository. -- 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-2004) Hot deployment of welcome app failed
Hot deployment of welcome app failed Key: GERONIMO-2004 URL: http://issues.apache.org/jira/browse/GERONIMO-2004 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: All Reporter: Anita Kulshreshtha Fix For: 1.1 This is for rev 405570 and a freshly built j2ee-tomcat-server. The following trace can be produced by - 1. start the server 2. uninstall geronimo/welcome-tomcat/---/car using console. The uninstall was successful. 3. hot deploy 08:44:02,359 INFO [Hot Deployer] Deploying welcome-tomcat-1.1-SNAPSHOT.car 08:44:03,046 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.x ml deployment plan. This may or may not be a problem, depending on whether you have things like res ource references that need to be resolved. You can also give the deployer a separate deployment pla n file on the command line. 08:44:03,921 ERROR [Deployer] Deployment failed due to java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) 08:44:04,031 ERROR [Hot Deployer] Unable to deploy: java.io.IOException: Sum file already exists org.apache.geronimo.common.DeploymentException: java.io.IOException: Sum file already exists at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:349) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) ... 10 more -- 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-2003) Remove geronimo-config-1.1.xsd
[ http://issues.apache.org/jira/browse/GERONIMO-2003?page=comments#action_12378908 ] Sachin Patel commented on GERONIMO-2003: Strange, i rebuilt yesterday and they are both in the distribution. Let me do a clean build. > Remove geronimo-config-1.1.xsd > -- > > Key: GERONIMO-2003 > URL: http://issues.apache.org/jira/browse/GERONIMO-2003 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Sachin Patel > Fix For: 1.1 > > Remove geronimo-config-1.1.xsd atleast out of the distribution in the schemas > directory as this will lead to confusion since it has been replaced by > geronimo-module-1.1.xsd -- 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-2003) Remove geronimo-config-1.1.xsd
[ http://issues.apache.org/jira/browse/GERONIMO-2003?page=comments#action_12378905 ] Aaron Mulder commented on GERONIMO-2003: I don't understand. It's gone from both source and output directories for me. modules/service-builder/src/schema: geronimo-config-1.0.xsd geronimo-module-1.1.xsd geronimo-javabean-xmlattribute-1.0.xsd xmlconfig.xml assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/schema: application_1_2.dtd geronimo-login-config-1.1.xsd application_1_3.dtd geronimo-module-1.1.xsd application_1_4.xsd geronimo-naming-1.1.xsd application-client_1_2.dtd geronimo-security-1.1.xsd application-client_1_3.dtd geronimo-web-1.1.xsd application-client_1_4.xsd j2ee_1_4.xsd connector_1_0.dtd j2ee_jaxrpc_mapping_1_1.xsd connector_1_0.xsd j2ee_web_services_1_1.xsd connector_1_5.xsd j2ee_web_services_client_1_1.xsd corba-css-config-2.0.xsdjsp_2_0.xsd corba-tss-config-2.0.xsdopenejb-jar-2.1.xsd ejb-jar_1_1.dtd openejb-pkgen-2.0.xsd ejb-jar_2_0.dtd web-app_2_2.dtd ejb-jar_2_1.xsd web-app_2_3.dtd geronimo-application-1.1.xsdweb-app_2_4.xsd geronimo-application-client-1.1.xsd web-jsptaglibrary_1_1.dtd geronimo-connector-1.1.xsd web-jsptaglibrary_1_2.dtd geronimo-javabean-xmlattribute-1.0.xsd wsdl.xsd geronimo-jetty-1.1.xsd xml.xsd geronimo-jetty-config-1.0.xsd > Remove geronimo-config-1.1.xsd > -- > > Key: GERONIMO-2003 > URL: http://issues.apache.org/jira/browse/GERONIMO-2003 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Reporter: Sachin Patel > Fix For: 1.1 > > Remove geronimo-config-1.1.xsd atleast out of the distribution in the schemas > directory as this will lead to confusion since it has been replaced by > geronimo-module-1.1.xsd -- 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-2003) Remove geronimo-config-1.1.xsd
Remove geronimo-config-1.1.xsd -- Key: GERONIMO-2003 URL: http://issues.apache.org/jira/browse/GERONIMO-2003 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Fix For: 1.1 Remove geronimo-config-1.1.xsd atleast out of the distribution in the schemas directory as this will lead to confusion since it has been replaced by geronimo-module-1.1.xsd -- 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: undeploy, redeploy and hot-deploy
Anita, Could you create a Jira for the behavior you're describing below? It looks like the application was already in the repository and the hot deploy caused it to be written in there again, which seems to have confused it (whereas it probably should have just overwritten it, unless it was already running or something). I think it may be fixed when we give the hot deployer a little update, but we should be sure. Thanks, Aaron On 5/9/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: Aaron, Thanks! These issues have been fixed in rev 405570. I have resolved both the issues. I hope that is ok. I tried hot-deploying the welcome app without the plan and got the following trace - 23:06:00,359 INFO [Hot Deployer] Deploying welcome-tomcat-1.1-SNAPSHOT.car 23:06:00,953 WARN [TomcatModuleBuilder] Web application . does not contain a WEB-INF/geronimo-web.x ml deployment plan. This may or may not be a problem, depending on whether you have things like res ource references that need to be resolved. You can also give the deployer a separate deployment pla n file on the command line. 23:06:01,609 ERROR [Deployer] Deployment failed due to java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) 23:06:01,718 ERROR [Hot Deployer] Unable to deploy: java.io.IOException: Sum file already exists org.apache.geronimo.common.DeploymentException: java.io.IOException: Sum file already exists at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:349) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:119) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeploy Command.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java: 60) at java.lang.Thread.run(Thread.java:534) Caused by: java.io.IOException: Sum file already exists at org.apache.geronimo.system.configuration.ConfigurationStoreUtil.writeChecksumFor(Configur ationStoreUtil.java:46) at org.apache.geronimo.system.configuration.ExecutableConfigurationUtil.writeConfiguration(E xecutableConfigurationUtil.java:156) at org.apache.geronimo.system.configuration.RepositoryConfigurationStore.install(RepositoryC onfigurationStore.java:319) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:308) ... 10 more Thanks Anita --- Aaron Mulder <[EMAIL PROTECTED]> wrote: > Please test again since Dain committed the patch yesterday. In my > testing, this did allow "undeploy myapp". If it doesn't work for > you, > can you give specific steps to reproduce the problem using the > welcome > sample application (applications/welcome/target/*.war and if needed, > configs/welcome-jetty/target/plan/plan.xml). > > Thanks, > Aaron > > On 5/9/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > > This refers to - > > http://issues.apache.org/jira/browse/GERONIMO-1945 and > > http://issues.apache.org/jira/browse/GERONIMO-1971 > > If a webapp with named "myapp" is deployed, It gets deployed as > > default/myapp//war. it is not possible to undeploy it with - > > ja
[jira] Commented: (GERONIMO-1818) ActiveMQ broker is shutting down before the rest of the server
[ http://issues.apache.org/jira/browse/GERONIMO-1818?page=comments#action_12378876 ] Jules Gosnell commented on GERONIMO-1818: - It looks like support for this property/fn-ality disappeared between 3.2.2 and 4.0-M4 - it is also not in trunk at the time of this comment. Geronimo seems to be on AMQ 4.0-SNAPSHOT - so I would expect this issue to be present. : [EMAIL PROTECTED] geronimo-trunk]$ find . -name pom.xml | xargs grep activeMqVersion ./pom.xml:4.0-SNAPSHOT WADI is being bitten by the same problem: http://jira.codehaus.org/browse/WADI-76 I have posted activemq-user asking for help. As soon as WADi has a fix, I will report back. Jules > ActiveMQ broker is shutting down before the rest of the server > -- > > Key: GERONIMO-1818 > URL: http://issues.apache.org/jira/browse/GERONIMO-1818 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: kernel > Versions: 1.1 > Reporter: Kevan Miller > Fix For: 1.1 > > The ActiveMQ broker is shutting down before the rest of the Geronimo server. > This can result in several errors (deadlock and infinite recursion) as well > as annoying info messages like: > Server shutdown begun > 13:49:11,666 INFO [ActiveMQAsfEndpointWorker] Endpoint connection to JMS > broker failed: Initialization of TcpTransportChannel failed. URI was: > tcp://localhost:61616 Reason: java.net.ConnectException: Connection refused > 13:49:11,666 INFO [ActiveMQAsfEndpointWorker] Endpoint will try to reconnect > to the JMS broker in 30 seconds > Server shutdown completed > In the past, these problems have been avoided by the following in the > activemq-broker config plan: > class="org.apache.geronimo.system.properties.SystemProperties"> > > activemq.broker.disable-clean-shutdown=true > > > However, it doesn't seem to be working. Seem to be 3 possible explanations: > 1) The SystemProperties GBean is not working. > 2) The order of GBean shutdown has been changed and the broker is being > stopped before clients are stopped. > 3) ActiveMQ 3.2.4 disable-clean-shutdown processing is broken. > Most likely explanation is 1) or 2)... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1899) Build includes J2EE 1.1-SNAPSHOT spec
[ http://issues.apache.org/jira/browse/GERONIMO-1899?page=all ] David Jencks closed GERONIMO-1899: -- Resolution: Fixed Assign To: David Jencks Primarily through Joe Bohn's efforts all but one of the appearances of the uber-spec jar were already removed from the assemblies. I just removed the last, from the installer, in rev 405652. There are still some individual spec jars that need to be released as 1.1 final versions. > Build includes J2EE 1.1-SNAPSHOT spec > - > > Key: GERONIMO-1899 > URL: http://issues.apache.org/jira/browse/GERONIMO-1899 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: core, buildsystem, console > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: David Jencks > Priority: Blocker > Fix For: 1.1 > > The current 1.1 build includes several individual J2EE specs at the 1.0 > release level, then the spec uberJAR at the 1.1-SNAPSHOT release level. > I don't think we want to be using the spec uberJAR at all, but if we do, we > shouldn't be using a SNAPSHOT of it for the final 1.1 release. -- 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
