[jira] Created: (AMQ-849) Not all properties of the Message are copied during a call to Message.copy(Message)
Not all properties of the Message are copied during a call to Message.copy(Message) --- Key: AMQ-849 URL: https://issues.apache.org/activemq/browse/AMQ-849 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.2, 4.0.1 Reporter: Mathew Kuppe Fix For: 4.0.3 Attachments: message-copy-patch.txt Noticed that when using copyOnSend feature and compression, sent messages were not being compressed. It was then found that this was due to the fact that the connection that is used to determine whether compression should be performed or not, was null for the copied message. A look into the Message found that the connection and a number of other properties of the Message were not copied in the copy(Message) The patch attached copies the remaining properties of the Message to the message copy. -- 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
Anonymous read and authenticated write access to a destination
Hi I want to allow unauthenticated connections to read from a destination, and allow writes only to authenticated connections. e.g. *anyone* can read from a queue, but only a member of the admin group can write.. How can I specify an AuthorizationEntry for this? The following entries does not work authorizationEntry queue= read=* write=admins admin=admins/ authorizationEntry queue= read=anonymous write=admins admin=admins/ thanks asankha -- View this message in context: http://www.nabble.com/Anonymous-read-and-authenticated-write-access-to-a-destination-tf2013985.html#a5535072 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Resolved: (AMQ-733) Minor renaming of kaha module
[ https://issues.apache.org/activemq/browse/AMQ-733?page=all ] Adrian Co resolved AMQ-733. --- Resolution: Fixed Renamed KahaPersistentAdaptor to KahaPersistenceAdapter Minor renaming of kaha module - Key: AMQ-733 URL: https://issues.apache.org/activemq/browse/AMQ-733 Project: ActiveMQ Issue Type: Wish Components: Message Store Affects Versions: 4.0 Reporter: Adrian Co Assigned To: Adrian Co Priority: Trivial Fix For: 4.1 I was wondering if we can rename KahaPersistentAdaptor to KahaPersistenceAdapter just to be consistent with the rest of the persistence adapters. Also, should the package kahadaptor be kahaadapter or just plain kaha? :) Assign the jira to me if you're ok with the changes, I don't mind doing the renaming. Thanks! :) -- 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
ActiveMQ OpenWire .NET Example
Hi, Does anybody have any working examples using the ActiveMQ OpenWire .NET client libraries? We've been digging arround for ages and not been able to find anything that makes much sense. Thanks Carl -- View this message in context: http://www.nabble.com/ActiveMQ-OpenWire-.NET-Example-tf2014936.html#a5537968 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Resolved: (AMQ-522) get ProxyConnectorTest to work
[ https://issues.apache.org/activemq/browse/AMQ-522?page=all ] Adrian Co resolved AMQ-522. --- Fix Version/s: 4.1 Resolution: Fixed Tested that this is passing in windows and linux. Although it takes 379 secs to complete in linux, while it only takes 9 secs in windows. get ProxyConnectorTest to work -- Key: AMQ-522 URL: https://issues.apache.org/activemq/browse/AMQ-522 Project: ActiveMQ Issue Type: Test Components: Test Cases Affects Versions: 4.0 Environment: Linux, jdk 1.5 Reporter: Fritz Oconer Assigned To: Adrian Co Fix For: 4.1 Running this test case hangs in iago.simulalabs.com. The test log file is empty. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ OpenWire .NET Example
On 7/28/06, cbourne [EMAIL PROTECTED] wrote: James, Thanks for the quick response. We're new to JMS type messaging systems but have good C# skills. ActiveMQ looks like it will fit the needs of our project perfectly. Great. BTW we'd appreciate some feedback on the C# build and code from good C# developers :) e.g. is there an easy way to get it to auto generate javadoc type stuff for the NMS API etc We've been looking through the test cases but they are a bit cryptic to us at the moment. We could do with a couple of really simple examples that maybe shows producing/consuming binary data. i.e. Something like reading a binary file sending it to a queue and then reading the file back of the queue. This example shows how to send and receive messages... http://incubator.apache.org/activemq/openwire-dotnet.html the main difference is you'll not be using ITextMessage objects but using IBytesMessage instead and setting the Content property to be a byte[] -- James --- http://radio.weblogs.com/0112098/
Re: Source File Header Changes
I was a bit sleepless tonight and I think I got most of the headers converted. Committing since the changes should not cause any merge conflicts (I doubt anybody else was editing the source headers.) On 7/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: We soon need to make a large set of source file header changes do to recent policy changes.. see: http://www.apache.org/legal/src-headers.html. Hopefully I'll get some time in the next few days and I'll tackle this. Please let me know if you got some big changes pending commit and want me to avoid changing the headers to avoid a commit conflict. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: New graphical Eclipse tool : CIMERO
BTW are you still considering where to donate/host the code - are you planning to turn it into a new open source project? e.g. do you fancy donating to the ServiceMix project and we could integrate it together with the existing Maven and Eclipse tooling? On 7/28/06, Pierre NOTEL [EMAIL PROTECTED] wrote: Thanks for the wiki. We sent our plugins and a flash demonstration. More documentation should arrive... So you can see and test the CIMERO plugin at : http://goopen.org/confluence/display/ACTIVEMQ/Cimero. We are waiting for feedback. Cheers, Pierre NOTEL Cédric MOUILLERON //** James Strachan wrote: I've created a wiki page that you can attach screenshots and examples to - I've started with the screen shot you previously sent http://goopen.org/confluence/display/ACTIVEMQ/Cimero Though Apache can't host LGPL code so am not sure if you should attach any of your code; but documentation screenshots should be fine. On 7/28/06, Pierre NOTEL [EMAIL PROTECTED] wrote: I have a problem to send you our plugins because they are rejected by the mailing list. The size of these two jar files is 370Ko so I assume it's too big for a single mail on the list. I can send them directly to interessed people. If anybody has an other solution to share these plugin Cheers, Pierre NOTEL Cédric MOUILLERON //* James Strachan wrote: On 7/27/06, Jerome Camilleri [EMAIL PROTECTED] wrote: James Strachan wrote: Thanks for the heads up! Do you have a link to the project? No link because for the moment it's an internal project but we would like to publish it. Ah OK :) Is your intention to create an open source project out of it and host it some place or was it a one-off experiment? Either way as soon as there is a URL to where it lives so folks can look at it/download it we'll be happy to add a link to the wiki. (Its a wiki so you can do it yourself actually :) Pierre seems to have forgotten to attach a screenshot to have a quick look. Screenshots rock :) They will send to the mailing list a beta version of cimero for testing it. Great! -- James --- http://radio.weblogs.com/0112098/
[jira] Resolved: (SM-352) Empty service assembly name prevents service units from start
[ https://issues.apache.org/activemq/browse/SM-352?page=all ] Guillaume Nodet resolved SM-352. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Author: gnodet Date: Fri Jul 28 17:30:57 2006 New Revision: 426721 URL: http://svn.apache.org/viewvc?rev=426721view=rev Log: SM-352: add more tests on the jbi descriptor Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/deployment/DescriptorFactory.java Empty service assembly name prevents service units from start - Key: SM-352 URL: https://issues.apache.org/activemq/browse/SM-352 Project: ServiceMix Issue Type: Bug Components: servicemix-core Affects Versions: 3.0 Environment: servicemix snapshot created 15-Feb-2006 Reporter: Ilya Kuleshov Assigned To: Guillaume Nodet Priority: Minor Fix For: 3.0-M3 Original Estimate: 15 minutes Remaining Estimate: 15 minutes In case the service assembly name was accidently left empty, an incorrect directory path is being created for the SA (like /wdir/defaultJBI/service-assemblies/version_1). This in turn does not allow service units to initialize after the ServiceMix restart. It would be better to raise some error if empty SA name was found in the descriptor. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2233) Deployment fails with InvalidConfigException: Unable to deserialize GBeanState when Sun JMX RI JAR is on classpath in EAR
[ http://issues.apache.org/jira/browse/GERONIMO-2233?page=all ]
John Sisson updated GERONIMO-2233:
--
Description:
h1. Problem
Deployment of an EAR that contains the Sun JMX RI 1.2 JAR in the classpath set
in the META-INF/MANIFEST.MF file of the JAR in the EAR fails. An EAR may
include a JMX implementation library so that it can run on J2EE 1.3 servers.
h1. Symptoms
The following error is seen on the server console:
{code}
23:58:47,831 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state: abstractName=geronimo-test/jira-g-n
nnn/1.0-SNAPSHOT/ear?configurationName=geronimo-test/jira-g-/1.0-SNAPSHOT/ear
org.apache.geronimo.kernel.config.InvalidConfigException: Unable to deserialize
GBeanState
at
org.apache.geronimo.kernel.config.SerializedGBeanState.loadGBeans(SerializedGBeanState.java:120)
at
org.apache.geronimo.kernel.config.SerializedGBeanState.getGBeans(SerializedGBeanState.java:65)
at
org.apache.geronimo.kernel.config.ConfigurationData.getGBeans(ConfigurationData.java:171)
at
org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:277)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:933)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:161)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:292)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:260)
at
org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:112)
at
org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:338)
at
org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.system.jmx.MBeanGBeanBridge.invoke(MBeanGBeanBridge.java:168)
at
mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:221)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:84)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:120)
at
mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:203
)
at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1043)
at
mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219)
at sun.reflect.GeneratedMethodAccessor347.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
Re: Source File Header Changes
Thanks! :) On 7/28/06, Hiram Chirino [EMAIL PROTECTED] wrote: I was a bit sleepless tonight and I think I got most of the headers converted. Committing since the changes should not cause any merge conflicts (I doubt anybody else was editing the source headers.) On 7/27/06, Hiram Chirino [EMAIL PROTECTED] wrote: We soon need to make a large set of source file header changes do to recent policy changes.. see: http://www.apache.org/legal/src-headers.html. Hopefully I'll get some time in the next few days and I'll tackle this. Please let me know if you got some big changes pending commit and want me to avoid changing the headers to avoid a commit conflict. -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2124) Deploying an EAR with included WAR and there included commons-logging fails
[ http://issues.apache.org/jira/browse/GERONIMO-2124?page=all ] Krishnakumar B updated GERONIMO-2124: - Attachment: SimpleServlet.war Hi, I tried this feature in geronimo 1.1 and it works. The geronimo plan has hidden-classes filterorg.apache.log4j/filter /hidden-classes The server repository has log4j - 1.2.8.The application war has log4j 1.2.13 in WEB-INF/lib The Servlet code uses Logger in WEB-INF lib if i give hidden-classes. I call a method on Logger thats not present in 1.2.8 and it works. The example u have attached with JIRA also works. Hence i am not sure why u got the exception except i see a change in JDK I have used JDK1.4.2_09 Deploying an EAR with included WAR and there included commons-logging fails --- Key: GERONIMO-2124 URL: http://issues.apache.org/jira/browse/GERONIMO-2124 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0 Environment: Ubuntu Linux Java 5.0 Geronimo 1.0 with Tomcat Reporter: Markus Wolf Attachments: ear-test.tar.gz, SimpleServlet.war I have an EAR archive containing a WAR archive. Inside this WAR archiv there is commons-logging bundled. To hide the commons-logging version from Geronimo the geronimo-web.xml contains a hidden-classes element with org.apache.commons.logging. But when a servlet is executed (which uses commons-logging) then there is a stacktrace regarding the two commons-logging versions. I got the following stacktrace: 15:39:45,536 ERROR [[/simpleservlet]] StandardWrapper.Throwable org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at de.nmmn.simple.SimpleServlet.init(SimpleServlet.java:44) at javax.servlet.GenericServlet.init(GenericServlet.java:168) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:750) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at
[jira] Updated: (GERONIMO-2124) Deploying an EAR with included WAR and there included commons-logging fails
[ http://issues.apache.org/jira/browse/GERONIMO-2124?page=all ] Krishnakumar B updated GERONIMO-2124: - Kindly try out the attached war SimpleServlet.war and see if it works in ur environment. We can then work on this issue or close it. Deploying an EAR with included WAR and there included commons-logging fails --- Key: GERONIMO-2124 URL: http://issues.apache.org/jira/browse/GERONIMO-2124 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 1.0 Environment: Ubuntu Linux Java 5.0 Geronimo 1.0 with Tomcat Reporter: Markus Wolf Attachments: ear-test.tar.gz, SimpleServlet.war I have an EAR archive containing a WAR archive. Inside this WAR archiv there is commons-logging bundled. To hide the commons-logging version from Geronimo the geronimo-web.xml contains a hidden-classes element with org.apache.commons.logging. But when a servlet is executed (which uses commons-logging) then there is a stacktrace regarding the two commons-logging versions. I got the following stacktrace: 15:39:45,536 ERROR [[/simpleservlet]] StandardWrapper.Throwable org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed.)) at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) at de.nmmn.simple.SimpleServlet.init(SimpleServlet.java:44) at javax.servlet.GenericServlet.init(GenericServlet.java:168) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:750) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:130) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:272) at org.apache.geronimo.tomcat.valve.TransactionContextValve.invoke(TransactionContextValve.java:53) at org.apache.geronimo.tomcat.valve.ComponentContextValve.invoke(ComponentContextValve.java:47) at org.apache.geronimo.tomcat.valve.InstanceContextValve.invoke(InstanceContextValve.java:60) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.commons.logging.LogConfigurationException: org.apache.commons.logging.LogConfigurationException: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by
Issues Closed: week of 07-28-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** Bug * [GERONIMO-2208] bad classpath in geronimo-deploy-jsr88-1.1.jar * [GERONIMO-2202] Move to new Apache Maven 1 repo (repo/m1-snapshot-repository * [GERONIMO-] Application errors in static initialization blocks during serialization of configuration during deployment due to incorrect TCCL * [GERONIMO-2234] User can lock the default keystore without warning, making jetty server unusable * [GERONIMO-2182] Add 1.1 schemas to web site * [GERONIMO-2120] Can't have ejb references outside current config. ClassCastException on org.openejb.proxy.ProxyInfo * [GERONIMO-2199] Key portion of Geronimo-1145 appears have gotten lost. * [GERONIMO-2198] CSSBean creates 2 unnecessary threads for every instance. * [GERONIMO-1695] CORBA for EJB with Local interface only causes NPE * [GERONIMO-1959] Console: plugin % complete shoudl reset to 0 while preparing a download * [GERONIMO-2072] Client-Deployer config is using wrong/hardcoded commons-primitives version * [GERONIMO-2097] PluginRepositoryExporter.updateMavenMetadata(..) may leave maven-metadata.xml file open * [GERONIMO-2138] Configuration jsp-examples-tomcat includes Jetty dependencies * [GERONIMO-1817] Test a Login while adding LDAP Realm fails with NullPointerException * [GERONIMO-1791] LDAP Security Realm created via Console can fail deployment * [GERONIMO-1781] FileSystemRepository not able to handle entry with version number which is a single digit * [GERONIMO-1182] Connector portlet delete challenge * [GERONIMO-2145] NPE in Maven1Repository * [GERONIMO-1960] Bad GBean reference isn't caught during deployment ** Improvement * [GERONIMO-1037] Clicking on uninstall link in Applications management pages deletes the configuration without any confirmation from user * [GERONIMO-1538] Update the website to use the new look and feel from Epiq * [GERONIMO-1380] New Graphics for Geronimo Web Site ** Task * [GERONIMO-2073] Copyright date in the console needs to be updated
Re: problems with servicemix-common mvn2 poms and trunk
If you build the whole source tree at once, the problem should not appear. Recently, I have tried to upload new snapshots, but the process failed with the same kind of error you mentionned. :( However it seems to work build running mvn install instead. Cheers, Guillaume Nodet On 7/27/06, Renaud Bruyeron [EMAIL PROTECTED] wrote: I've been trying to build from source (from trunk) for a couple of days, and every day I run into the same issue with the servicemix-common artifact on the mvn2 repos: [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.servicemix:servicemix-common:jar:3.0-incubating-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.servicemix -DartifactId=servicemix-common \ -Dversion=3.0-incubating-20060726.220305-4 -Dpackaging=jar -Dfile=/path/to/file Path to dependency: 1) org.apache.servicemix:servicemix-jms:jbi-component:3.0-incubating-SNAPSHOT 2) org.apache.servicemix:servicemix-soap:jar:3.0-incubating-SNAPSHOT 3) org.apache.servicemix:servicemix-common:jar:3.0-incubating-20060726.220305-4 If I look into the mvn2 repo on http://people.apache.org/maven-snapshot-repository/, I see this jar: servicemix-common-3.0-incubating-20060726.220305-5.jar For all the other modules, I see jars with 20060726.220305-4. Why the discrepancy? I had the same issue yesterday with servicemix-common as well: all the other modules were ok, but servicemix-common had its time stamp shifted by one as well in the repo. Anyone else having the problem? I have to download servicemix-common-3.0-incubating-20060726.220305-5.jar and install it as 20060726.220305-4 like mvn tells me to do to be able to build servicemix, which seems weird to me. - Renaud -- Cheers, Guillaume Nodet
Re: Exception handling
There is nothing to really help you doing that. But you're right, it may be worth creating an EIP pattern for that. Could you please raise a JIRA ? If you have any time to write this small component, please do ;) On 7/27/06, travi [EMAIL PROTECTED] wrote: If i need to route message based on if an error occurs or not what do I do? Example I pass a message m0 to component c1, then pass message from component c1 to c2, if c2 returns an error I want to pass the contents in m0 to component c3. How can I do this, is there some EIP pattern to do this or do I need to write some custom component. Thanks. -- View this message in context: http://www.nabble.com/Exception-handling-tf2011368.html#a5527124 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
[jira] Created: (SM-504) Beanflow: Multiple execution of beanflow steps
Beanflow: Multiple execution of beanflow steps
--
Key: SM-504
URL: https://issues.apache.org/activemq/browse/SM-504
Project: ServiceMix
Issue Type: Bug
Affects Versions: incubation
Environment: Windows2K, running ServiceMix under JBoss4.0.3SP1
Reporter: Andreas Held
Consider the following simple Beanflow example:
public class TestWorkflow extends WorkflowString {
private static Logger log =
Logger.getLogger(TestWorkflow.class.getName());
public static int count = 0;
public TestWorkflow() {
super(startStep);
}
public String startStep() {
count += 1;
log.info(Workflow: Validation);
// next step
return persistenceStep;
}
public String persistenceStep() {
count += 1;
log.info(Workflow: Persistence);
// next step
return transferStep;
}
public String transferStep() {
count += 1;
log.info(Workflow: Transfer);
// next step
return stop;
}
}
If I write a JUnit test case with assertEquals(workflow.count, 3); then
this will fail, as count has a value of 5. Looking at the log shows the
following output:
08:19:26,335 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: startStep
08:19:26,351 INFO [ch.bbp.igt.comm.ServiceMix.TestWorkflow.startStep()]
FileActWorkflow: Validation
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: persistenceStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.persistenceStep()]
FileActWorkflow: Persistence
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: transferStep
08:19:26,351 INFO
[ch.bbp.igt.comm.ServiceMix.TestWorkflow.transferStep()]
FileActWorkflow: Transfer
08:19:26,351 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
08:19:26,367 DEBUG [org.apache.servicemix.beanflow.Workflow.run()] About
to execute step: stop
This means, all steps but the start step are executed twice! This
corresponds to count being 5 in the end!
JUnit Testcase :
public class WorkflowTest extends TestCase {
public WorkflowTest(String s) {
super(s);
}
protected void setUp() {
}
protected void tearDown() {
}
public void testTest() throws Exception {
TestWorkflow workflow = new TestWorkflow();
workflow.start();
Thread.sleep(2000);
assertEquals(3, workflow.count);
}
public static Test suite() {
TestSuite suite = new TestSuite();
suite.addTest(new WorkflowTest(testTest));
return suite;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-850) add the ability to timeout a prefetch buffer to prevent a single consumer grabbing messages
add the ability to timeout a prefetch buffer to prevent a single consumer grabbing messages --- Key: AMQ-850 URL: https://issues.apache.org/activemq/browse/AMQ-850 Project: ActiveMQ Issue Type: New Feature Components: Broker Reporter: james strachan Fix For: 4.2 If a MessageConsumer is created but not used, it still tends to get its prefetch-buffer worth of messages. If it does not process them within a specific time the consumer should either be closed, or the messages unacked and flushed from the buffer so that the consumer does not hog the messages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-851) move the XPath filtering components out of the activemq-core module into activemq-optional to reduce the dependencies of the activemq-core POM to only minimal stuff
move the XPath filtering components out of the activemq-core module into activemq-optional to reduce the dependencies of the activemq-core POM to only minimal stuff Key: AMQ-851 URL: https://issues.apache.org/activemq/browse/AMQ-851 Project: ActiveMQ Issue Type: Improvement Reporter: james strachan Assigned To: Jonas Lim Priority: Minor to remove dependencies on things like JAXP1.3, jaxen, xmlbeans etc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [m2 build] Test failure in activation module
Your suspicion about the JDK version became stronger when the same activation module built successfully on my Linux machine which has jdk 1.4.2_10. The windows machine on which it failed had jdk 1.5.0_06. I think we should exclude this test for now. Then we should fix the test to account for differences in jdk versions. What say you ? Cheers Prasad. On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI, this was the test that I had commented out before in that module... that mysteriously started working. Maybe it is related to the JDK version? Just a guess though. --jason On Jul 27, 2006, at 11:51 AM, Prasad Kashyap wrote: At revision 426188. Clean local repo Test in activation module fails. Anybody know what suddenly changed there ? -- --- Test set: org.apache.geronimo.activation.handlers.MailcapTest -- - Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec FAILURE! testTextPlainHandler (org.apache.geronimo.activation.handlers.MailcapTest) Time elapsed: 0.03 sec FAILURE! junit.framework.ComparisonFailure: expected:...activation.handlers.TextPlain... but was:...mail.handlers.Text... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.geronimo.activation.handlers.MailcapTest.testTextPlainHandl er(MailcapTest.java:34) Cheers Prasad
Re: [m2 build] Test failure in activation module
Sounds reasonable to disable this test for now. On that note, I'm also starting to lean towards disabling modules/ timer tests for now too. --jason On Jul 28, 2006, at 6:04 AM, Prasad Kashyap wrote: Your suspicion about the JDK version became stronger when the same activation module built successfully on my Linux machine which has jdk 1.4.2_10. The windows machine on which it failed had jdk 1.5.0_06. I think we should exclude this test for now. Then we should fix the test to account for differences in jdk versions. What say you ? Cheers Prasad. On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI, this was the test that I had commented out before in that module... that mysteriously started working. Maybe it is related to the JDK version? Just a guess though. --jason On Jul 27, 2006, at 11:51 AM, Prasad Kashyap wrote: At revision 426188. Clean local repo Test in activation module fails. Anybody know what suddenly changed there ? - - --- Test set: org.apache.geronimo.activation.handlers.MailcapTest - - - Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec FAILURE! testTextPlainHandler (org.apache.geronimo.activation.handlers.MailcapTest) Time elapsed: 0.03 sec FAILURE! junit.framework.ComparisonFailure: expected:...activation.handlers.TextPlain... but was:...mail.handlers.Text... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.geronimo.activation.handlers.MailcapTest.testTextPlainHand l er(MailcapTest.java:34) Cheers Prasad
Re: [m2 build] Test failure in activation module
Hallelujah !!! Cheers Prasad On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Sounds reasonable to disable this test for now. On that note, I'm also starting to lean towards disabling modules/ timer tests for now too. --jason On Jul 28, 2006, at 6:04 AM, Prasad Kashyap wrote: Your suspicion about the JDK version became stronger when the same activation module built successfully on my Linux machine which has jdk 1.4.2_10. The windows machine on which it failed had jdk 1.5.0_06. I think we should exclude this test for now. Then we should fix the test to account for differences in jdk versions. What say you ? Cheers Prasad. On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI, this was the test that I had commented out before in that module... that mysteriously started working. Maybe it is related to the JDK version? Just a guess though. --jason On Jul 27, 2006, at 11:51 AM, Prasad Kashyap wrote: At revision 426188. Clean local repo Test in activation module fails. Anybody know what suddenly changed there ? - - --- Test set: org.apache.geronimo.activation.handlers.MailcapTest - - - Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec FAILURE! testTextPlainHandler (org.apache.geronimo.activation.handlers.MailcapTest) Time elapsed: 0.03 sec FAILURE! junit.framework.ComparisonFailure: expected:...activation.handlers.TextPlain... but was:...mail.handlers.Text... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.geronimo.activation.handlers.MailcapTest.testTextPlainHand l er(MailcapTest.java:34) Cheers Prasad
[jira] Updated: (GERONIMO-2223) [RTC] Move genesis out of the sandbox
[ http://issues.apache.org/jira/browse/GERONIMO-2223?page=all ]
Jason Dillon updated GERONIMO-2223:
---
Description:
h3. Overview
Genesis, which provides common build configuration and plugin modules, is
needed by the main Maven2 build to function.
The project is here:
* http://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/
You need to use the {{build}} or {{bootstrap}} scripts for the first build.
The later will nuke the previous genesis artifacts from the repo to ensure a
clean build (only genesis is removed from the repo).
h3. Recommended Post RTC
{noformat}
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/tags
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/branches
svn mv https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis
https://svn.apache.org/repos/asf/geronimo/genesis/trunk
{noformat}
was:
h3. Overview
Genesis, which provides common build configuration and plugin modules, is
needed by the main Maven2 build to function.
The project is here:
* http://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/
You need to use the {{build}} or {{bootstrap}} scripts for the first build.
The later will nuke the previous genesis artifacts from the repo to ensure a
clean build (only genesis is removed from the repo).
h3. Recommended Post RTC
{noformat}
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/tags
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/branches
svn mv https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis
http://svn.apache.org/repos/asf/geronimo/genesis/trunk
{noformat}
Fixed {{svn mv}} for clarity.
[RTC] Move genesis out of the sandbox
-
Key: GERONIMO-2223
URL: http://issues.apache.org/jira/browse/GERONIMO-2223
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Priority: Critical
Fix For: 1.2
h3. Overview
Genesis, which provides common build configuration and plugin modules, is
needed by the main Maven2 build to function.
The project is here:
* http://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis/
You need to use the {{build}} or {{bootstrap}} scripts for the first build.
The later will nuke the previous genesis artifacts from the repo to ensure a
clean build (only genesis is removed from the repo).
h3. Recommended Post RTC
{noformat}
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/tags
svn mkdir https://svn.apache.org/repos/asf/geronimo/genesis/branches
svn mv https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/genesis
https://svn.apache.org/repos/asf/geronimo/genesis/trunk
{noformat}
--
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: [m2 build] Test failure in activation module
Okay, I disabled the MailcapTest and all of the timer tests for now. --jason On Jul 28, 2006, at 6:31 AM, Prasad Kashyap wrote: Hallelujah !!! Cheers Prasad On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Sounds reasonable to disable this test for now. On that note, I'm also starting to lean towards disabling modules/ timer tests for now too. --jason On Jul 28, 2006, at 6:04 AM, Prasad Kashyap wrote: Your suspicion about the JDK version became stronger when the same activation module built successfully on my Linux machine which has jdk 1.4.2_10. The windows machine on which it failed had jdk 1.5.0_06. I think we should exclude this test for now. Then we should fix the test to account for differences in jdk versions. What say you ? Cheers Prasad. On 7/27/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI, this was the test that I had commented out before in that module... that mysteriously started working. Maybe it is related to the JDK version? Just a guess though. --jason On Jul 27, 2006, at 11:51 AM, Prasad Kashyap wrote: At revision 426188. Clean local repo Test in activation module fails. Anybody know what suddenly changed there ? - - --- Test set: org.apache.geronimo.activation.handlers.MailcapTest - - - Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.06 sec FAILURE! testTextPlainHandler (org.apache.geronimo.activation.handlers.MailcapTest) Time elapsed: 0.03 sec FAILURE! junit.framework.ComparisonFailure: expected:...activation.handlers.TextPlain... but was:...mail.handlers.Text... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.geronimo.activation.handlers.MailcapTest.testTextPlainHand l er(MailcapTest.java:34) Cheers Prasad
[jira] Assigned: (GERONIMO-2219) [RTC] Merge m2migration (functional m2 build) to trunk
[ http://issues.apache.org/jira/browse/GERONIMO-2219?page=all ]
Jason Dillon reassigned GERONIMO-2219:
--
Assignee: Jason Dillon
[RTC] Merge m2migration (functional m2 build) to trunk
--
Key: GERONIMO-2219
URL: http://issues.apache.org/jira/browse/GERONIMO-2219
Project: Geronimo
Issue Type: RTC
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Priority: Critical
Fix For: 1.2
h3. Overview
For the past few weeks we have been busy at work getting Geronimo
1.2-SNAPSHOT to build with Maven 2. As I have noted before in email, the
process is almost complete. At this point the work done so far results in a
functional server for the following assemblies:
* geronimo-jetty-j2ee
* geronimo-jetty-minimal
* geronimo-tomcat-j2ee
* geronimo-tomcat-minimal
The work to implement has been applied to a branch in the sandbox, and
includes many submitted patches from those contributors and commiters that
had been helping with the effort.
My recommendation is that we _merge_ this change to trunk and not generate a
diff and then patch. There are a few changes which patch does not handle
well and will cause failed chunks when applied, and there are a few files
moved and copied, which when patched will cause loss of that history.
As I mentioned this work is _almost complete_, there are still a few pending
issues, please see the section below for more details.
h3. Recommend Action Post RTC
Once we have the required RTC +1's to allow this work to be merged, this is
what I recommend:
# Merge m2migration to trunk as described below
# Deprecate the Maven1 build; meaning leave the m1 files, but strongly urge
developers to use the m2 build
# Enable the TCK _automated_ testing in GBuild using the m2 build
# Remove the m1 build (and related files)
These steps will probably take a few weeks post-merge to complete.
h3. About the Branch
The main branch which should be used for review is:
* https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
I have been using SVK ( http://svk.elixus.org/ ) to keep this m2migration
branch up to date with the latest changes that have been made to trunk (with
a few exceptions). I have been staging the merge as follows:
* merge from {{trunk}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} {{sandbox/svkmerge/m2migration}}
This has worked out very well and I have found that using SVK dramatically
reduces to complexity of performing full tree (or partial tree merges). I
have been verifying that the SVK {{smerge}} is indeed doing the right thing
and I have a good deal of confidence in it at this point.
The idea is to merge m2migration back to trunk using SVK as follows:
* merge from {{sandbox/svkmerge/m2migration}} to {{sandbox/svkmerge/trunk}}
* merge from {{sandbox/svkmerge/trunk}} to {{trunk}}
This is the opposite of what I am performing now on a regular basis to sync
this development branch. Normally the additional branch (svkmerge/trunk)
would not be needed, but it exists to help ensure that the merge is indeed
_doing the right thing_.
h3. Recommended Review Steps
{noformat}
svn co https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/m2migration
cd m2migration
./bootstrap
gunzip -c
m2-assemblies/geronimo-jetty-j2ee/target/geronimo-jetty-j2ee-1.2-SNAPSHOT-bin.tar.gz
| tar xf -
./geronimo-jetty-j2ee/bin/startup.sh tail -f
geronimo-jetty-j2ee/var/log/geronimo.out
./geronimo-jetty-j2ee/bin/shutdown.sh --user system --password manager
{noformat}
*NOTE:* Windows users need to run {{bootstrap}} from a Cygwin environment and
should probably run these steps from the root of a drive (c:, d:, etc) to
better ensure that the long filename problem is not an issue when testing.
*WARNING:* The {{bootstrap}} script will remove your local Maven2 repository
cache and will take maybe 30 minutes or so to run... more or less depending
on how fast your network connection is.
You should define a mirror for the {{central}} m2 repository before
running... otherwise you will almost certainly get repository failures
downloading from ibiblio. This is what I am using (in ~/.m2/settings.xml):
{code:xml}
?xml version=1.0?
settings
mirrors
mirror
idrepo.mergere.com/id
urlhttp://repo.mergere.com/maven2/url
mirrorOfcentral/mirrorOf
/mirror
/mirrors
/settings
{code}
Also, due to the coupling of Geronimo and OpenEJB2, OpenEJB2 must be checked
out and built in the middle of the bootstrapping. Once G is hooked up to CI
and snapshots are being automatically deployed, we can also hook up OpenEJB2
to
Re: Geronimo site POC using Confluence Autoexport
On Jul 27, 2006, at 6:17 PM, Jacek Laskowski wrote: No, definitely not. What I could gather from reading the thread got me thinking about its wide range of possibilities a few in our team seem to be able to fully leverage and judge how useful they would eventually be. I think we need something to keep our web site updated where *everybody* contributes and if Confluence helps us moving in this direction even a little, I'm happy to give it a shot. We can always revert changes and go back to what we've got now, cann't we? So, unless you're busy with other tasks, I'd ask you to go on. Will you? ;-) Okay, I am glad to see there is some support for this. I do believe it is the right direction. I will continue to work on it when I am not working on m2migration. --jason
Re: Geronimo site POC using Confluence Autoexport
I used TimTam a long time ago, and it was really cool... but I don't believe it supports offline editing. Or is that a new feature? --jason On Jul 27, 2006, at 7:53 PM, Bruce Snyder wrote: On 7/27/06, John Sisson [EMAIL PROTECTED] wrote: I think it would be worthwhile continuing to work on this but I think we need to sort out some of the issues mentioned below before we switch over so any committer can update the site without requiring assistance from Infra or yourself. I also agree with Matt's comment about it being preferable to be able to make changes to the site but not have the changes go live instantly. A bit off topic, do you know of any tools to edit pages offline (where you can have a WYSIWYG view of the page) other than installing a confluence server on my notebook? Try TimTam: http://timtam.codehaus.org/ Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\! G;6%I;\YC;VT* );' Apache Geronimo - http://geronimo.apache.org/ Apache ActiveMQ - http://incubator.apache.org/activemq/ Apache ServiceMix - http://incubator.apache.org/servicemix/ Castor - http://castor.org/
Re: Geronimo site POC using Confluence Autoexport
On Jul 27, 2006, at 6:42 PM, John Sisson wrote: A bit off topic, do you know of any tools to edit pages offline (where you can have a WYSIWYG view of the page) other than installing a confluence server on my notebook? Not that I am aware of :-( I just end up installing a confluence server. Someone should embed the personal server into a RCP (Eclipse or NetBeans) and then provide a mechanism to sync one local space to a remote space (complete pull sync, selective push sync). --jason
Re: Geronimo site POC using Confluence Autoexport
On Jul 27, 2006, at 7:35 PM, Bruce Snyder wrote: Maintenance: I doubt we will be using any custom Confluence plugins, the infrastructure team doesn't allow that. We are already using AutoExport... which is custom, and will have to either patch it or fork it to fix the remaining issues. Might also want to look more into a direct SVN plugin, to at the very least commit wiki content to SVN. That could then be used as the basis for future work to sync the SVN content back to a space. Anyways, I don't think we will have a ton of customizations, but I'm sure that we will need a few. I was unaware of any restrictions from infra@ regarding plugins for this puppy. --jason
[jira] Commented: (GERONIMO-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=comments#action_12424096 ] Joe Bohn commented on GERONIMO-2218: Vamsi, Some comments/questions about your patch: In the attached patch why did you change the panel presented in Add Trust Certificate accept only trusted certificate text (which must be cut and pasted) rather than a trusted certificate file as with the front door code? If the goal is to be able to support importing free form certificates then I think we need to support both files and text. I also noticed that after generating a new key it is not posisble to generate a CSR for that key. As you suggested if I lock and then unlock the keystore availability (and unlock the new key as available as well) then I am able to generate the CSR. Can you update the patch to provide the option to unlock the key without the requirement to lock and unlock the keystore? Finally, when viewing the contents of a keystore the are links to view a key both via a initial text on each element (view) and a link on the alias name. Can you please remove the view link and have the link just on the alias name to be consistent with other views (such as the keystore view)? KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any practical scenario. -- 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-1917) repository doesn't deal well with case insensitive file systems
[
http://issues.apache.org/jira/browse/GERONIMO-1917?page=comments#action_12424098
]
Jason Dillon commented on GERONIMO-1917:
I'm not sure what your simple fix was... but why not add an additional check to
{{Repository.contains(Artifact)}} to verify that the case of the file via
{{Repository.getLocation(Artifact)}} matches the values given to {{contains()}}
? If they case does not match, then return false
repository doesn't deal well with case insensitive file systems
---
Key: GERONIMO-1917
URL: http://issues.apache.org/jira/browse/GERONIMO-1917
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: kernel
Affects Versions: 1.1
Reporter: David Jencks
Fix For: 1.1.1
If you've installed a configuration A/B/1/car and then look for a/b/1/car,
the repository will claim it's there on a case insensitive file system, but
then further logic in the config store/ manager blows up because those are
different artifacts. Solution appears to be to check when locating an
artifact that the case from the file system matches the case you are asking
for.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ OpenWire .NET Example
James, Thanks again for the help. We’ve managed to get this to work now using the default settings for ActiveMQ. It works great for smallish (around 1k) but when we send larger binary files (20Mb) then the library seems to just stop part way through the send! Are there any message/queue size settings we need to change? Carl -- View this message in context: http://www.nabble.com/ActiveMQ-OpenWire-.NET-Example-tf2014936.html#a5540768 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems
[ http://issues.apache.org/jira/browse/GERONIMO-1917?page=comments#action_12424101 ] Jason Dillon commented on GERONIMO-1917: Probably easiest to create a string that is the expected pathname in the repository and then get the actual file path and see if the path ends with the expected string. repository doesn't deal well with case insensitive file systems --- Key: GERONIMO-1917 URL: http://issues.apache.org/jira/browse/GERONIMO-1917 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: David Jencks Fix For: 1.1.1 If you've installed a configuration A/B/1/car and then look for a/b/1/car, the repository will claim it's there on a case insensitive file system, but then further logic in the config store/ manager blows up because those are different artifacts. Solution appears to be to check when locating an artifact that the case from the file system matches the case you are asking for. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2209) Enable tests (geronimo-activation :: **/MailcapTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2209?page=all ] Jason Dillon reassigned GERONIMO-2209: -- Assignee: (was: Jason Dillon) Enable tests (geronimo-activation :: **/MailcapTest.java) - Key: GERONIMO-2209 URL: http://issues.apache.org/jira/browse/GERONIMO-2209 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Fix For: 1.2 A few tests failed in non-obvious ways when run under the m2 build. Need someone who knows these tests better to inspect, resolve and enable the test (remove the test exclusions in the pom). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2183) Timer tests will fail on slower machines; unit tests should not be enviornment dependent to pass
[ http://issues.apache.org/jira/browse/GERONIMO-2183?page=all ] Jason Dillon reassigned GERONIMO-2183: -- Assignee: (was: Jason Dillon) Timer tests will fail on slower machines; unit tests should not be enviornment dependent to pass Key: GERONIMO-2183 URL: http://issues.apache.org/jira/browse/GERONIMO-2183 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.2 Reporter: Jason Dillon Priority: Critical Due to the usage of Thread.sleep() in the unit tests (very bad IMO)... and expecting a certain number of invocations in a set period of time, the Timer unit tests can fail when run on slower hardware, or on moderate hardware that is incurring a moderate to high load at the time the tests are run. Tests should not be dependent on the environment they run in... more so on the availability of cycles to process the test to determine the success or failure of the test. The timer tests should be revisited and augmented to produce valid results even on slower or highly loaded systems. -- 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: ActiveMQ OpenWire .NET Example
On 7/28/06, James Strachan [EMAIL PROTECTED] wrote: On 7/28/06, cbourne [EMAIL PROTECTED] wrote: James, Thanks for the quick response. We're new to JMS type messaging systems but have good C# skills. ActiveMQ looks like it will fit the needs of our project perfectly. Great. BTW we'd appreciate some feedback on the C# build and code from good C# developers :) e.g. is there an easy way to get it to auto generate javadoc type stuff for the NMS API etc I just tried adding support for ndoc to the nant build which seems to work OK - though it does take a very long time to run :). I've uploaded the documentation here... http://incubator.apache.org/activemq/nms/ndoc/ I've also tidied up the NMS documentation a little... http://activemq.org/site/nms.html -- James --- http://radio.weblogs.com/0112098/
Re: ActiveMQ OpenWire .NET Example
On 7/28/06, cbourne [EMAIL PROTECTED] wrote: James, Thanks again for the help. We've managed to get this to work now using the default settings for ActiveMQ. It works great for smallish (around 1k) but when we send larger binary files (20Mb) then the library seems to just stop part way through the send! The out of the box ActiveMQ configuration is pretty modest and not setup for much RAM buffer so you probably want to increase this. Note messages are normally fairly small (say under 1Mb) and for larger messages we tend to recommend using JMS streams... http://incubator.apache.org/activemq/jms-streams.html whcih we've not yet implemented in NMS Are there any message/queue size settings we need to change? I'd set a large value for the usageManager to around 400Mb or something then run with a large heap size. http://incubator.apache.org/activemq/xml-configuration.html BTW If you use 4.1-SNAPSHOT you can set this via the following which is a bit simpler usageManager limitMb=400/ -- James --- http://radio.weblogs.com/0112098/
auto-generating documentation for C++ client?
I just figured out a way with NAnt to generate documentation for NMS http://activemq.org/site/javadocs.html which is then copied to where the ActiveMQ site is checked out locally https://svn.apache.org/repos/asf/incubator/activemq/site/ so its easy to deploy to Apache via an svn commit. It'd be nice to do the same for the C++ code too at some point. -- James --- http://radio.weblogs.com/0112098/
[jira] Commented: (GERONIMO-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=comments#action_12424104 ] Vamsavardhana Reddy commented on GERONIMO-2218: --- The reason for using a textarea to paste the content instead of selecting the file is because the upload using file is failing on windows (GERONIMO-1984). I agree with you that both text and file options should be provided (infact I expressed this opinion on the dev-list). But my immediate priority was to comeup with something that works consistently on all platforms. I will update the patch to provide an unlock key link from the certificate details page. The reason for the view link is that it is possible for the keystore to have an entry with (empty string) as alias and such an entry caused problem while viewing its details (GERONIMO-1196). (Though we prevent this possibility with entries added by keystore portlet, it is not necessary that the keystore files our users want to use with geronimo are all created by the keystore portlet.). In this case, there is no way that the entry details can be viewed. KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any practical scenario. -- 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-1035) tomcat integration should wrap each servlet indiviudally
[ http://issues.apache.org/jira/browse/GERONIMO-1035?page=comments#action_12424106 ] Anita Kulshreshtha commented on GERONIMO-1035: -- Donald, tomcat provides statistics for each connector similar to jetty. For more details please see: http://issues.apache.org/jira/browse/GERONIMO-1293#action_12360139 These can be displayed on the connector page. Tomcat does not provide container wide statistics. I do not know if computing these by aggregating per connector statistics provides any benifits. tomcat integration should wrap each servlet indiviudally Key: GERONIMO-1035 URL: http://issues.apache.org/jira/browse/GERONIMO-1035 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: Tomcat Affects Versions: 1.0-M5 Environment: All Reporter: Anita Kulshreshtha Assigned To: Jeff Genender Fix For: 1.2 Attachments: application.patch, applications.patch, applications.patch, geronimo-stats-1.1-SNAPSHOT.war, management.patch, management.patch, management.patch, management.patch, management.patch, management.patch, management.patch, management.patch, pom.patch, stats.zip, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat-builder.patch, tomcat.patch, tomcat.patch, tomcat.patch, tomcat.patch, tomcat.patch TomcatModuleBuilder should wrap each servlet specified in the deployment descriptor individually. This is needed by JSR-77 and for gathering tomcat internal statistics. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2188) Need to configure CommitBeforeAutoCommit=true for Database Commits in Oracle
[ http://issues.apache.org/jira/browse/GERONIMO-2188?page=all ] Donald Woods reassigned GERONIMO-2188: -- Assignee: Matt Hogstrom (was: Donald Woods) Need to configure CommitBeforeAutoCommit=true for Database Commits in Oracle Key: GERONIMO-2188 URL: http://issues.apache.org/jira/browse/GERONIMO-2188 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: connector Affects Versions: 1.1.1 Reporter: Krishnakumar B Assigned To: Matt Hogstrom Attachments: G2188.patch We have to configure CommitBeforeAutCommit=true property exclusively in the database connection pool plan, to have the ejb -based transactions immediately committed for oracle database. Otherwise it only commits transaction when the server shuts-down. This problem is not faces with Derby database. -- 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: Where is the source code for the G samples ?
We need to have these artifacts generated by our build. I don't really care too much where the sources come from... So, if that means branching (since we all use the same SVN repo)... or an svn:externals to pull the right code... or a zip of the sources and a set of patches to apply. If we need some custom changes then we should branch it... else we should use svn:externals. I don't recommend the zip+patches, but that is an option (a sucky option). * * * I don't consider this a fork... we don't want to fork, but we need to have more control over the generation of these artifacts to support our build. What is the SVN URL to the sources of the samples? --jason On Jul 27, 2006, at 1:01 PM, Dave Colasurdo wrote: IIRC, there were a few minor tweaks of the examples.. See GERONIMO-1299 and GERONIMO-1540 for details.. -Dave- Jeff Genender wrote: I believe we used the source from Tomcat verbatim as we did not want to fork the code. In fact IIRC, it was a rename of the jars. Jeff Prasad Kashyap wrote: Does anybody know where I can find the source code for the geronimo samples, jsp-examples and tomcat-examples ? We are using these in our builds from this repository http://people.apache.org/repo/m1-snapshot-repository/geronimo- samples/wars/ We should archive the classes dirs in these wars just like we do to the apps in our build. When these examples wars are used in our build as is, there is a good possibility that it might hit the long path limit on windows. Cheers Prasad
Re: Repository discussion (was GroupId for DayTrader needed)
I think we need to fix up how the repo is used before we can do
anything fancier. Specifically, we need to abstract the usage of
java.io.File. There is already too much going outside of the repo
API to access files directly in the repository.
After that... then we could easily support an aggregated repo view
over a set of repositories.
--jason
On Jul 25, 2006, at 11:45 AM, Matt Hogstrom wrote:
Looks interesting. It does solve some of the issues we're having.
One thing that keeps resonating in my ears from users is Tomcat is
so easy.
The goal of the repository is to store artifacts needed by the
server for both its own internal componentry as well as deployed
applications. At this point (correct me where I'm wrong) but we
have the core repo and in place deployment which allows users to
point to their application. Not to mention hot-deploy.
I haven't thought through this all but do people think users will
require multiple repo strategies? I like the idea of a flat file
structure so people can manipulate the dir on their own without a
server active.
Perhaps we need a repo contest :)
Jason Dillon wrote:
FYI, I have an initial impl of a JDBM-based hybrid repository here:
http://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
geronimo-repository/geronimo-repository-providers/geronimo-
repository-jdbm/ This uses files to store the content to be
compatible wit the existing API, and JDBM for the metadata.
Repository fs looks like:
metadata.db
metadata.lg
data / hash (of groupId, artifactId, version) / artifactId-
version.type
If/when when the repo api is abstracted away from files, thrn it
would be easy to put all content into another artifacts.db to
reduce any chance of long filenames (except for the most insane
cases).
I added a RepositoryCopier util too, so it would be trivial to
make a command-line version to turn a JDBM-repo into an m2-repo
for folks that don't use windows and prefer to see the files as is.
Have not done it yet, but would be easy to write a tool to add a
new file to and repo. Can either specify the artifact or if built
with maven 2, then the META-INF/maven/* bits can be used to
specify the right groupId/artifactId/version/type to install
with. This tool can also complain if not enough information was
given... so it solves the problem of people copying random
artifacts into the repository.
* * *
Also, this http://svn.apache.org/repos/asf/geronimo/sandbox/
svkmerge/geronimo-repository is the new structure I am going to
recommend for future reorg for maven2-based systems, so you might
want to take a peek at the overall tree too. This tree provides
encapsulation of all of the repository components (though
currently missing the impls for m1 and m2 as well as the admin
portlets, but will eventually have them).
NOTE: This is just a POC, no plans yet to move this to trunk in
any way... though eventually I would like to do that.
--jason
On Jul 21, 2006, at 4:34 PM, Dain Sundstrom wrote:
On Jul 20, 2006, at 4:01 PM, Jason Dillon wrote:
It is not just how we use the m2-style repo inside of G, but
also how we build G using m2 that will cause problems for
windows peeps.
The later is going to be more trouble to resolve I think.
I'm still thinking it would be a good idea to have some sort of
file-system abstraction for our m2-style repo... in the same way
that SVN has an abstraction... that could use BDB or a regular
file system (ie. FSFS) for actual storage. WIth something like
this, we could have the default distro use a BDB-ish filesystem
and completely resolve the windows file name limitations. With
a set of cli tools we can easily allow the BDB-ish to be
converted to a FSFS.
The repo is an interface. Well it is really three interfaces
depending how much you want to implement:
public interface Repository {
boolean contains(Artifact artifact);
File getLocation(Artifact artifact);
LinkedHashSet getDependencies(Artifact artifact);
}
public interface WriteableRepository extends Repository {
void copyToRepository(File source, Artifact destination,
FileWriteMonitor monitor) throws IOException;
void copyToRepository(InputStream source, int size, Artifact
destination, FileWriteMonitor monitor) throws IOException;
}
public interface ListableRepository extends Repository {
SortedSet list();
SortedSet list(Artifact query);
}
We have an M1 and M2 implementation of these, so if you want
another one you have some good base code to start with.
-dain
Re: ActiveMQ OpenWire .NET Example
Thanks James! Does the pure C# Stomp client support the Javastreams type functionality - We need to some fairly hefty files if possible! Carl -- View this message in context: http://www.nabble.com/ActiveMQ-OpenWire-.NET-Example-tf2014936.html#a5542164 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: JIRAs adopter query/policy?
Hrm... I'm still unsure that we need this.But... dunno, now that I think about it... its just a way to allow reporters to group their issues.I wish we could get the JIRA label plugin installed, and then the issues could just be labeled.--jasonOn Jul 25, 2006, at 1:11 PM, Sachin Patel wrote:fyihttp://www.eclipse.org/webtools/adopters/On Jul 25, 2006, at 3:01 PM, Jason Dillon wrote:I don't understand exactly what "adopter required" means. Someone is required to adopt the issue? I don't get it :-(I also don't see how companies/customers should get any such entity status in jira for an open source project. Does one need to give more priority to an issue from IBM than an issue submitted by joe user? I don't think so... at least not based on that critical alone.--jasonOn Jul 25, 2006, at 11:26 AM, Sachin Patel wrote:As the Geronimo user base grows, it is important that we be able to distinguish between JIRAs open during a development cycle to those that are being hit in the field or requested by companies who either use Geronimo or build products and or plugins on top of it. So I suggest we provide a restricted "adopter required" field in JIRA. This adopter field would be exposed to JIRA users who request and identify themselves as adopters. So just like our query for available patches, we can easily query these and help ensure that these issues that companies face get the necessary attention and help resolve them faster then they would be otherwise.Thoughts? -sachin -sachin
[jira] Assigned: (GERONIMO-2067) Configs migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all ] Jason Dillon reassigned GERONIMO-2067: -- Assignee: Jason Dillon (was: Anita Kulshreshtha) Configs migration to M2 --- Key: GERONIMO-2067 URL: http://issues.apache.org/jira/browse/GERONIMO-2067 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Jason Dillon Fix For: 1.2 Attachments: applications.patch, applications.patch, configs.log, configs.log, configs.log, configs.log, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, configs.patch, console-configs.patch, etc.patch, etc.patch, hot-deployer.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch, modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml To build these configurations use packaging plugin GERONIMO-1740. This patch builds non openejb and non jetty configurations. This patch is for the new trunk, and has been edited using emcas to rempve ^M. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (GERONIMO-2067) Configs migration to M2
correct.
Thanks
Anita
--- Jason Dillon [EMAIL PROTECTED] wrote:
Okay. In the future can you open new issues for isolated work.
GERONIMO-2067 is already way overloaded IMO.
Looks like m2-plugins.patch and hot-deployer.patch are the only
relevant patches... ?
--jason
On Jul 27, 2006, at 3:47 AM, anita kulshreshtha wrote:
Jason,
I have attached the patches for the car-maven-plugin here for my
convenience just in case I need to refer to something.
Thanks
Anita
--- Anita Kulshreshtha (JIRA) dev@geronimo.apache.org wrote:
[ http://issues.apache.org/jira/browse/GERONIMO-2067?page=all
]
Anita Kulshreshtha updated GERONIMO-2067:
-
Attachment: m2-plugins.patch
hot-deployer.patch
1. The latest m2-plugins.patch is made against m2migration branch
rev
425727.
It include all the things from Jul/27/06 patch and It changes
the
sourceDir parameter to planDir
the configuration is as follows :
planDir --- default value = src/plan or
${basedir}/src/a-dir
planFile -- default value = plan.xml
pluginDir - default value = src/conf or
${basedir}/src/conf
pluginFile - default value = geronimo-plugin.xml
2. The hot-deployer.patch is made against m2migration rev 426029.
The hot-deployer configuration has been changed. The patch
accommodates the recent changes.
Configs migration to M2
---
Key: GERONIMO-2067
URL:
http://issues.apache.org/jira/browse/GERONIMO-2067
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.2
Environment: All
Reporter: Anita Kulshreshtha
Assigned To: Anita Kulshreshtha
Fix For: 1.2
Attachments: applications.patch, applications.patch,
configs.log, configs.log, configs.log, configs.log, configs.patch,
configs.patch, configs.patch, configs.patch, configs.patch,
configs.patch, configs.patch, configs.patch, configs.patch,
console-configs.patch, etc.patch, etc.patch, hot-deployer.patch,
m2-plugins.patch, m2-plugins.patch, m2-plugins.patch,
m2-plugins.patch, m2-plugins.patch, modules.patch, modules.patch,
modules.patch, newconfigs.patch, pom.patch, pom.patch, pom.patch,
pom.patch, pom.xml
To build these configurations use packaging plugin GERONIMO-1740.
This patch builds non openejb and non jetty configurations.
This patch is for the new trunk, and has been edited using emcas
to
rempve ^M.
--
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
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: How to use M2 G Packaging Plugin
That phase has nothing to do with car:install (or car:installConfig). If InstallMojo is not needed anymore, then I don't see any reason not to change car:installConfig to car:install. --jason On Jul 28, 2006, at 9:09 AM, anita kulshreshtha wrote: No, install phase of the car packaging is bound to install:install using plexus component.xml. installorg.apache.maven.plugins:maven-install-plugin:install/ install Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Can I rename car:installConfig to car:install then? --jason On Jul 26, 2006, at 5:06 AM, anita kulshreshtha wrote: --- Jason Dillon [EMAIL PROTECTED] wrote: FYI, newer car plugin side is up: http://geronimo.apache.org/maven/plugins/car-maven-plugin Though due to non-xhtml javadocs in PackageMojo the config page for that mojo is broken. I've fixed it but need to wait again for the site to sync. --jason Great work!! Thanks! The installMojo is not used anywhere. It can be removed. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: How to use M2 G Packaging Plugin
Currently mvn car:prepare-plan -generates target/plan.xml mvn car:package - builds a car using this plan.xml mvn car:install - installs it in .m2 repo. I have never tested it to see if redefining this will cause any conflicts. May be it won't.. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: That phase has nothing to do with car:install (or car:installConfig). If InstallMojo is not needed anymore, then I don't see any reason not to change car:installConfig to car:install. --jason On Jul 28, 2006, at 9:09 AM, anita kulshreshtha wrote: No, install phase of the car packaging is bound to install:install using plexus component.xml. installorg.apache.maven.plugins:maven-install-plugin:install/ install Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Can I rename car:installConfig to car:install then? --jason On Jul 26, 2006, at 5:06 AM, anita kulshreshtha wrote: --- Jason Dillon [EMAIL PROTECTED] wrote: FYI, newer car plugin side is up: http://geronimo.apache.org/maven/plugins/car-maven-plugin Though due to non-xhtml javadocs in PackageMojo the config page for that mojo is broken. I've fixed it but need to wait again for the site to sync. --jason Great work!! Thanks! The installMojo is not used anywhere. It can be removed. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Assigned: (GERONIMO-2218) KeyStore portlet: Functionality missing from 1.0
[ http://issues.apache.org/jira/browse/GERONIMO-2218?page=all ] Joe Bohn reassigned GERONIMO-2218: -- Assignee: Joe Bohn KeyStore portlet: Functionality missing from 1.0 - Key: GERONIMO-2218 URL: http://issues.apache.org/jira/browse/GERONIMO-2218 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Win XP, Sun JDK1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-2218-with-unlockkey.patch, GERONIMO-2218.patch Functionality missing from AG1.0 includes 1. Ability to view Trusted Certificate and Private Key Entry details 2. Ability to generate CertificateRequests 3. Ability to import CA reply The 2nd and 3rd functions from above are most important and without these the portlet is of very less (or no) use in any practical scenario. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2235) Locking default keystore results in serialization error on tomcat termination
[ http://issues.apache.org/jira/browse/GERONIMO-2235?page=all ] Joe Bohn reassigned GERONIMO-2235: -- Assignee: Joe Bohn Locking default keystore results in serialization error on tomcat termination - Key: GERONIMO-2235 URL: http://issues.apache.org/jira/browse/GERONIMO-2235 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1 Environment: windows xp tomcat Reporter: Joe Bohn Assigned To: Joe Bohn Fix For: 1.2, 1.1.1 Once having locked the keystore availability a subsequent termination of the server will result in a serialization exception on tomcat. This situation cannot be resolved, even with a server restart. Attempting to unlock the keystore and key again will appear to succeed ont he console but the serialization error continues to appear on server termination and the keystore is never really unlock (after restart you can observe that it is once again locked). Here's the stack trace: Server shutdown begun 14:15:18,819 WARN [[/console-standard]] Cannot serialize session attribute javax.portlet.p.Security_keystores_row1_col1_p1?org.apache.geronimo.keystore.geronim o-default for session 0BCA0CD146C855673E893CA127A31961 java.io.NotSerializableException: org.apache.geronimo.management.geronimo.KeystoreInstance$$EnhancerByCGLIB$$911c98e6 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1460) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:936) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:516) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4316) at org.apache.geronimo.tomcat.GeronimoStandardContext.stop(GeronimoStandardContext.java:216) at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:324) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$12e838fd.removeContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStop(TomcatWebAppContext.java:459) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1143) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at
Receive Messages from MQ
Does ActiveMQ Support receiveing messages from MSMQ. If so are there any examples to do this? Thanks. -- View this message in context: http://www.nabble.com/Receive-Messages-from-MQ-tf2016318.html#a5542725 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Assigned: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Joe Bohn reassigned GERONIMO-1531: -- Assignee: Joe Bohn KeyStore portlet should support deletion of certificates and private keys - Key: GERONIMO-1531 URL: http://issues.apache.org/jira/browse/GERONIMO-1531 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0 Reporter: Vamsavardhana Reddy Assigned To: Joe Bohn Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1531.patch KeyStore portlet currently supports generation of keypairs, adding trusted certificates to keystore and importing certificate issued by CA. It does not address deletion of any of these from the keystore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: How to use M2 G Packaging Plugin
On Jul 28, 2006, at 9:35 AM, anita kulshreshtha wrote: mvn car:install - installs it in .m2 repo. This invokes InstallMojo (from the car plugin) and is not the same as install:install. install:install hooked up to the install phase for the car packaging. For example, if we remove InstallMojo as you suggested, then `mvn car:install` will produce an error as there would be no 'install' goal for the car plugin w/o the InstallMojo class. * * * What was InstallMojo used for initially? --jason I have never tested it to see if redefining this will cause any conflicts. May be it won't.. Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: That phase has nothing to do with car:install (or car:installConfig). If InstallMojo is not needed anymore, then I don't see any reason not to change car:installConfig to car:install. --jason On Jul 28, 2006, at 9:09 AM, anita kulshreshtha wrote: No, install phase of the car packaging is bound to install:install using plexus component.xml. installorg.apache.maven.plugins:maven-install-plugin:install/ install Thanks Anita --- Jason Dillon [EMAIL PROTECTED] wrote: Can I rename car:installConfig to car:install then? --jason On Jul 26, 2006, at 5:06 AM, anita kulshreshtha wrote: --- Jason Dillon [EMAIL PROTECTED] wrote: FYI, newer car plugin side is up: http://geronimo.apache.org/maven/plugins/car-maven-plugin Though due to non-xhtml javadocs in PackageMojo the config page for that mojo is broken. I've fixed it but need to wait again for the site to sync. --jason Great work!! Thanks! The installMojo is not used anywhere. It can be removed. Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: JIRAs adopter query/policy?
Last I checked, Jeff Turner was waiting to see how the upgraded JIRA install did memory and perf wise before installing any plugins. I requested that these plugins get installed: * Toolkit ( http://confluence.atlassian.com/display/JIRAEXT/JIRA +Toolkit ) * Charting ( http://confluence.atlassian.com/display/JIRAEXT/JIRA +Charting+Plugin ) * Labels ( http://confluence.atlassian.com/display/JIRAEXT/JIRA +Label+Plugin ) To install, these jars need to be added to WEB-INF/lib and the app needs to be restarted. I ping'd Jeff about it last week and did not hear anything... --jason On Jul 28, 2006, at 9:51 AM, Sachin Patel wrote: Good point Jason, thats probably a better way to look at it. What prevents us from installing the plugin? Perf? On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Hrm... I'm still unsure that we need this. But... dunno, now that I think about it... its just a way to allow reporters to group their issues. I wish we could get the JIRA label plugin installed, and then the issues could just be labeled. --jason On Jul 25, 2006, at 1:11 PM, Sachin Patel wrote: fyi http://www.eclipse.org/webtools/adopters/ On Jul 25, 2006, at 3:01 PM, Jason Dillon wrote: I don't understand exactly what adopter required means. Someone is required to adopt the issue? I don't get it :-( I also don't see how companies/customers should get any such entity status in jira for an open source project. Does one need to give more priority to an issue from IBM than an issue submitted by joe user? I don't think so... at least not based on that critical alone. --jason On Jul 25, 2006, at 11:26 AM, Sachin Patel wrote: As the Geronimo user base grows, it is important that we be able to distinguish between JIRAs open during a development cycle to those that are being hit in the field or requested by companies who either use Geronimo or build products and or plugins on top of it. So I suggest we provide a restricted adopter required field in JIRA. This adopter field would be exposed to JIRA users who request and identify themselves as adopters. So just like our query for available patches, we can easily query these and help ensure that these issues that companies face get the necessary attention and help resolve them faster then they would be otherwise. Thoughts? -sachin -sachin
VMware on GBuild?
I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Thanks, Aaron
[jira] Assigned: (GERONIMO-2030) Allow WebServiceBuilder determine if there are WebServices to be deployed
[ http://issues.apache.org/jira/browse/GERONIMO-2030?page=all ] Chris Cardona reassigned GERONIMO-2030: --- Assignee: Chris Cardona Allow WebServiceBuilder determine if there are WebServices to be deployed - Key: GERONIMO-2030 URL: http://issues.apache.org/jira/browse/GERONIMO-2030 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: webservices Affects Versions: 1.1 Environment: all Reporter: Conrad O'Dea Assigned To: Chris Cardona Fix For: 1.1.1 Attachments: find-web-services.patch, geronimo_ws_builder_change.patch Each J2EE module deployer (EJB, Tomcat, Jetty) must decide if the module being deployed has a WebService endpoint. Currently, this requires the deployer to check for the presence of a webservices.xml file. This makes it awkward to add support for JAXWS style web services to Geronimo. A better solution is to push the WS endpoint check into the webservice deployer. This simplifies the logic of webservice deployment and also allows for more flexible options (such as introducing a module that use JSE 5 features without polluting the existing deployers). A patch for this attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1476) Changes to default log4j.rootCategory are not dynamic
[ http://issues.apache.org/jira/browse/GERONIMO-1476?page=all ] Chris Cardona reassigned GERONIMO-1476: --- Assignee: Chris Cardona Changes to default log4j.rootCategory are not dynamic - Key: GERONIMO-1476 URL: http://issues.apache.org/jira/browse/GERONIMO-1476 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Logging Affects Versions: 1.0 Environment: AG 1.0 on WinXP w/ Sun JDK 1.4.2_08 Reporter: Donald Woods Assigned To: Chris Cardona Fix For: 1.1.1 Changes to the log4j.rootCategory value in server-log4j.properties while the server is running has no effect. If you change the default - log4j.rootCategory=INFO, CONSOLE, FILE to log4j.rootCategory=ALL, CONSOLE, FILE none of the Log4J loggers are updated to emit the additional log levels of Debug, Trace and All. Updating the following appender - log4j.appender.FILE.threshold=INFO to ALL is dynamic for already set components, so the timer thread to pickup changes to server-log4j.properties is working, but the rootCategory is never updated if changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2228) GeronimoAsMavenServlet.java generates wrong default-repository element
[ http://issues.apache.org/jira/browse/GERONIMO-2228?page=all ] Chris Cardona reassigned GERONIMO-2228: --- Assignee: Chris Cardona GeronimoAsMavenServlet.java generates wrong default-repository element -- Key: GERONIMO-2228 URL: http://issues.apache.org/jira/browse/GERONIMO-2228 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Plugins Affects Versions: 1.2, 1.1 Reporter: Kristian Koehler Assigned To: Chris Cardona Fix For: 1.1.1 Attachments: diff.patch The GeronimoAsMavenServlet generates a XML document which contains an element called 'default-repository' (see http://localhost:8080/console-standard/maven-repo/geronimo-plugins.xml). The value of this element looks like: --- 8 --- ... default-repository HTTP/1.1://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- With this issue it isn't possible to import a plugin from a Geronimo Server running somewhere. This should be: --- 8 --- ... default-repository http://localhost:8081/console-standard/maven-repo/ /default-repository --- 8 --- The attached patch resolves this issue. Kristian -- 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: VMware on GBuild?
Why not use Xen ( http://www.fedoraproject.org/wiki/Tools/Xen )? If you just plan to use VMWare workstation, then chances are you are going to be wasting a bunch of cycles. Would be better to just run multiple instances of Geronimo. I've had really bad luck with VMWare in the past so I am a bit jaded to using it. Previously we had a big box running ESX, and a few virtual machines on it. We setup our main build/ci server as one of them... and it was so slow the vm had 100% utilization, but the host was only at like 20%. --jason On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Thanks, Aaron
Re: VMware on GBuild?
On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Why not use Xen ( http://www.fedoraproject.org/wiki/Tools/Xen )? Because I understand that it's sensitive to the host OS and I don't want to fool with it. If you just plan to use VMWare workstation, then chances are you are going to be wasting a bunch of cycles. Would be better to just run multiple instances of Geronimo. No, was going to use VMware Server. It's now final and free. If I thought it was going to be possible to have multiple TCKs running simultaneously, I would, but that seems to be such a massive undertaking that I'm not willing to do it myself. Do you think it's easier than I'm speculating? I've had really bad luck with VMWare in the past so I am a bit jaded to using it. Previously we had a big box running ESX, and a few virtual machines on it. We setup our main build/ci server as one of them... and it was so slow the vm had 100% utilization, but the host was only at like 20%. I've had pretty good experience with VMware Server. Very low overhead and no limits like you're describing. It did seem that a database server suffered a little, but it was still quite usable, and I don't think the TCK does major disk access like that. Thanks, Aaron On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Thanks, Aaron
Re: VMware on GBuild?
On Jul 28, 2006, at 11:09 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Why not use Xen ( http://www.fedoraproject.org/wiki/Tools/Xen )? Because I understand that it's sensitive to the host OS and I don't want to fool with it. Mmmkay :-P Well maybe we will have to set Xen up on GBuild west and see which is better ;-) If you just plan to use VMWare workstation, then chances are you are going to be wasting a bunch of cycles. Would be better to just run multiple instances of Geronimo. No, was going to use VMware Server. It's now final and free. Doh, I did not realize they were giving it away for free. If I thought it was going to be possible to have multiple TCKs running simultaneously, I would, but that seems to be such a massive undertaking that I'm not willing to do it myself. Do you think it's easier than I'm speculating? How hard could it be? Change some port numbers... run from a different directory? I've had really bad luck with VMWare in the past so I am a bit jaded to using it. Previously we had a big box running ESX, and a few virtual machines on it. We setup our main build/ci server as one of them... and it was so slow the vm had 100% utilization, but the host was only at like 20%. I've had pretty good experience with VMware Server. Very low overhead and no limits like you're describing. It did seem that a database server suffered a little, but it was still quite usable, and I don't think the TCK does major disk access like that. Aight, fair enough. I'm interested to see how well it performs. --jason Thanks, Aaron On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Thanks, Aaron
Re: VMware on GBuild?
On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: Mmmkay :-P Well maybe we will have to set Xen up on GBuild west and see which is better ;-) That would be awesome! How hard could it be? Change some port numbers... run from a different directory? I assumed that GBuild told a slave machine please download a TCK for branch N.M and execute build target foo. So I was assuming that the standard TCK build would need to support this somehow. There are actually kind of a lot of port numbers to change, and I assume all the app clients would need the change to in order to connect to the correct server. So it sounded pretty intimidating. If we can set up several TCK installs on a box and have one GBuild slave process sit on each one, it would be more manageable in that we could create a procedure or script to mangle all the port numbers and run it by hand when setting up the TCK. Still would be annoying every time we need to set up a new TCK rev to run, but better than trying to make the core TCK distribution take a parameter indicating whether it should configure itself for alternate ports or something. Aight, fair enough. I'm interested to see how well it performs. I still need to get past the IP address issue. I can ask if we can get more from our provider, but there might be a fee or something and it may or may not work out. Thanks, Aaron Thanks, Aaron On Jul 28, 2006, at 10:21 AM, Aaron Mulder wrote: I'm interested in setting up VMware Server on my GBuild boxes, since my understanding is that the TCK is pretty single-threaded and we ought to get better utilization out of the (dual-CPU) machines if we ran the host plus one VM or just two VMs (and forget about the host) on each box. It sounds like memory might be the constraining feature -- my boxes have 1.5, 2, and 4 GB respectively and I wonder whether splitting the smaller ones in half would leave enough RAM for the TCK to run. Would 512 or 768 be enough? The other question is IPs. I only have 3 IPs. Is there any way for me to put all the boxes/VMs behind a NAT and have them share 1 IP with various port forwards, or do they really need to each have a public IP? Thanks, Aaron
Re: VMware on GBuild?
On Jul 28, 2006, at 11:27 AM, Aaron Mulder wrote: Aight, fair enough. I'm interested to see how well it performs. I still need to get past the IP address issue. I can ask if we can get more from our provider, but there might be a fee or something and it may or may not work out. I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. --jason
Re: VMware on GBuild?
On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Re: VMware on GBuild?
Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Re: VMware on GBuild?
Could it be through a proxy? Jason Dillon wrote: Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Source re-structuring
I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) P
Tomcat 5.5.17 for 1.2?
What do people think? I would like to see us on the most stable version of Tomcat for 1.2. Comments? Thanks, Jeff
Re: VMware on GBuild?
Not sure... does ActiveMQ support it? If so... then sure... if not... well, then we'd have to write a transport (er something like that). Why? --jason On Jul 28, 2006, at 12:10 PM, Matt Hogstrom wrote: Could it be through a proxy? Jason Dillon wrote: Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Re: Tomcat 5.5.17 for 1.2?
If it works... then why not. I think we should always try to keep these components up to the latest stable for new releases. --jason On Jul 28, 2006, at 12:22 PM, Jeff Genender wrote: What do people think? I would like to see us on the most stable version of Tomcat for 1.2. Comments? Thanks, Jeff
Re: Tomcat 5.5.17 for 1.2?
Let's go for it. Won't know until we bite the bullet. Cheers Prasad On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: If it works... then why not. I think we should always try to keep these components up to the latest stable for new releases. --jason On Jul 28, 2006, at 12:22 PM, Jeff Genender wrote: What do people think? I would like to see us on the most stable version of Tomcat for 1.2. Comments? Thanks, Jeff
[jira] Created: (GERONIMO-2238) Can't copy a MultiParentClassLoader
Can't copy a MultiParentClassLoader --- Key: GERONIMO-2238 URL: http://issues.apache.org/jira/browse/GERONIMO-2238 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Assigned To: Aaron Mulder Fix For: 1.1.1 MultiParentClassLoader does not expose properties like inverseClassLoading and hiddenClasses so you can't get all the properties you would need in order to make a duplicate. -- 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
wiki migration
Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Cheers! Hernan
Re: Source re-structuring
On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. +1 to this reorg The question is wether we will release everything at the same time or not. Currently, the problem is that we need to build the maven plugin in a first step, else maven will not pick it while building the whole source tree. We could avoid that if we could release the plugin, then use it to build the source tree (as done in Geronimo). But the maven plugin needs the core container before :( The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines Or break the components jar into different jars. This would allow to replace all optional dependencies by non optional dependencies and the maven plugin could be used to generate SU and bundle all the necessary dependencies. 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. Yeah, maybe. We need to rewrite the examples to be less focused on servicemix-lwcontainer. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) +1 P -- Cheers, Guillaume Nodet
Re: Source re-structuring
One note on the plugin - with the re-org the build order would succeed if you built core first - the tooling - then everything else since nothing in core requires the plugin P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. +1 to this reorg The question is wether we will release everything at the same time or not. Currently, the problem is that we need to build the maven plugin in a first step, else maven will not pick it while building the whole source tree. We could avoid that if we could release the plugin, then use it to build the source tree (as done in Geronimo). But the maven plugin needs the core container before :( The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines Or break the components jar into different jars. This would allow to replace all optional dependencies by non optional dependencies and the maven plugin could be used to generate SU and bundle all the necessary dependencies. 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. Yeah, maybe. We need to rewrite the examples to be less focused on servicemix-lwcontainer. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) +1 P -- Cheers, Guillaume Nodet
Re: Source re-structuring
Not really. There is a bug in maven which cause maven plugins with extension to not being used when build in the current build. Not sure I'm very clear, here. The problem happen when you build from a clean machine. You can not do mvn install from the root and expect everything to work. This works for simple maven plugins, but not for plugins using extensions :( You need to do mvn -N install cd tooling mvn install cd .. mvn install At least, it is my understanding on how maven currently works. On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: One note on the plugin - with the re-org the build order would succeed if you built core first - the tooling - then everything else since nothing in core requires the plugin P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. +1 to this reorg The question is wether we will release everything at the same time or not. Currently, the problem is that we need to build the maven plugin in a first step, else maven will not pick it while building the whole source tree. We could avoid that if we could release the plugin, then use it to build the source tree (as done in Geronimo). But the maven plugin needs the core container before :( The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines Or break the components jar into different jars. This would allow to replace all optional dependencies by non optional dependencies and the maven plugin could be used to generate SU and bundle all the necessary dependencies. 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. Yeah, maybe. We need to rewrite the examples to be less focused on servicemix-lwcontainer. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) +1 P -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Source re-structuring
So maybe breaking it up into two builds - core/tooling and everything else? Is there a JIRA for the Maven bug? P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Not really. There is a bug in maven which cause maven plugins with extension to not being used when build in the current build. Not sure I'm very clear, here. The problem happen when you build from a clean machine. You can not do mvn install from the root and expect everything to work. This works for simple maven plugins, but not for plugins using extensions :( You need to do mvn -N install cd tooling mvn install cd .. mvn install At least, it is my understanding on how maven currently works. On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: One note on the plugin - with the re-org the build order would succeed if you built core first - the tooling - then everything else since nothing in core requires the plugin P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. +1 to this reorg The question is wether we will release everything at the same time or not. Currently, the problem is that we need to build the maven plugin in a first step, else maven will not pick it while building the whole source tree. We could avoid that if we could release the plugin, then use it to build the source tree (as done in Geronimo). But the maven plugin needs the core container before :( The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines Or break the components jar into different jars. This would allow to replace all optional dependencies by non optional dependencies and the maven plugin could be used to generate SU and bundle all the necessary dependencies. 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. Yeah, maybe. We need to rewrite the examples to be less focused on servicemix-lwcontainer. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) +1 P -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: Source re-structuring
http://jira.codehaus.org/browse/MNG-1911 On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: So maybe breaking it up into two builds - core/tooling and everything else? Is there a JIRA for the Maven bug? P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Not really. There is a bug in maven which cause maven plugins with extension to not being used when build in the current build. Not sure I'm very clear, here. The problem happen when you build from a clean machine. You can not do mvn install from the root and expect everything to work. This works for simple maven plugins, but not for plugins using extensions :( You need to do mvn -N install cd tooling mvn install cd .. mvn install At least, it is my understanding on how maven currently works. On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: One note on the plugin - with the re-org the build order would succeed if you built core first - the tooling - then everything else since nothing in core requires the plugin P On 7/28/06, Guillaume Nodet [EMAIL PROTECTED] wrote: On 7/28/06, Philip Dodds [EMAIL PROTECTED] wrote: I put together a basic plan (with some help from Guillaume), here http://goopen.org/confluence/display/SM/Source+Structure The purpose of the new structure it two allow cleaner separation between: 1/ The JBI Container 2/ Deployables such as shared libraries/BC's/SE's 3/ Platform specific packaging projects 4/ Archetypes 5/ Tooling 6/ Sampels By categorizing the source it should become easier to read and therefore identifying what SE/BC's/SL's are available should become more obvious, as well as cleanly showing what is required for core Container functionality. There are a couple of ommissions - first rather than one assembly (currently apache-servicemix project) I would like to add a root directories called assemblies and then create a few packaging (as previously mentioned) ie. assemblies \ core-only \ core-and-components etc. +1 to this reorg The question is wether we will release everything at the same time or not. Currently, the problem is that we need to build the maven plugin in a first step, else maven will not pick it while building the whole source tree. We could avoid that if we could release the plugin, then use it to build the source tree (as done in Geronimo). But the maven plugin needs the core container before :( The other is the servicemix-components package, there are two ways to go here: 1/ Break up the components into different service engines Or break the components jar into different jars. This would allow to replace all optional dependencies by non optional dependencies and the maven plugin could be used to generate SU and bundle all the necessary dependencies. 2/ Turn the servicemix-components jar into an SE, add a dependencies on the servicemix-lwcontainer and then change all the libs to optional false I'm not keen on the first way because I think the conversion to real SE's will take some time and should be given space to make sure we are able to address things like WSDL for services etc. In the second option we end up with a large SE though I believe it will provide all the functionality, I was thinknig that this would be a special packaging - ie. your can download just that big SE separate from the other assemblies. Yeah, maybe. We need to rewrite the examples to be less focused on servicemix-lwcontainer. I would like to try and get a discussion going on this since once this is out of the way we could then look to the work invovled in converting some of the lw-container service engines into more complete JBI Service Engines (using the service-engine architype as a basis) and also work on puting more WSDL in place for those services :) +1 P -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet -- Cheers, Guillaume Nodet
Re: TCK Dog
Kevan, Sorry for being so late with this response, but I was thinking that I should probably get involved some with the TCK (to help address your desire for broader participation across the project and get some much deserved personal relief). I just faxed my NDA for confidential materials. I'll let you know when I get my authorization. Thanks, Joe Kevan Miller wrote: On Jul 10, 2006, at 1:55 PM, David Blevins wrote: Kevan, you've been tck dog for six months now. Having built the system and done the job myself, I know you're not going to survive another six months. We definitely need to get someone else to take that job for a while. What do you think? I certainly agree with that... I would also hope that we can work on distributing the burden, a bit. So, it's not one dog, but several... Although I certainly had a lot of help from you, David J, and Dain, It'd be great to see a broader base of participation... I see the following pieces: 1) Keeping builds running through Continuum 2) Keeping tests running through GBuild 3) Monitoring/advertising test results. 4) Fixing problems It's #4 that can be the killer and where we should be working as a team... but the others can eat up time, also. I have #1 going for 1.1.1-SNAPSHOT and 1.2-SNAPSHOT. Hope to get #2 going later today... Now, would be a great time for getting more people involved... --kevan
[jira] Commented: (GERONIMO-2239) java.lang.UnsupportedOperationException in org.openejb.deployment.OpenEJBReferenceBuilder
[
http://issues.apache.org/jira/browse/GERONIMO-2239?page=comments#action_12424168
]
Ted Kirby commented on GERONIMO-2239:
-
Now that I look at the code, this is probably easily fixed by checking for
Collections.EMPTY_MAP, and if so, set nameQuery to a new HashMap()
java.lang.UnsupportedOperationException in
org.openejb.deployment.OpenEJBReferenceBuilder
-
Key: GERONIMO-2239
URL: http://issues.apache.org/jira/browse/GERONIMO-2239
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment, OpenEJB
Affects Versions: 1.1.1
Reporter: Ted Kirby
Priority: Critical
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:243)
at java.util.AbstractMap.putAll(AbstractMap.java:332)
at
org.openejb.deployment.OpenEJBReferenceBuilder.getMatchesFromName(OpenEJBReferenceBuilder.java:283)
at
org.openejb.deployment.OpenEJBReferenceBuilder.getImplicitMatch(OpenEJBReferenceBuilder.java:298)
at
org.openejb.deployment.OpenEJBReferenceBuilder.createEJBRemoteRef(OpenEJBReferenceBuilder.java:219)
at
org.openejb.deployment.OpenEJBReferenceBuilder$$FastClassByCGLIB$$bfd62c9f.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.j2ee.deployment.EJBReferenceBuilder$$EnhancerByCGLIB$$c7839d34.createEJBRemoteRef(generated)
at
org.apache.geronimo.j2ee.deployment.RefContext.getEJBRemoteRef(RefContext.java:69)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRef(ENCConfigBuilder.java:412)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRefs(ENCConfigBuilder.java:339)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:731)
at
org.apache.geronimo.client.builder.AppClientModuleBuilder.buildComponentContext(AppClientModuleBuilder.java:672)
at
org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:530)
... 56 more
in OpenEJBReferenceBuilder, getImplicitMatch say:
Collection matches = getMatchesFromName(isSession,
Collections.EMPTY_MAP, context, context.getId(), isRemote, home, remote);
However,
getMatchesFromName(boolean isSession, Map nameQuery, Configuration context,
Artifact id, boolean isRemote, String home, String remote) {
nameQuery.putAll(ENTITY);
}
Collections.EMPTY_MAP is immutable!
This code was inserted as part of fix 2823 in openejb., a fix for JIRAs
2120 and 2142.
--
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: Tomcat 5.5.17 for 1.2?
I think we should move to it. I expect that 1.2 won't get out until November based on our current course and speed. Greg / Jan, what version of Jetty should we be looking at. Jeff Genender wrote: What do people think? I would like to see us on the most stable version of Tomcat for 1.2. Comments? Thanks, Jeff
potenial problem with GBean attribute processing
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However, when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line 130.
Thanks,
Joe
Re: potenial problem with GBean attribute processing
It sounds like a problem with the attribute manager and related code
to me -- it's responsible for writing config.xml and it should ensure
that there are no duplicate entries. Can you create a Jira for 1.1.1
for this? We better fix it.
Thanks,
Aaron
On 7/28/06, Joe Bohn [EMAIL PROTECTED] wrote:
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However, when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line 130.
Thanks,
Joe
[jira] Created: (GERONIMO-2240) Memory leak in DWR memory viewer info screen in console
Memory leak in DWR memory viewer info screen in console --- Key: GERONIMO-2240 URL: http://issues.apache.org/jira/browse/GERONIMO-2240 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1.1 Environment: Windows Reporter: Jeff Genender Priority: Critical Fix For: 1.1.1 After leaving the console up on the serverinfo screen which contains the DWR AJAX component for 25 minutes, Geronimo fails with an OutOfMemory Error: 16:01:01,790 WARN [ExecuteQuery] Method execution failed: net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.createClass(Enhancer.java:317) at org.apache.geronimo.kernel.basic.BasicProxyManager$ManagedProxyFactory.init(BasicProxyManager.java:206) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxyFactory(BasicProxyManager.java:81) at org.apache.geronimo.kernel.basic.BasicProxyManager.createProxy(BasicProxyManager.java:106) at org.apache.geronimo.console.util.KernelManagementHelper.getDomains(KernelManagementHelper.java:96) at org.apache.geronimo.console.jsr77.Jsr77Lookup.getJavaVMStatistics(Jsr77Lookup.java:39) at sun.reflect.GeneratedMethodAccessor446.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at uk.ltd.getahead.dwr.impl.ExecuteQuery.execute(ExecuteQuery.java:239) at uk.ltd.getahead.dwr.impl.DefaultExecProcessor.handle(DefaultExecProcessor.java:48) at uk.ltd.getahead.dwr.impl.DefaultProcessor.handle(DefaultProcessor.java:81) at uk.ltd.getahead.dwr.AbstractDWRServlet.doPost(AbstractDWRServlet.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.geronimo.console.servlet.ForwardDispatchFilter.doFilter(ForwardDispatchFilter.java:59) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672) at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301) at org.apache.geronimo.console.servlet.ContextForwardServlet.doPost(ContextForwardServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java
[jira] Resolved: (GERONIMO-2235) Locking default keystore results in serialization error on tomcat termination
[ http://issues.apache.org/jira/browse/GERONIMO-2235?page=all ] Joe Bohn resolved GERONIMO-2235. Resolution: Fixed fixed in geronimo 1.1: Sending applications\console-standard\src\java\org\apache\geronimo\console\keystores\BaseKeystoreHandler.java Transmitting file data . Committed revision 426679. and trunk: Sending applications\console\console-standard\src\java\org\apache\geronimo\console\keystores\BaseKeystoreHandler.java Transmitting file data . Committed revision 426681. Locking default keystore results in serialization error on tomcat termination - Key: GERONIMO-2235 URL: http://issues.apache.org/jira/browse/GERONIMO-2235 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.2, 1.1, 1.1.1 Environment: windows xp tomcat Reporter: Joe Bohn Assigned To: Joe Bohn Fix For: 1.1.1, 1.2 Once having locked the keystore availability a subsequent termination of the server will result in a serialization exception on tomcat. This situation cannot be resolved, even with a server restart. Attempting to unlock the keystore and key again will appear to succeed ont he console but the serialization error continues to appear on server termination and the keystore is never really unlock (after restart you can observe that it is once again locked). Here's the stack trace: Server shutdown begun 14:15:18,819 WARN [[/console-standard]] Cannot serialize session attribute javax.portlet.p.Security_keystores_row1_col1_p1?org.apache.geronimo.keystore.geronim o-default for session 0BCA0CD146C855673E893CA127A31961 java.io.NotSerializableException: org.apache.geronimo.management.geronimo.KeystoreInstance$$EnhancerByCGLIB$$911c98e6 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1460) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:936) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:516) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:462) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:666) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4316) at org.apache.geronimo.tomcat.GeronimoStandardContext.stop(GeronimoStandardContext.java:216) at org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:324) at org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$12e838fd.removeContext(generated) at org.apache.geronimo.tomcat.TomcatWebAppContext.doStop(TomcatWebAppContext.java:459) at org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1143) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:337) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) at org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:548) at
[jira] Created: (GERONIMO-2241) Duplicate attributes created in config.xml for gbean
Duplicate attributes created in config.xml for gbean
Key: GERONIMO-2241
URL: http://issues.apache.org/jira/browse/GERONIMO-2241
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Affects Versions: 1.1.1
Environment: windows xp
jetty and tomcat
Reporter: Joe Bohn
Fix For: 1.1.1
Here is the text from a dev list post. For the post responses see:
http://marc.theaimsgroup.com/?l=geronimo-devm=115412195529876w=2
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which result
in two entries in the config.xml for the same attribute rather than replacing
the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore lock at
the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to the
default password (which effectively means it is unlocked). If we lock the
keystore the password is then replaced with a null value and this is reflected
in the config.xml. So far, so good. However, when we subsequently unlock the
keystore, rather than replacing the password attribute with the value again it
ends up creating a second entry for the attribute just before the null value
entry. Here is what it looks like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the net
result is that the keystore remains locked. This is not a good thing (see
other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting the
attribute or is it a problem with the attribute processing itself (particularly
around the setting and removing of a null value)? The code that sets the
attribute is in FileKeystoreInstance around line 130.
--
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: potenial problem with GBean attribute processing
I created this JIRA for the problem:
http://issues.apache.org/jira/browse/GERONIMO-2241
Joe
Aaron Mulder wrote:
It sounds like a problem with the attribute manager and related code
to me -- it's responsible for writing config.xml and it should ensure
that there are no duplicate entries. Can you create a Jira for 1.1.1
for this? We better fix it.
Thanks,
Aaron
On 7/28/06, Joe Bohn [EMAIL PROTECTED] wrote:
There is either a problem with the attribute processing on gbeans or the
keystore use of this processing, I'm not sure which.
The problem is that there are times when an attribute is being set which
result in two entries in the config.xml for the same attribute rather
than replacing the current setting. Here is the scenario.
There is an attribute on the keystore instance gbean (the default one we
provide) for the keystore lock password and key passwords. The scenario
happens with both attributes but I'm most concerned with the keystore
lock at the moment so I'll just discuss that one.
With a brand new image, the attribute for the keystore lock is set to
the default password (which effectively means it is unlocked). If we
lock the keystore the password is then replaced with a null value and
this is reflected in the config.xml. So far, so good. However, when we
subsequently unlock the keystore, rather than replacing the password
attribute with the value again it ends up creating a second entry for
the attribute just before the null value entry. Here is what it looks
like in the config.xml:
gbean
name=geronimo/j2ee-security/1.1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-security/1.1.1-SNAPSHOT/car,j2eeType=Keystore,name=geronimo-default
attribute
name=keystorePassword{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwEArVToThqcjvbXFD5C2uUmpwdAADQUVT/attribute
attribute
name=keyPasswords{Simple}rO0ABXNyABlqYXZheC5jcnlwdG8uU2VhbGVkT2JqZWN0PjY9psO3VHACAARbAA1lbmNvZGVkUGFyYW1zdAACW0JbABBlbmNyeXB0ZWRDb250ZW50cQB+AAFMAAlwYXJhbXNBbGd0ABJMamF2YS9sYW5nL1N0cmluZztMAAdzZWFsQWxncQB+AAJ4cHB1cgACW0Ks8xf4BghU4AIAAHhwIJu+zYXdGgTo+dMtBxYduheM0Te6O/om49Ln+vWNipopcHQAA0FFUw==/attribute
attribute name=keystorePassword null=true/
attribute name=keyPasswords null=true/
It appears that null wins out (probably because it is last) and the
net result is that the keystore remains locked. This is not a good
thing (see other posts on the keystore processing).
So my question is this: Is this a problem with the way we are setting
the attribute or is it a problem with the attribute processing itself
(particularly around the setting and removing of a null value)? The
code that sets the attribute is in FileKeystoreInstance around line 130.
Thanks,
Joe
Re: VMware on GBuild?
Just getting back to the multiple images behind a gateway system. I was thinking the other images could simply go through the gateway using a proxy rather than having to mees around with IP layer tricks. Jason Dillon wrote: Not sure... does ActiveMQ support it? If so... then sure... if not... well, then we'd have to write a transport (er something like that). Why? --jason On Jul 28, 2006, at 12:10 PM, Matt Hogstrom wrote: Could it be through a proxy? Jason Dillon wrote: Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
Re: VMware on GBuild?
IMO its easier to just using a NAT'ing router... instead of mucking with a proxy. Routers w/NAT are relatively cheap or if you have a Linux box w/2 NICs you can roll any sort of fancier router you want... at the cost of a bit more admin foo. --jason On Jul 28, 2006, at 5:47 PM, Matt Hogstrom wrote: Just getting back to the multiple images behind a gateway system. I was thinking the other images could simply go through the gateway using a proxy rather than having to mees around with IP layer tricks. Jason Dillon wrote: Not sure... does ActiveMQ support it? If so... then sure... if not... well, then we'd have to write a transport (er something like that). Why? --jason On Jul 28, 2006, at 12:10 PM, Matt Hogstrom wrote: Could it be through a proxy? Jason Dillon wrote: Agents make a TCP connection to the central AMQ router running on stan.gbuild.org... and then ActiveMQ takes care of the rest. So, its not push or pull... but the Agent must initiate the connection. --jason On Jul 28, 2006, at 11:41 AM, Aaron Mulder wrote: On 7/28/06, Jason Dillon [EMAIL PROTECTED] wrote: I'm no expert on how the TCK runs, but I do not believe that you need a public IP. Though, with out a public IP, we can't use Cacti to monitor the hosts, or ssh to them directly to admin them... but if you dedicate one host as a gateway then we can get past that... and might even be able to setup port forwarding for SNMP/Cacti monitoring. If there is any other issue that requires a public IP I am not aware of it... and we should remove the need for it if one exists. How does the GBuild master communicate with the GBuild slaves? Is it all pull from the slaves? Thanks, Aaron
[jira] Commented: (GERONIMO-2239) java.lang.UnsupportedOperationException in org.openejb.deployment.OpenEJBReferenceBuilder
[
http://issues.apache.org/jira/browse/GERONIMO-2239?page=comments#action_12424254
]
Ted Kirby commented on GERONIMO-2239:
-
getImplicitMatch() should pass new HashMap() insteand of Collections.EMPTY_MAP
on its calls to getMatchesFromName().
java.lang.UnsupportedOperationException in
org.openejb.deployment.OpenEJBReferenceBuilder
-
Key: GERONIMO-2239
URL: http://issues.apache.org/jira/browse/GERONIMO-2239
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: deployment, OpenEJB
Affects Versions: 1.1.1
Reporter: Ted Kirby
Priority: Critical
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:243)
at java.util.AbstractMap.putAll(AbstractMap.java:332)
at
org.openejb.deployment.OpenEJBReferenceBuilder.getMatchesFromName(OpenEJBReferenceBuilder.java:283)
at
org.openejb.deployment.OpenEJBReferenceBuilder.getImplicitMatch(OpenEJBReferenceBuilder.java:298)
at
org.openejb.deployment.OpenEJBReferenceBuilder.createEJBRemoteRef(OpenEJBReferenceBuilder.java:219)
at
org.openejb.deployment.OpenEJBReferenceBuilder$$FastClassByCGLIB$$bfd62c9f.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.j2ee.deployment.EJBReferenceBuilder$$EnhancerByCGLIB$$c7839d34.createEJBRemoteRef(generated)
at
org.apache.geronimo.j2ee.deployment.RefContext.getEJBRemoteRef(RefContext.java:69)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRef(ENCConfigBuilder.java:412)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBRefs(ENCConfigBuilder.java:339)
at
org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:731)
at
org.apache.geronimo.client.builder.AppClientModuleBuilder.buildComponentContext(AppClientModuleBuilder.java:672)
at
org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:530)
... 56 more
in OpenEJBReferenceBuilder, getImplicitMatch say:
Collection matches = getMatchesFromName(isSession,
Collections.EMPTY_MAP, context, context.getId(), isRemote, home, remote);
However,
getMatchesFromName(boolean isSession, Map nameQuery, Configuration context,
Artifact id, boolean isRemote, String home, String remote) {
nameQuery.putAll(ENTITY);
}
Collections.EMPTY_MAP is immutable!
This code was inserted as part of fix 2823 in openejb., a fix for JIRAs
2120 and 2142.
--
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: wiki migration
Hernan Cunico wrote: Hi All, this is a friendly reminder that the Moin Moin wiki ( namely wiki.apache.org/geronimo ) is being migrated to the confluence based http://cwiki.apache.org/geronimo Great! Please refrain from continuing updating content to the Moin Moin wiki. The current migration status can me seen at http://cwiki.apache.org/confluence/display/GMOxMoinMoin/Home I tried looking at the status and got a page not found. I also tried http://cwiki.apache.org/confluence/display/GMOxMoinMoin and got a Not Permitted page. This is the raw content migrated so far from the Moin Moin wiki has not been edited yet, this is a temporary space while migrating. This is the first step of several, later this content will be evaluated for accuracy and then incorporated to one of the cwiki.apache.org/geronimo sub-structures. Comments, suggestions and HELP! are very much welcomed. Will information be moved to space for a particular release? E.G. the build instructions for 1.1.x will differ to 1.2? Thanks, John Cheers! Hernan
