Re: Where the heck does this come from?
So far no response from the scout peeps... :-( --jason On Jul 19, 2006, at 4:34 PM, John Sisson wrote: I noticed the scout.log entry below. I looked in geronimo-1.1 \repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
[jira] Created: (GERONIMO-2215) Add link to XBean site to Geronimo sub projects page.
Add link to XBean site to Geronimo sub projects page. - Key: GERONIMO-2215 URL: http://issues.apache.org/jira/browse/GERONIMO-2215 Project: Geronimo Issue Type: Task Security Level: public (Regular issues) Components: website Reporter: John Sisson Assigned To: Dain Sundstrom Priority: Minor A link needs to be added on the http://geronimo.apache.org/subprojects.html page to the http://geronimo.apache.org/xbean/ site -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (XBEAN-28) Update xbean poms with current site and mailing list addresses
Update xbean poms with current site and mailing list addresses -- Key: XBEAN-28 URL: http://issues.apache.org/jira/browse/XBEAN-28 Project: XBean Issue Type: Bug Affects Versions: 2.5 Reporter: John Sisson Assigned To: Dain Sundstrom Priority: Minor Fix For: 2.6 Update xbean poms with current site and mailing list addresses. They currently point to xbean.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1182) Connector portlet delete challenge
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Vamsavardhana Reddy updated GERONIMO-1182: -- Attachment: GERONIMO-1182-1.1.1.patch Though GERONIMO-1182-1.patch and GERONIMO-1182-1.1.1.patch look same, I had trouble using GERONIMO-1182-1.patch with the patch command. Verified that GERONIMO-1182-1.1.1.patch addresses the following two issues: 1. Asks for user confirmation before deleting an HTTP/HTTPS/AJP Listener 2. Provides Reset and Cancel buttons in Add/Edit Listener pages and the actions are dealt accordingly. Connector portlet delete challenge -- Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Assigned To: Matt Hogstrom Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1182-1.1.1.patch, GERONIMO-1182-1.patch, GERONIMO-1182.patch Minor improvements to Connector portlet. 1. User confirmation on clicking delete link to delete a connector. 2. Add Reset and Cancel buttons to edit pages. -- 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-1509) Maven logging output multipled
[ http://issues.apache.org/jira/browse/GERONIMO-1509?page=comments#action_12422561 ] Jason Dillon commented on GERONIMO-1509: Is this still an issue? Maven logging output multipled -- Key: GERONIMO-1509 URL: http://issues.apache.org/jira/browse/GERONIMO-1509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: 1.x When I run a new Maven build on the 1.0 branch... It starts out printing each Maven log message once... By the time it gets to the Transaction module, it's printing each one twice: 23:09:54,922 INFO [ReactorTag] + 23:09:54,922 INFO [ReactorTag] + | geronimo and geronimo-plugins Geronimo :: Transaction 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: Transaction 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: Transaction | Memory: 24M/66M 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M + 23:09:54,924 INFO [ReactorTag] + 23:09:54,924 INFO [ReactorTag] + Something right there causes it to really get out of hand (see below). I wonder if the Transaction tests are manipulating the Log4J configuration? It looks like there are 8 transaction tests and the log output goes from repeated twice to repeated 10 times (a difference of 8... kind of makes you go hmmm...). Someone should look into this. If we ID the issue in the transaction tests, maybe we can figure out what's causing it to get from 1 to 2 and so on. Anyway, here's the suspicious output from the transaction build: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Transaction java:prepare-filesystem: [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes java:compile: depend closure=false srcdir=1.4 dump=false destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend [echo] Compiling to /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes [javac] Compiling 40 source files to /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports test:test-resources: test:compile: [javac] Compiling 15 source files to /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes test:test: [junit] Running org.apache.geronimo.transaction.context.TransactionContextManagerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec [junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec [junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec [junit] Running org.apache.geronimo.transaction.manager.TransactionManagerImplTest [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test [touch] Creating
[jira] Commented: (GERONIMO-1196) Keystore portlet: Viewing trusted certificate results in an error
[ http://issues.apache.org/jira/browse/GERONIMO-1196?page=comments#action_12422563 ] Vamsavardhana Reddy commented on GERONIMO-1196: --- Verification of this issue thru Admin Console in G1.1 is prevented by GERONIMO-1984 (New Keystore portlet - Add Trust Certificate throws exception) . Will have to use a different method to verify. Keystore portlet: Viewing trusted certificate results in an error - Key: GERONIMO-1196 URL: http://issues.apache.org/jira/browse/GERONIMO-1196 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: Verification Required Attachments: GERONIMO-1196-2.patch, GERONIMO-1196.patch Viewing a trusted certificate results in an error. The following exception is logged to geronimo.log 12:04:01,806 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.certmanager.actions.ViewKeyStoreEntryDetail.render(ViewKeyStoreEntryDetail.java:69) at org.apache.geronimo.console.certmanager.CertManagerPortlet.doView(CertManagerPortlet.java:134) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) ... Caused by: java.lang.NullPointerException at sun.security.provider.JavaKeyStore$JKS.convertAlias(JavaKeyStore.java:40) at sun.security.provider.JavaKeyStore.engineIsCertificateEntry(JavaKeyStore.java:409) at java.security.KeyStore.isCertificateEntry(KeyStore.java:567) at org.apache.geronimo.console.core.keystore.KeyStoreGBean.getKeyEntryInfo(KeyStoreGBean.java:179) ... -- 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-1730) Module migration to Maven 2: interop
[ http://issues.apache.org/jira/browse/GERONIMO-1730?page=comments#action_12422568 ] Jason Dillon commented on GERONIMO-1730: Why is this still open? Where is the interop module?! I don't see it anywhere. Module migration to Maven 2: interop Key: GERONIMO-1730 URL: http://issues.apache.org/jira/browse/GERONIMO-1730 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jacek Laskowski It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1736) Module migration to Maven 2: web-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1736?page=comments#action_12422569 ] Jason Dillon commented on GERONIMO-1736: Why is this still opened? Module migration to Maven 2: web-builder Key: GERONIMO-1736 URL: http://issues.apache.org/jira/browse/GERONIMO-1736 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: web Affects Versions: 1.x Reporter: Jacek Laskowski It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1714) Module migration to Maven2: connector-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1714?page=comments#action_12422567 ] Jason Dillon commented on GERONIMO-1714: Why is this still open? Module migration to Maven2: connector-builder - Key: GERONIMO-1714 URL: http://issues.apache.org/jira/browse/GERONIMO-1714 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Reporter: Anita Kulshreshtha Assigned To: Prasad Kashyap Attachments: connector-builder-apply-me.patch, connector-builder.patch, test-setup.zip -- 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-1739) Plugin migration to Maven 2: geronimo-izpack-plugin
[ http://issues.apache.org/jira/browse/GERONIMO-1739?page=comments#action_12422570 ] Jason Dillon commented on GERONIMO-1739: I am not sure that any work is going to be done on this for now. I recommend closing this issue with will not fix for m2 for now. Plugin migration to Maven 2: geronimo-izpack-plugin --- Key: GERONIMO-1739 URL: http://issues.apache.org/jira/browse/GERONIMO-1739 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.x Reporter: Jacek Laskowski It's a task to keep track of the progress of the plugin build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1748) Site migration to Maven 2
[ http://issues.apache.org/jira/browse/GERONIMO-1748?page=comments#action_12422572 ] Jason Dillon commented on GERONIMO-1748: Why does the site build need m2? This is not directly related to the m2 conversation for the project. I recommend closing this issue w/will not fix. If we want to change the site to build w/m2 that is unrelated to the main build with m2 so open a new issue (not a sub task). Site migration to Maven 2 - Key: GERONIMO-1748 URL: http://issues.apache.org/jira/browse/GERONIMO-1748 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: website Affects Versions: 1.2 Reporter: John Sisson Priority: Minor Fix For: 1.2 Currently the Geronimo site is build using Ant. The Ant build has been recently updated to use Velocity to 1.5-dev (I built from svn rev 386004) to fix issue where generated html files have inconsistent line endings when building the site on Windows ( see http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg11613.html ) See http://svn.apache.org/viewcvs?rev=386059view=rev A conversion to Maven 2 needs to use a version of velocity that has this fix. You can test whether the version of velocity has the fix by: * running touch * in cygwin in the geronimo\site\xdocs directory * build the site * attempt to check in the generated site files under geronimo\site\docs - if you don't get any errors about inconsistent line endings then you are using the fixed version of velocity. For a list of dependencies required by velocity see the doco at http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/xdocs/jar-dependencies.xml . FYI, the current Ant build loads the jars in the geronimo\site\lib dir onto the classpath. I don't know if velocity's project.xml file is up to date as they aren't doing builds with maven yet AFAIK.. http://svn.apache.org/repos/asf/jakarta/velocity/engine/trunk/project.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1196) Keystore portlet: Viewing trusted certificate results in an error
[ http://issues.apache.org/jira/browse/GERONIMO-1196?page=comments#action_12422573 ] Vamsavardhana Reddy commented on GERONIMO-1196: --- OOPS!! Admin Console in G1.1 does not provide a link to view trusted certificate (and private-key certifcate) details!!! I added a trusted certificate with alias to the keystore using keytool. Noticed the above when I went in to verify this issue thru Admin Console. Keystore portlet: Viewing trusted certificate results in an error - Key: GERONIMO-1196 URL: http://issues.apache.org/jira/browse/GERONIMO-1196 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Critical Fix For: Verification Required Attachments: GERONIMO-1196-2.patch, GERONIMO-1196.patch Viewing a trusted certificate results in an error. The following exception is logged to geronimo.log 12:04:01,806 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error while dispatching portlet. javax.portlet.PortletException at org.apache.geronimo.console.certmanager.actions.ViewKeyStoreEntryDetail.render(ViewKeyStoreEntryDetail.java:69) at org.apache.geronimo.console.certmanager.CertManagerPortlet.doView(CertManagerPortlet.java:134) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) ... Caused by: java.lang.NullPointerException at sun.security.provider.JavaKeyStore$JKS.convertAlias(JavaKeyStore.java:40) at sun.security.provider.JavaKeyStore.engineIsCertificateEntry(JavaKeyStore.java:409) at java.security.KeyStore.isCertificateEntry(KeyStore.java:567) at org.apache.geronimo.console.core.keystore.KeyStoreGBean.getKeyEntryInfo(KeyStoreGBean.java:179) ... -- 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
Update: EJB Server Portlet
A few months ago I submitted a patch to add EJB Server portlet in the Console - http://issues.apache.org/jira/browse/GERONIMO-1701. The patch worked on G 1.0 source and I was hoping I can get some feedback on my design and implementation so I can make it better. Anyway, Im working on updating the patch to work on G 1.1.0 / 1.1.1 / 1.2 sources and I have a couple of questions: 1. In my implementation, I modified org.openejb.EJBModuleImpl to implement org.apache.geronimo.management.StatisticsProvider interface. This is part of JSR 77s performance data framework. This allows the EJBModuleImpl to provide basic statistics like the count of different EJB types (EB, SLSB, SFSB, MDB). Is EJBModuleImpl the best place to implement the said interface? If not then where is the best place to implement it? 2. While updating the patch to work on G 1.1.0 / 1.1.1 / 1.2, I encountered a problem. I made the necessary changes including modifying EJBModuleImpl to implement StatisticsProvider interface. This defines a method public Stats getStats(). I was able to rebuild G including the openejb core module successfully but deploying a simple stateless session bean throws the ff: java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1655) at java.lang.Class.privateGetPublicMethods(Class.java:1778) at java.lang.Class.privateGetPublicMethods(Class.java:1788) at java.lang.Class.getMethods(Class.java:832) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:279) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:273) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:267) at org.apache.geronimo.gbean.GBeanInfoBuilder.init(GBeanInfoBuilder.java:207) at org.apache.geronimo.gbean.GBeanInfoBuilder.createStatic(GBeanInfoBuilder.java:92) at org.apache.geronimo.gbean.GBeanInfoBuilder.createStatic(GBeanInfoBuilder.java:45) at org.openejb.EJBModuleImpl.clinit(EJBModuleImpl.java:255) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:399) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.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.ModuleBuilder$$EnhancerByCGLIB$$1fd0a0c0.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:562) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java: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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$ $2bbda932.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.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.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at
Re: ActiveCluster Docs
On 7/20/06, Brian McCallister [EMAIL PROTECTED] wrote: Hmm, are there any up to date docs on ActiveCluster? The docs are still here... http://activecluster.codehaus.org/ I haven't looked at it since, er, 1.0? Is it still used anywhere? Its not used that much right now. I think its only WADI. At some point I'd like to try out refactoring the ActiveCluster API to remove all the messaging stuff and make it a pure POJO library of Nodes, Groups and NodeListeners - then add the remoting on top using Spring Remoting (such as Lingo for JMS) to make it a really simple library to work with in many projects. -- James --- http://radio.weblogs.com/0112098/
anyone any idea why RegionBroker.removeConnection() works as it does?
in http://rafb.net/paste/results/h7qOVA70.html there's
// we may be removing the duplicate connection, not the
first connection to be created
if (oldValue == info) {
I'm just wondering about the == operator here. I guess the issue is
that a duplicate tries to add a connection, gets a failure then tries
to remove itself and we want to guard against the original connection
being removed right?
Am wondering if it might be better to check for equal connectionId's
instead as I could see cases where oldValue != info but they are the
same connection?
This line of code could mybe be the cause of some duplicate clientID
exceptions some folks have experienced from time to time.
--
James
---
http://radio.weblogs.com/0112098/
Re: Build errors - kaha
I think it should be fixed now - at least svn up and building worked for me this morning. I wonder if this was just an omitted interface when some work was committed? On 7/20/06, bmadigan [EMAIL PROTECTED] wrote: clean install after updating this morning: /home/bmadigan/workspaces/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/kaha/impl/VMIndexLinkedList.java:[21,52] interface expected here /home/bmadigan/workspaces/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/kaha/impl/DiskIndexLinkedList.java:[22,37] interface expected here /home/bmadigan/workspaces/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/kaha/impl/VMIndexLinkedList.java:[221,30] incompatible types found : org.apache.activemq.kaha.impl.VMIndexLinkedList required: org.apache.activemq.kaha.impl.IndexLinkedList /home/bmadigan/workspaces/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/kaha/impl/BaseContainerImpl.java:[59,34] incompatible types found : org.apache.activemq.kaha.impl.DiskIndexLinkedList required: org.apache.activemq.kaha.impl.IndexLinkedList /home/bmadigan/workspaces/activemq/trunk/activemq-core/src/main/java/org/apache/activemq/kaha/impl/MapContainerImpl.java:[260,25] cannot find symbol symbol : method getEntry(org.apache.activemq.kaha.impl.IndexItem) location: class org.apache.activemq.kaha.impl.IndexLinkedList -- View this message in context: http://www.nabble.com/Build-errors---kaha-tf1974624.html#a5418680 Sent from the ActiveMQ - Dev forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
Re: Maven2 Conversation Status
Jason Dillon wrote: On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. Timer tests are known to fail on slower or more resource constrained systems. All of the failures should be expected '20' found (something less than 20). The tests need to be redesigned to work in all environments regardless of cpu/resource availability. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. I find it very hard to believe that we are going to spend time to setup the TCK to run on sandbox/svkmerge/m2migration. How does this differ from what you are doing today with the G codebase? We will get the TCK to run, but we should do so from trunk. It will happen very soon after the merge is complete. It is not like we are going to drop this work once the merge has been done. I'd appreciate a little flexibility here, else it just wastes our time. --jason
[jira] Assigned: (AMQ-818) Code Drop for Version 0.0.2 of the activemq-cpp library
[ https://issues.apache.org/activemq/browse/AMQ-818?page=all ] Nathan Mittler reassigned AMQ-818: -- Assignee: Nathan Mittler Code Drop for Version 0.0.2 of the activemq-cpp library --- Key: AMQ-818 URL: https://issues.apache.org/activemq/browse/AMQ-818 Project: ActiveMQ Issue Type: Improvement Components: CMS Reporter: Timothy Bish Assigned To: Nathan Mittler Attachments: activemq-cpp-0-0-2-071906.zip This issues addresses the code drop for Revision 0.0.2 of the ActiveMQ CPP library. Changes are listed below. New Features: * Destinations now support the Destination Options shown here: http://www.activemq.org/site/destination-options.html Additional Changes * Extensive code cleanup, including expanded Java DOC comments and more consistant formatting. * Memory leak checking with Rational Purify were done and several small leaks were fixed. * Added additional Unit tests for new functionality, and additional tests for existing feature correctness * Minor bug fixes Known Issues * Unchanged from version 0.0.1 -- 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
Issues Closed: week of 07-21-2006
Project: Apache Geronimo Status: Resolved, Closed (25 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-1865] Add ability to restart and reload configurations * [GERONIMO-2148] Add javamail 1.4 to geronimo specs. * [GERONIMO-2086] Create a 1.4 version of javamail. ** Bug * [GERONIMO-2214] Use m2 filtering to fill in values for geronimo-version.propertes (and friends) * [GERONIMO-2213] Bug in ServerConstants cause NPE when geronimo-version.properties is missing * [GERONIMO-1492] Many org/apache/geronimo configIds still live in source tree * [GERONIMO-1582] NPE for EJB webservices.xml with bad jaxrpc-mapping-file * [GERONIMO-1967] /remote-deploy url link throws Error 404. * [GERONIMO-2175] etc/explicit_versions.properties should be automatically generated (or made unecessary) * [GERONIMO-2200] SMTP debug output echos portions of the output twice. * [GERONIMO-2117] Remove deployer-log4j.properties files - they are no longer used * [GERONIMO-1145] Too many ORBs (or possibly not enough) * [GERONIMO-2197] NPE when the edit link is selected on the Security Realms console page * [GERONIMO-2195] SharedLib GBean fails to start if shared/lib and shared/classes dirs are missing ** Improvement * [GERONIMO-1524] DB pool portlet should let you select multiple driver JARs * [GERONIMO-2109] Link to Console on Welcome application should be more prominent * [GERONIMO-2135] Improve the ActiveMQ GBeans * [GERONIMO-2147] Remove javamail-transport from Geronimo build and replace with javamail-provider dependency. * [GERONIMO-2152] Update for new OpenEJB 2.2 * [GERONIMO-2159] Corba Spec pom has inconsistent groupId
[jira] Closed: (GERONIMO-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Vamsavardhana Reddy closed GERONIMO-1703. - ServerInfo.getBaseDirectory() returns null -- Key: GERONIMO-1703 URL: http://issues.apache.org/jira/browse/GERONIMO-1703 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: startup/shutdown Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat Reporter: Vamsavardhana Reddy Assigned To: Paul McMahan Priority: Critical Fix For: 1.1.1 Attachments: ServerInfoWebApp.war, ServerInfoWebApp_g1.1.war Calling getBaseDirectory on org.apache.geronimo.system.serverinfo.ServerInfo returned by KernelManagementHelper.getServerInfo() returns null instead of Geronimo Base Directory. -- 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: Update: EJB Server Portlet
On 7/21/06, Chris Cardona [EMAIL PROTECTED] wrote: A few months ago I submitted a patch to add EJB Server portlet in the Console - http://issues.apache.org/jira/browse/GERONIMO-1701. The patch worked on G 1.0 source and I was hoping I can get some feedback on my design and implementation so I can make it better. Anyway, I'm working on updating the patch to work on G 1.1.0 / 1.1.1 / 1.2 sources and I have a couple of questions: Sounds good! 1. In my implementation, I modified org.openejb.EJBModuleImpl to implement org.apache.geronimo.management.StatisticsProvider interface. This is part of JSR 77's performance data framework. This allows the EJBModuleImpl to provide basic statistics like the count of different EJB types (EB, SLSB, SFSB, MDB). Is EJBModuleImpl the best place to implement the said interface? If not then where is the best place to implement it? I expect we may want similar statistics at the EJB Container level (meaning for all EJBs deployed in the server), but it makes sense to have them at the module level too. I will say that if we have stats at the module level, I would expect to access them via the list of deployed EJB modules elsewhere in the console, not necessarily through an EJB Server page, but I'm not sure exactly how you've got things laid out. 2. While updating the patch to work on G 1.1.0 / 1.1.1 / 1.2, I encountered a problem. I made the necessary changes including modifying EJBModuleImpl to implement StatisticsProvider interface. This defines a method – public Stats getStats(). I was able to rebuild G including the openejb core module successfully but deploying a simple stateless session bean throws the ff: Can you find out what ClassLoader is being used at the time? It should be a Geronimo ClassLoader from which you can get a module ID and a list of JARs in both it and its parent modules. Thanks, Aaron java.lang.NoClassDefFoundError: javax/management/j2ee/statistics/Stats at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:1655) at java.lang.Class.privateGetPublicMethods(Class.java:1778) at java.lang.Class.privateGetPublicMethods(Class.java:1788) at java.lang.Class.getMethods(Class.java:832) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:279) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:273) at org.apache.geronimo.gbean.GBeanInfoBuilder.addInterface(GBeanInfoBuilder.java:267) at org.apache.geronimo.gbean.GBeanInfoBuilder.init(GBeanInfoBuilder.java:207) at org.apache.geronimo.gbean.GBeanInfoBuilder.createStatic(GBeanInfoBuilder.java:92) at org.apache.geronimo.gbean.GBeanInfoBuilder.createStatic(GBeanInfoBuilder.java:45) at org.openejb.EJBModuleImpl.clinit(EJBModuleImpl.java:255) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:399) at org.openejb.deployment.OpenEJBModuleBuilder$$FastClassByCGLIB$$11bd7b20.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.ModuleBuilder$$EnhancerByCGLIB$$1fd0a0c0.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:562) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java: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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$ $2bbda932.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:302) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) at
Deficiencies in the new KeyStore portlet
I see that there are too many deficiencies in the new KeyStore portlet in AG1.1. 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. Will these be addressed soon? Is anyone working on this?
Re: Deficiencies in the new KeyStore portlet
On 7/21/06, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: I see that there are too many deficiencies in the new KeyStore portlet in AG1.1. 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. Will these be addressed soon? Is anyone working on this? Patches welcome... Thanks, Aaron
[jira] Commented: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=comments#action_12422632 ] Prasad Kashyap commented on GERONIMO-2066: -- Anita, can you please tell us if this patch is still valid ? I think we need the geronimo-dependency.xml in it but am unsure about the others. Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Environment: All Reporter: Anita Kulshreshtha Assigned To: Prasad Kashyap Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- 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-2186) Editing of Connection Pools other than Derby from console not working
[ http://issues.apache.org/jira/browse/GERONIMO-2186?page=all ] Sachin Patel reassigned GERONIMO-2186: -- Assignee: Sachin Patel (was: Paul McMahan) Editing of Connection Pools other than Derby from console not working - Key: GERONIMO-2186 URL: http://issues.apache.org/jira/browse/GERONIMO-2186 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 1.1 Reporter: Krishnakumar B Assigned To: Sachin Patel Fix For: 1.1.1 Attachments: GERONIMO-2186.patch Editing of connection pools other than Derby is currently not working -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2186) Editing of Connection Pools other than Derby from console not working
[ http://issues.apache.org/jira/browse/GERONIMO-2186?page=all ] Sachin Patel closed GERONIMO-2186. -- Resolution: Fixed p applied. Editing of Connection Pools other than Derby from console not working - Key: GERONIMO-2186 URL: http://issues.apache.org/jira/browse/GERONIMO-2186 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: core Affects Versions: 1.1 Reporter: Krishnakumar B Assigned To: Sachin Patel Fix For: 1.1.1 Attachments: GERONIMO-2186.patch Editing of connection pools other than Derby is currently not working -- 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: Maven2 Conversation Status
On Jul 21, 2006, at 3:20 AM, Jeff Genender wrote: I find it very hard to believe that we are going to spend time to setup the TCK to run on sandbox/svkmerge/m2migration. How does this differ from what you are doing today with the G codebase? Sorry, I do not understand what you are asking. * * * My understanding is that to get the TCK bits working and automated in GBuild that we need to have a CI process that is publishing artifacts and I do not believe that we want to spend time to setup that process on this sandbox branch. I believe that we want to do this for trunk. In fact we need to do that to get the OpenEJB2 build automated, which is also required to get the G build automated. I believe that setting this up for my m2migration branch would be an intermediate step that benefits us very little and overall just slows down the progress of getting the TCK up and running for the long run using m2. If you mean to have me (or someone) run the TCK locally I'm not sure that will fly either as I certainly don't have cycles on my laptop to run the TCK for however many days it takes for the thing to run, nor do I have the expertise at this moment to know how to fix it if it breaks on something. IIUC there is significant configuration involved to get everything up and running, and significant time to actually run, therefor we could easily burn a week or more to perform the intermediate setup and then have to reburn that time to do it again. The best option to get the TCK up and running fastest and in a permanent state of continuous integration is to merge the work to the trunk and then setup GBuild to use trunk to run tests against. Its like we have just performed some major renovations on your house and need the inspector to come and make sure that everything is up to code... well, the inspector is not going to demand that the renovations be applied to a mock house build out in your backyard first before allowing them to be applied to your house proper. --jason
[jira] Assigned: (GERONIMO-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies mus
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Sachin Patel reassigned GERONIMO-1572: -- Assignee: Sachin Patel (was: Paul McMahan) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must be enabled (instead of allowing the browser to present a default 408 error page) - Key: GERONIMO-1572 URL: http://issues.apache.org/jira/browse/GERONIMO-1572 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1 Environment: All environments Reporter: Steve Whitlatch Assigned To: Sachin Patel Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1572.patch Just a suggestion: In Geronimo's administration console application, adjust its behavior so that rather than dispalying an HTTP Status 408 error message, display a custom error page or popup with a message stating that for the application to work properly cookies must be enabled (that is, if that is actually the case). I found that to be the case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Sachin Patel updated GERONIMO-1572: --- Fix Version/s: 1.1.1 Affects Version/s: 1.1 Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must be enabled (instead of allowing the browser to present a default 408 error page) - Key: GERONIMO-1572 URL: http://issues.apache.org/jira/browse/GERONIMO-1572 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1 Environment: All environments Reporter: Steve Whitlatch Assigned To: Sachin Patel Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1572.patch Just a suggestion: In Geronimo's administration console application, adjust its behavior so that rather than dispalying an HTTP Status 408 error message, display a custom error page or popup with a message stating that for the application to work properly cookies must be enabled (that is, if that is actually the case). I found that to be the case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1572) Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must
[ http://issues.apache.org/jira/browse/GERONIMO-1572?page=all ] Sachin Patel closed GERONIMO-1572. -- Resolution: Fixed p applied Adjust the admin console app so that if the user does not have cookies enabled, the application presents a custom error page or popup telling the user that cookies must be enabled (instead of allowing the browser to present a default 408 error page) - Key: GERONIMO-1572 URL: http://issues.apache.org/jira/browse/GERONIMO-1572 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: console Affects Versions: 1.0, 1.1 Environment: All environments Reporter: Steve Whitlatch Assigned To: Sachin Patel Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1572.patch Just a suggestion: In Geronimo's administration console application, adjust its behavior so that rather than dispalying an HTTP Status 408 error message, display a custom error page or popup with a message stating that for the application to work properly cookies must be enabled (that is, if that is actually the case). I found that to be the case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2216) Use JLine API to get password interactivly when using shutdown
Use JLine API to get password interactivly when using shutdown -- Key: GERONIMO-2216 URL: http://issues.apache.org/jira/browse/GERONIMO-2216 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: startup/shutdown Affects Versions: 1.2 Reporter: Jason Dillon Assigned To: Jason Dillon Priority: Minor Sometimes when interactively entering a password for shutdown, if the password is typed too fast, some of the chars are visible for a brief period. JLine provides the ability to mask the input as it is read (or omit it all together): * http://jline.sourceforge.net/#reading_password -- 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: anyone any idea why RegionBroker.removeConnection() works as it does?
Yep it looks smelly. I guess it would be best if we created a test case for
it showing the problem.
On 7/21/06, James Strachan [EMAIL PROTECTED] wrote:
in http://rafb.net/paste/results/h7qOVA70.html there's
// we may be removing the duplicate connection, not the
first connection to be created
if (oldValue == info) {
I'm just wondering about the == operator here. I guess the issue is
that a duplicate tries to add a connection, gets a failure then tries
to remove itself and we want to guard against the original connection
being removed right?
Am wondering if it might be better to check for equal connectionId's
instead as I could see cases where oldValue != info but they are the
same connection?
This line of code could mybe be the cause of some duplicate clientID
exceptions some folks have experienced from time to time.
--
James
---
http://radio.weblogs.com/0112098/
--
Regards,
Hiram
Blog: http://hiramchirino.com
JIRA policy on patches
As I've been working to get some of these patches applied to 1.1.1, I've noticed most of the patches are still months old and 90% of the time when a patch is applied thats the end of the defect thread and no comments on the patches are provided. This I'm sure is very frustrating and surely it has to be discouraging community participation. We need to have an immediate change our policy on when patches get posted by the community (non-committers specifically) that they get assigned to an individiual for review ASAP and under no circumstances should a jira that contains a patch be unassigned. All patches must be considered for inclusion in the targeted fix version and we cannot continue to let patches dangle over multiple releases. I'm not sure if there would be a way to enforce this, except take it upon ourselves to take the time to review and comment on contributions from the community.So what would be a reasonable time frame that a patch should should be reviewed, applied or commented on by? 3-4 days, a week?-sachin
[Fwd: The Asian Event for Apache Technologies! Register Now and Save!]
Dear Apache enthusiast, ApacheCon Asia is the first ever Asian offering of the popular ApacheCon Conference of the Apache Software Foundation (ASF). ApacheCon Asia provides an excellent opportunity to experience first-hand what ASF technologies and development communities can do for you and your enterprise. The program consists of two technical tracks in the main conference and a large number of tutorials. In addition a hackathon will be held the day before the conference where attendees can interact with various Apache project developers and learn and contribute! Priced at a very affordable level, the conference will be held in Colombo, Sri Lanka from August 14th to 17th at the Trans Asia Hotel. The complete agenda and registration information of ApacheCon Asia 2006 are available at http://asia.apachecon.com/ Register by Friday, August 4th and receive a 10% early bird discount! Interested in sponsoring? See: http://asia.apachecon.com/conference/sponsor/ We look forward to seeing you in Colombo! --The ApacheCon Asia Organizing Team.
Re: JIRA policy on patches
On Jul 21, 2006, at 7:03 AM, Sachin Patel wrote: As I've been working to get some of these patches applied to 1.1.1, I've noticed most of the patches are still months old and 90% of the time when a patch is applied thats the end of the defect thread and no comments on the patches are provided. This I'm sure is very frustrating and surely it has to be discouraging community participation. We need to have an immediate change our policy on when patches get posted by the community (non-committers specifically) that they get assigned to an individiual for review ASAP and under no circumstances should a jira that contains a patch be unassigned. All patches must be considered for inclusion in the targeted fix version and we cannot continue to let patches dangle over multiple releases. I'm not sure if there would be a way to enforce this, except take it upon ourselves to take the time to review and comment on contributions from the community. Short of writing some RPC app to apply some policy... or nag emails... probably has to be a human process to manage this. I'm trying to get the JIRA Toolkit plugin installed, which has a feature to change the color of older issues... which helps a bunch to see what is old and what is stale. So what would be a reasonable time frame that a patch should should be reviewed, applied or commented on by? 3-4 days, a week? Probably a week max... but I'd shoot for 1-3 days for an initial comment on the issue. --jason
[jira] Commented: (GERONIMO-1509) Maven logging output multipled
[ http://issues.apache.org/jira/browse/GERONIMO-1509?page=comments#action_12422671 ] Paul McMahan commented on GERONIMO-1509: I still see the multiplied output when I do a top down build on a fresh checkout of branches/1.1 using maven 1.1b2. Only seems to happen to me under these circumstances. Maven logging output multipled -- Key: GERONIMO-1509 URL: http://issues.apache.org/jira/browse/GERONIMO-1509 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: 1.x When I run a new Maven build on the 1.0 branch... It starts out printing each Maven log message once... By the time it gets to the Transaction module, it's printing each one twice: 23:09:54,922 INFO [ReactorTag] + 23:09:54,922 INFO [ReactorTag] + | geronimo and geronimo-plugins Geronimo :: Transaction 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: Transaction 23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo :: Transaction | Memory: 24M/66M 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M 23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M + 23:09:54,924 INFO [ReactorTag] + 23:09:54,924 INFO [ReactorTag] + Something right there causes it to really get out of hand (see below). I wonder if the Transaction tests are manipulating the Log4J configuration? It looks like there are 8 transaction tests and the log output goes from repeated twice to repeated 10 times (a difference of 8... kind of makes you go hmmm...). Someone should look into this. If we ID the issue in the transaction tests, maybe we can figure out what's causing it to get from 1 to 2 and so on. Anyway, here's the suspicious output from the transaction build: multiproject:install-callback: [echo] Running jar:install for Geronimo :: Transaction java:prepare-filesystem: [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes java:compile: depend closure=false srcdir=1.4 dump=false destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend [echo] Compiling to /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes [javac] Compiling 40 source files to /data/cvs/geronimo-1.0-branch/modules/transaction/target/classes java:jar-resources: test:prepare-filesystem: [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes [mkdir] Created dir: /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports test:test-resources: test:compile: [javac] Compiling 15 source files to /data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes test:test: [junit] Running org.apache.geronimo.transaction.context.TransactionContextManagerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec [junit] Running org.apache.geronimo.transaction.log.HOWLLogTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec [junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec [junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec [junit] Running org.apache.geronimo.transaction.manager.ProtocolTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec [junit] Running org.apache.geronimo.transaction.manager.RecoveryTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec [junit] Running org.apache.geronimo.transaction.manager.TransactionManagerImplTest [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec [junit] Running org.apache.geronimo.transaction.manager.XidImporterTest [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running post goal: test:test 23:10:25,440 INFO [PostGoalTag] Running
[jira] Updated: (GERONIMO-1509) Maven logging output multipled
[ http://issues.apache.org/jira/browse/GERONIMO-1509?page=all ]
Jason Dillon updated GERONIMO-1509:
---
Description:
When I run a new Maven build on the 1.0 branch...
It starts out printing each Maven log message once...
By the time it gets to the Transaction module, it's printing each one twice:
{noformat}
23:09:54,922 INFO [ReactorTag] +
23:09:54,922 INFO [ReactorTag] +
| geronimo and geronimo-plugins Geronimo :: Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
| Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
+
23:09:54,924 INFO [ReactorTag] +
23:09:54,924 INFO [ReactorTag] +
Something right there causes it to really get out of hand (see below). I
wonder if the Transaction tests are manipulating the Log4J configuration? It
looks like there are 8 transaction tests and the log output goes from repeated
twice to repeated 10 times (a difference of 8... kind of makes you go
hmmm...). Someone should look into this. If we ID the issue in the
transaction tests, maybe we can figure out what's causing it to get from 1 to 2
and so on. Anyway, here's the suspicious output from the transaction build:
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Transaction
java:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
[javac] Compiling 40 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:jar-resources:
test:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports
test:test-resources:
test:compile:
[javac] Compiling 15 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
test:test:
[junit] Running
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec
[junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec
[junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec
[junit] Running
org.apache.geronimo.transaction.manager.TransactionManagerImplTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec
Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
[touch] Creating
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports/tstamp
jar:jar:
[jar] Building jar:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/geronimo-transaction-1.0.1-SNAPSHOT.jar
jar:install:
[echo] Installing...
Uploading to geronimo/jars/geronimo-transaction-1.0.1-SNAPSHOT.jar:
(73K)
Uploading to geronimo/poms/geronimo-transaction-1.0.1-SNAPSHOT.pom:
(12K)
+
build:end:
23:10:26,145 INFO [ReactorTag] +
23:10:26,145
Re: JIRA policy on patches
Your suggestion is good Sachin and I agree. What I think we need is a JIRA triage person who watches the incoming JIRAs and is a PITA until someone deals with the patch. Kind of like we do the TCK. I think 3-4 days is max as after that discouragement probably starts to set in. Sachin Patel wrote: As I've been working to get some of these patches applied to 1.1.1, I've noticed most of the patches are still months old and 90% of the time when a patch is applied thats the end of the defect thread and no comments on the patches are provided. This I'm sure is very frustrating and surely it has to be discouraging community participation. We need to have an immediate change our policy on when patches get posted by the community (non-committers specifically) that they get assigned to an individiual for review ASAP and under no circumstances should a jira that contains a patch be unassigned. All patches must be considered for inclusion in the targeted fix version and we cannot continue to let patches dangle over multiple releases. I'm not sure if there would be a way to enforce this, except take it upon ourselves to take the time to review and comment on contributions from the community. So what would be a reasonable time frame that a patch should should be reviewed, applied or commented on by? 3-4 days, a week? -sachin
[jira] Commented: (GERONIMO-1509) Maven logging output multipled
[
http://issues.apache.org/jira/browse/GERONIMO-1509?page=comments#action_12422676
]
Jason Dillon commented on GERONIMO-1509:
A rebuild of branches/1.1 (ie. not fresh) produces normal output?
Maven logging output multipled
--
Key: GERONIMO-1509
URL: http://issues.apache.org/jira/browse/GERONIMO-1509
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.0
Reporter: Aaron Mulder
Priority: Minor
Fix For: 1.x
When I run a new Maven build on the 1.0 branch...
It starts out printing each Maven log message once...
By the time it gets to the Transaction module, it's printing each one twice:
{noformat}
23:09:54,922 INFO [ReactorTag] +
23:09:54,922 INFO [ReactorTag] +
| geronimo and geronimo-plugins Geronimo :: Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
| Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
+
23:09:54,924 INFO [ReactorTag] +
23:09:54,924 INFO [ReactorTag] +
Something right there causes it to really get out of hand (see below). I
wonder if the Transaction tests are manipulating the Log4J configuration? It
looks like there are 8 transaction tests and the log output goes from
repeated twice to repeated 10 times (a difference of 8... kind of makes you
go hmmm...). Someone should look into this. If we ID the issue in the
transaction tests, maybe we can figure out what's causing it to get from 1 to
2 and so on. Anyway, here's the suspicious output from the transaction build:
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Transaction
java:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
[javac] Compiling 40 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:jar-resources:
test:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports
test:test-resources:
test:compile:
[javac] Compiling 15 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
test:test:
[junit] Running
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec
[junit] Running
org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec
[junit] Running
org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec
[junit] Running
org.apache.geronimo.transaction.manager.TransactionManagerImplTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec
Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
[touch]
[jira] Updated: (GERONIMO-1509) Maven logging output multipled
[ http://issues.apache.org/jira/browse/GERONIMO-1509?page=all ]
Jason Dillon updated GERONIMO-1509:
---
Description:
When I run a new Maven build on the 1.0 branch...
It starts out printing each Maven log message once...
By the time it gets to the Transaction module, it's printing each one twice:
{noformat}
23:09:54,922 INFO [ReactorTag] +
23:09:54,922 INFO [ReactorTag] +
| geronimo and geronimo-plugins Geronimo :: Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
| Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
+
23:09:54,924 INFO [ReactorTag] +
23:09:54,924 INFO [ReactorTag] +
{noformat}
Something right there causes it to really get out of hand (see below). I
wonder if the Transaction tests are manipulating the Log4J configuration? It
looks like there are 8 transaction tests and the log output goes from repeated
twice to repeated 10 times (a difference of 8... kind of makes you go
hmmm...). Someone should look into this. If we ID the issue in the
transaction tests, maybe we can figure out what's causing it to get from 1 to 2
and so on. Anyway, here's the suspicious output from the transaction build:
{noformat}
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Transaction
java:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
[javac] Compiling 40 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:jar-resources:
test:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports
test:test-resources:
test:compile:
[javac] Compiling 15 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
test:test:
[junit] Running
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec
[junit] Running org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec
[junit] Running org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec
[junit] Running
org.apache.geronimo.transaction.manager.TransactionManagerImplTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec
Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
[touch] Creating
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports/tstamp
jar:jar:
[jar] Building jar:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/geronimo-transaction-1.0.1-SNAPSHOT.jar
jar:install:
[echo] Installing...
Uploading to geronimo/jars/geronimo-transaction-1.0.1-SNAPSHOT.jar:
(73K)
Uploading to geronimo/poms/geronimo-transaction-1.0.1-SNAPSHOT.pom:
(12K)
+
build:end:
23:10:26,145 INFO [ReactorTag]
[jira] Created: (SM-491) Links in apache-servicemix-3.0-M2-incubating/README are stale/broken.
Links in apache-servicemix-3.0-M2-incubating/README are stale/broken. - Key: SM-491 URL: https://issues.apache.org/activemq/browse/SM-491 Project: ServiceMix Issue Type: Wish Affects Versions: 3.0-M2 Environment: All (documentation) Reporter: Jeffrey Grabell Priority: Trivial These links in the README do not work: Getting Started === To find out how to get started try this http://incubator.apache.org/servicemix/Getting+Started If you need more help try talking to us on our mailing lists http://incubator.apache.org/servicemix/Mailing+Lists We welcome contributions http://incubator.apache.org/servicemix/Contributing Many thanks for using Apache ServiceMix. The ServiceMix Team http://incubator.apache.org/servicemix/Team -- 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: Maven2 Conversation Status
On Jul 21, 2006, at 8:15 AM, Matt Hogstrom wrote: Based on this note and the others it sounds like the build is working and that you are suggesting a temporary blackout period when the migration is completed. During the migration period the Maven 1 build will no longer work so we will effectively halt any development in trunk. Not exactly. The m1 build will still function, just it is not preferred... and use would be discouraged. Soon afterwards once we have the TCK up and everyone is happy (or happy enough) then the m1 build will be removed. Development on trunk using m1 _should_ halt... and be replaced by development using m2... but by no means will the migration force anyone to halt for the initial steps. Based on the commit log it doesn't really look like there is much going on now anyway so its probably not a huge issue. Looks like some folks have left trunk for branches or the sandbox which is unfortunate. There is almost nothing going on in trunk right now except for merges from 1.1 that Sachin has been doing. How long do you estimate that the work will take and what happens if its not completed before your vacation? I'm uncomfortable throwing M1 out if its going to be a three week conversion period. You may have answered this in the thread and if I missed it I apologize. I'm taking a vacation? Where am I going? Do I need my bathing suite? :-P The build with m2 works now. The conversion period would be the time it takes for me to merge m2migration back to trunk (and verify w/ bootstrap which takes ~30m or so on my laptop). Using svk that should be maybe an hour. But lets say it will take a day for a nice 8x buffer. I'm planning on merging with svk from svkmerge/m2migration to svkmerge/trunk and then from svkmerge/trunk to trunk. I've been doing the opposite to keep svkmerge/m2migration in sync with trunk periodically, which is mostly brainless and works flawlessly. --jason
Re: JIRA policy on patches
Several of the patches that Sachin applied were attached to JIRAs that I had assigned to myself. Would it help facilitate the process if I unassigned the JIRAs after I have finished working on them and attached the patch? Or should I leave the JIRA assigned to myself and look on IRC for a committer to reassign it to? Just want to be sure that I'm sending the right signals. thanks, Paul On 7/21/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Your suggestion is good Sachin and I agree. What I think we need is a JIRA triage person who watches the incoming JIRAs and is a PITA until someone deals with the patch. Kind of like we do the TCK. I think 3-4 days is max as after that discouragement probably starts to set in. Sachin Patel wrote: As I've been working to get some of these patches applied to 1.1.1, I've noticed most of the patches are still months old and 90% of the time when a patch is applied thats the end of the defect thread and no comments on the patches are provided. This I'm sure is very frustrating and surely it has to be discouraging community participation. We need to have an immediate change our policy on when patches get posted by the community (non-committers specifically) that they get assigned to an individiual for review ASAP and under no circumstances should a jira that contains a patch be unassigned. All patches must be considered for inclusion in the targeted fix version and we cannot continue to let patches dangle over multiple releases. I'm not sure if there would be a way to enforce this, except take it upon ourselves to take the time to review and comment on contributions from the community. So what would be a reasonable time frame that a patch should should be reviewed, applied or commented on by? 3-4 days, a week? -sachin
[jira] Commented: (GERONIMO-1509) Maven logging output multipled
[
http://issues.apache.org/jira/browse/GERONIMO-1509?page=comments#action_12422687
]
Paul McMahan commented on GERONIMO-1509:
A rebuild of branches/1.1 (ie. not fresh) produces normal output?
As I recall yes that is the case. Unfortunately my dev environment is
completely hosed right now so I can't verify, sorry.
Maven logging output multipled
--
Key: GERONIMO-1509
URL: http://issues.apache.org/jira/browse/GERONIMO-1509
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.0
Reporter: Aaron Mulder
Priority: Minor
Fix For: 1.x
When I run a new Maven build on the 1.0 branch...
It starts out printing each Maven log message once...
By the time it gets to the Transaction module, it's printing each one twice:
{noformat}
23:09:54,922 INFO [ReactorTag] +
23:09:54,922 INFO [ReactorTag] +
| geronimo and geronimo-plugins Geronimo :: Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
| Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
+
23:09:54,924 INFO [ReactorTag] +
23:09:54,924 INFO [ReactorTag] +
{noformat}
Something right there causes it to really get out of hand (see below). I
wonder if the Transaction tests are manipulating the Log4J configuration? It
looks like there are 8 transaction tests and the log output goes from
repeated twice to repeated 10 times (a difference of 8... kind of makes you
go hmmm...). Someone should look into this. If we ID the issue in the
transaction tests, maybe we can figure out what's causing it to get from 1 to
2 and so on. Anyway, here's the suspicious output from the transaction build:
{noformat}
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Transaction
java:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
[javac] Compiling 40 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:jar-resources:
test:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports
test:test-resources:
test:compile:
[javac] Compiling 15 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
test:test:
[junit] Running
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec
[junit] Running
org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec
[junit] Running
org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec
[junit] Running
org.apache.geronimo.transaction.manager.TransactionManagerImplTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec
Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post
1.1.1 Status - Help please
All, I am attempting to get some vacation time in this week so I haven't been too active on the list or doing work. There are still most of the JIRAs for 1.1.1 our there for consumption. The ones assigned to me are fair game and if you have some extra cycles and can help please feel free to take any of the JIRAs for me and assign them to yourself. Current course and speed I think we've closed 1 or 2 thanks to Sachin. Any and all help is appreciated to get 1.1.1 done by the end of next week. Thanks in advance. Matt
Re: JIRA policy on patches
Generally, when I am going to commit patches, then I assign the issue to myself, commit, then resolve (or close depending on if the commit needs more validation). Or, sometimes if a contributor knows I am going to work on the issue, or needs me to look at it they will assign the issue to me. Either way, the issue gets assigned to the commiter who does the final work and resolves the issue. Its not official policy, but I have found this works well and I recommend others to follow. --jason On Jul 21, 2006, at 8:48 AM, Paul McMahan wrote: Several of the patches that Sachin applied were attached to JIRAs that I had assigned to myself. Would it help facilitate the process if I unassigned the JIRAs after I have finished working on them and attached the patch? Or should I leave the JIRA assigned to myself and look on IRC for a committer to reassign it to? Just want to be sure that I'm sending the right signals. thanks, Paul On 7/21/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Your suggestion is good Sachin and I agree. What I think we need is a JIRA triage person who watches the incoming JIRAs and is a PITA until someone deals with the patch. Kind of like we do the TCK. I think 3-4 days is max as after that discouragement probably starts to set in. Sachin Patel wrote: As I've been working to get some of these patches applied to 1.1.1, I've noticed most of the patches are still months old and 90% of the time when a patch is applied thats the end of the defect thread and no comments on the patches are provided. This I'm sure is very frustrating and surely it has to be discouraging community participation. We need to have an immediate change our policy on when patches get posted by the community (non-committers specifically) that they get assigned to an individiual for review ASAP and under no circumstances should a jira that contains a patch be unassigned. All patches must be considered for inclusion in the targeted fix version and we cannot continue to let patches dangle over multiple releases. I'm not sure if there would be a way to enforce this, except take it upon ourselves to take the time to review and comment on contributions from the community. So what would be a reasonable time frame that a patch should should be reviewed, applied or commented on by? 3-4 days, a week? -sachin
[jira] Commented: (GERONIMO-1509) Maven logging output multipled
[
http://issues.apache.org/jira/browse/GERONIMO-1509?page=comments#action_12422688
]
Jason Dillon commented on GERONIMO-1509:
Np, just trying to clarify.
I don't believe that this will be fixed, unless someone stumbles into the
cause...
Maven logging output multipled
--
Key: GERONIMO-1509
URL: http://issues.apache.org/jira/browse/GERONIMO-1509
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 1.0
Reporter: Aaron Mulder
Priority: Minor
Fix For: 1.x
When I run a new Maven build on the 1.0 branch...
It starts out printing each Maven log message once...
By the time it gets to the Transaction module, it's printing each one twice:
{noformat}
23:09:54,922 INFO [ReactorTag] +
23:09:54,922 INFO [ReactorTag] +
| geronimo and geronimo-plugins Geronimo :: Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
23:09:54,922 INFO [ReactorTag] | geronimo and geronimo-plugins Geronimo ::
Transaction
| Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
23:09:54,923 INFO [ReactorTag] | Memory: 24M/66M
+
23:09:54,924 INFO [ReactorTag] +
23:09:54,924 INFO [ReactorTag] +
{noformat}
Something right there causes it to really get out of hand (see below). I
wonder if the Transaction tests are manipulating the Log4J configuration? It
looks like there are 8 transaction tests and the log output goes from
repeated twice to repeated 10 times (a difference of 8... kind of makes you
go hmmm...). Someone should look into this. If we ID the issue in the
transaction tests, maybe we can figure out what's causing it to get from 1 to
2 and so on. Anyway, here's the suspicious output from the transaction build:
{noformat}
multiproject:install-callback:
[echo] Running jar:install for Geronimo :: Transaction
java:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:compile:
depend closure=false srcdir=1.4 dump=false
destdir=/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes/depend
[echo] Compiling to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
[javac] Compiling 40 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/classes
java:jar-resources:
test:prepare-filesystem:
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
[mkdir] Created dir:
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-reports
test:test-resources:
test:compile:
[javac] Compiling 15 source files to
/data/cvs/geronimo-1.0-branch/modules/transaction/target/test-classes
test:test:
[junit] Running
org.apache.geronimo.transaction.context.TransactionContextManagerTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.121 sec
[junit] Running org.apache.geronimo.transaction.log.HOWLLogTest
[junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 8.094 sec
[junit] Running
org.apache.geronimo.transaction.manager.HOWLLogRecoveryTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.954 sec
[junit] Running
org.apache.geronimo.transaction.manager.MockLogRecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.075 sec
[junit] Running org.apache.geronimo.transaction.manager.ProtocolTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.113 sec
[junit] Running org.apache.geronimo.transaction.manager.RecoveryTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.073 sec
[junit] Running
org.apache.geronimo.transaction.manager.TransactionManagerImplTest
[junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 15.164 sec
[junit] Running org.apache.geronimo.transaction.manager.XidImporterTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 0.114 sec
Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
23:10:25,440 INFO [PostGoalTag] Running post goal: test:test
[jira] Created: (AMQ-839) Opening a connection after closing a connectoin with the same clientid sometimes fails
Opening a connection after closing a connectoin with the same clientid sometimes fails -- Key: AMQ-839 URL: https://issues.apache.org/activemq/browse/AMQ-839 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.0.1 Environment: Linux Red Hat Enterprise 4 Reporter: Christopher Mihaly If a client closes a connection, and then fairly quicly tries to open a connection with the same clientid, this sometimes fails. Apparently, the connection is not completely closed on the broker when the close on the connection completes. This allows the client to try to open a conection and receive a client already connected exception. The close connection should not return until the connection is actually closed, or at least an attribute on the collection should allow for setting if you want to wait or not. -- 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: servicemix-http and normalization
Alex, I suppose the problem is going to be that the components are configurable to the level which can affect the input/ouput, and therefore it is the final implementation that needs to generate the WSDL. A component like the Groovy Component is going to be difficult to provide WSDL for - it is the responsiblity of the implementor. I can see the WSDL 1.1 would work for stricter interfaces (such as those of the JSR181 component) but what about more flexible content? P On 7/20/06, Alex Boisvert [EMAIL PROTECTED] wrote: My suggestion would be to go towards WSDL 1.1. It's a widely accepted spec with well-defined rules of interoperability if you take into account the WS-I BasicProfile 1.1. And we have a good mapping defined in the JBI spec for passing around WSDL 1.1 normalized messages. I'm not a WS fanatic but I don't see any other approach that would better formalize the service invocation contract (esp. the normalized message format) between components. WSDL also provides the ability to map header properties into the (JBI) message content as required by the use-case Ramon described below. It's a little more work for each component to define a WSDL 1.1 mapping but in the end you get much more value out of the whole system because all components can work together out-of-the-box without worrying about transformations, ad-hoc mappings, adapters, etc. And after all, it's the big idea behind the separation of binding components and service engines. alex Philip Dodds wrote: Its certainly a good point, so far most of the components have been pretty self-centred and the specification is purposefully vague. Perhaps it is time to start looking at message sterotypes of some kind to allow people using servicemix a little better understand of the input/output message types. This might at least provide some guidance as to what fits together out of the box and what might need transformation? I wonder if we should look at extensing a wiki page or two on some ServiceMix standards? Could be as little as a list of message types and we could provide either an index of the components by type? P On 7/19/06, Ramon Buckland [EMAIL PROTECTED] wrote: Interesting topic. In our recent development work we chose BPEL as part of an implementation but BPEL cannot access JBI properties, which when we spec'd our work, were going to be used as META data for the messages. As it turned out, we came up with our own message format rootNode properties propertyNamevalue/propertyName ... /properties payload .. actual XML ..., data, command request etc /payload /rootNode and we marshal between our bespoke and JBI NormalizedMessage when we need. (ie, shift properties to and from the message content to NM properties when needed). It posed some tricky decisions. Going forward for the use we have, this custom normalisation is good, (meaning we have one WSDL for BPEL messaging etc .. ). For Eg: when -http provides the response .. regardless of it's normalisation we run it through a custom normaliser and then in BPEL would get rootNode properties ... /properties payload .. actual XML from servicemix-http .. /payload /rootNode our two cents. On Wed, 19 Jul 2006 07:50:15 -0700, Alex Boisvert wrote To tell you the truth, I was secretly hoping to spur a debate around message normalization. :) The way I understand it, if I start changing the message format put on the bus, it will most likely break other components that expect the older format. I'd be curious to hear what other think about this. Various components seem to use different normalization rules (or no normalization at all) which will inevitably lead to interoperability problems down the road. Time to set higher standards? alex Philip Dodds wrote: Alex, I don't believe anyone is, and we would more than welcome a patch :) just create a JIRA and attach it Thanks P On 7/18/06, Alex Boisvert [EMAIL PROTECTED] wrote: Hi, I've noticed that servicemix-http simply places the child element of the SOAP:Body as the content of JBI normalized message. This doesn't seem to go with the spirit of normalization... I would have expected a WSDL 1.1-wrapper element with message parts if I deployed a WSDL 1.1. document. Is anybody working on this yet? If not, I could volunteer for a patch. cheers, alex -- Open WebMail Project (http://openwebmail.org)
Re: 1.1.1 Status - Help please
Actually I've been able close out about 7 of them, there are still 15 patches currently targeted for 1.1.1 which need to be looked at. (2 of them for openejb)On Jul 21, 2006, at 11:54 AM, Matt Hogstrom wrote:All,I am attempting to get some vacation time in this week so I haven't been too active on the list or doing work. There are still most of the JIRAs for 1.1.1 our there for consumption. The ones assigned to me are fair game and if you have some extra cycles and can help please feel free to take any of the JIRAs for me and assign them to yourself.Current course and speed I think we've closed 1 or 2 thanks to Sachin.Any and all help is appreciated to get 1.1.1 done by the end of next week.Thanks in advance.Matt -sachin
[jira] Assigned: (GERONIMO-2212) Enable tests (geronimo-system :: **/PluginInstallerTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2212?page=all ]
Jason Dillon reassigned GERONIMO-2212:
--
Assignee: Jason Dillon
Enable tests (geronimo-system :: **/PluginInstallerTest.java)
-
Key: GERONIMO-2212
URL: http://issues.apache.org/jira/browse/GERONIMO-2212
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: 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).
The test fails with (on the console):
{noformat}
14:59:18,201 ERROR [PluginInstallerGBean] Unable to load repository
configuration data
java.lang.IllegalArgumentException: No attributes are implemented
at
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.setAttribute(DocumentBuilderFactoryImpl.java:93)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.createDocumentBuilder(PluginInstallerGBean.java:1246)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.loadPluginList(PluginInstallerGBean.java:1212)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.listPlugins(PluginInstallerGBean.java:359)
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}
And in the surefire report:
{noformat}
---
Test set: org.apache.geronimo.system.plugin.PluginInstallerTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.342 sec
FAILURE!
testParsing(org.apache.geronimo.system.plugin.PluginInstallerTest) Time
elapsed: 0.207 sec ERROR!
java.lang.NullPointerException
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:78)
{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
[jira] Updated: (GERONIMO-2212) Enable tests (geronimo-system :: **/PluginInstallerTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2212?page=all ]
Prasad Kashyap updated GERONIMO-2212:
-
Attachment: geronimo-system.patch
Can you please try this ?
Enable tests (geronimo-system :: **/PluginInstallerTest.java)
-
Key: GERONIMO-2212
URL: http://issues.apache.org/jira/browse/GERONIMO-2212
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: geronimo-system.patch
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
14:59:18,201 ERROR [PluginInstallerGBean] Unable to load repository
configuration data
java.lang.IllegalArgumentException: No attributes are implemented
at
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.setAttribute(DocumentBuilderFactoryImpl.java:93)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.createDocumentBuilder(PluginInstallerGBean.java:1246)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.loadPluginList(PluginInstallerGBean.java:1212)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.listPlugins(PluginInstallerGBean.java:359)
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}
And in the surefire report:
{noformat}
---
Test set: org.apache.geronimo.system.plugin.PluginInstallerTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.342 sec
FAILURE!
testParsing(org.apache.geronimo.system.plugin.PluginInstallerTest) Time
elapsed: 0.207 sec ERROR!
java.lang.NullPointerException
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:78)
{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
[jira] Resolved: (GERONIMO-2212) Enable tests (geronimo-system :: **/PluginInstallerTest.java)
[ http://issues.apache.org/jira/browse/GERONIMO-2212?page=all ]
Jason Dillon resolved GERONIMO-2212.
Resolution: Fixed
Needed to include xerces deps to get a sensible parser that supports attributes
in case the host JDK uses a lame parser by default.
Enable tests (geronimo-system :: **/PluginInstallerTest.java)
-
Key: GERONIMO-2212
URL: http://issues.apache.org/jira/browse/GERONIMO-2212
Project: Geronimo
Issue Type: Sub-task
Security Level: public(Regular issues)
Affects Versions: 1.2
Reporter: Jason Dillon
Assigned To: Jason Dillon
Fix For: 1.2
Attachments: geronimo-system.patch
A few tests failed in non-obvious ways when run under the m2 build. Need
someone who knows these tests better to inspect, resolve and enable the test
(remove the test exclusions in the pom).
The test fails with (on the console):
{noformat}
14:59:18,201 ERROR [PluginInstallerGBean] Unable to load repository
configuration data
java.lang.IllegalArgumentException: No attributes are implemented
at
org.apache.crimson.jaxp.DocumentBuilderFactoryImpl.setAttribute(DocumentBuilderFactoryImpl.java:93)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.createDocumentBuilder(PluginInstallerGBean.java:1246)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.loadPluginList(PluginInstallerGBean.java:1212)
at
org.apache.geronimo.system.plugin.PluginInstallerGBean.listPlugins(PluginInstallerGBean.java:359)
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:77)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}
And in the surefire report:
{noformat}
---
Test set: org.apache.geronimo.system.plugin.PluginInstallerTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.342 sec
FAILURE!
testParsing(org.apache.geronimo.system.plugin.PluginInstallerTest) Time
elapsed: 0.207 sec ERROR!
java.lang.NullPointerException
at
org.apache.geronimo.system.plugin.PluginInstallerTest.testParsing(PluginInstallerTest.java:78)
{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
[jira] Resolved: (GERONIMO-2066) Openejb migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2066?page=all ] Prasad Kashyap resolved GERONIMO-2066. -- Resolution: Invalid Got a confirmation from djencks that the patch is no longer relevant. http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060721. JIRA may be closed. (Moreover, the openejb patches need to be applied to openejb jira at codehaus.) Openejb migration to M2 --- Key: GERONIMO-2066 URL: http://issues.apache.org/jira/browse/GERONIMO-2066 Project: Geronimo Issue Type: Sub-task Security Level: public(Regular issues) Components: buildsystem Environment: All Reporter: Anita Kulshreshtha Assigned To: Prasad Kashyap Attachments: openejb.patch, openejb.patch, openejb.patch, openejb.patch The attached patch provides a local openejb build for Geronimo using o.a.g.modules groupId. This is to ensure that the latest openejb jars are available. The results for rev 2659 are below : Path: . URL: https://svn.codehaus.org/openejb/branches/v2_1/openejb2 Repository UUID: 2b0c1533-c60b-0410-b8bd-89f67432e5c6 Revision: 2659 Node Kind: directory Schedule: normal Last Changed Author: gdamour Last Changed Rev: 2659 Last Changed Date: 2006-05-27 08:00:16 -0400 (Sat, 27 May 2006) Properties Last Updated: 2006-05-26 19:05:28 -0400 (Fri, 26 May 2006) Todo - fix the test failures. APSHOT\openejb-builder-2.1-SNAPSHOT.jar [INFO] [INFO] [INFO] [INFO] Reactor Summary: [INFO] [INFO] OpenEJB SUCCESS [3.953s] [INFO] OpenEJB :: Core SUCCESS [30.515s] [INFO] OpenEJB :: PK Generation :: Builder SUCCESS [9.297s] [INFO] OpenEJB :: Builder . SUCCESS [27.875s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 minute 12 seconds [INFO] Finished at: Mon May 29 08:11:40 EDT 2006 [INFO] Final Memory: 17M/53M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Sachin Patel updated GERONIMO-1531: --- Assignee: (was: Matt Hogstrom) 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 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
[jira] Updated: (GERONIMO-1451) A new TCP listener for ActiveMQ is not persisting across server startups
[ http://issues.apache.org/jira/browse/GERONIMO-1451?page=all ] Sachin Patel updated GERONIMO-1451: --- Assignee: (was: Matt Hogstrom) A new TCP listener for ActiveMQ is not persisting across server startups - Key: GERONIMO-1451 URL: http://issues.apache.org/jira/browse/GERONIMO-1451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.1 Environment: Windows 2003, Sun JVM java version 1.4.2_09 Reporter: Phani Balaji Madgula Priority: Critical Fix For: 1.1.1 Attachments: ActiveMQConnectorGBean.patch, ActiveMQManagerGBean.patch When we click on Add new tcp listener on JMS Network Listeners portlet, console asks for details of listener and when submitted with proper values, it creates a TCP listener and starts it. But, when we shutdown and restart the server, the listener is not shown in JMS Network Listeners portlet. The problem is that, I guess, the GBean pertaining to the new TCP listener is not saved to config.xml. But the same functionality is working fine for tomcat HTTP listeners. This problem is similar to GERONIMO-1070. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1182) Connector portlet delete challenge
[ http://issues.apache.org/jira/browse/GERONIMO-1182?page=all ] Sachin Patel updated GERONIMO-1182: --- Assignee: (was: Matt Hogstrom) Connector portlet delete challenge -- Key: GERONIMO-1182 URL: http://issues.apache.org/jira/browse/GERONIMO-1182 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.0-M5 Environment: Win XP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.1 Attachments: GERONIMO-1182-1.1.1.patch, GERONIMO-1182-1.patch, GERONIMO-1182.patch Minor improvements to Connector portlet. 1. User confirmation on clicking delete link to delete a connector. 2. Add Reset and Cancel buttons to edit pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2030) Allow WebServiceBuilder determine if there are WebServices to be deployed
[ http://issues.apache.org/jira/browse/GERONIMO-2030?page=all ] Sachin Patel updated GERONIMO-2030: --- Assignee: (was: Matt Hogstrom) 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 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] Updated: (GERONIMO-1906) Cannot add a new connector using ActiveMQManagerGBean
[ http://issues.apache.org/jira/browse/GERONIMO-1906?page=all ] Sachin Patel updated GERONIMO-1906: --- Assignee: (was: Matt Hogstrom) Cannot add a new connector using ActiveMQManagerGBean - Key: GERONIMO-1906 URL: http://issues.apache.org/jira/browse/GERONIMO-1906 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: ActiveMQ Affects Versions: 1.1 Environment: Geronimo 1.1 build, rev 396619; activemq_version=3.2.4-SNAPSHOT Reporter: Paul McMahan Priority: Critical Fix For: 1.1.1 Attachments: ACTIVEMQ-gbeaninfo.diff Calling this API: myJMSManager.addConnector( myJMSBroker, name, protocol, host, port ); Produces the following ST: java.lang.AssertionError: javax.management.MalformedObjectNameException: Invalid value: geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ.activeio.0.0.0.0.61616-test at org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:98) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:66) at org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54) at org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:179) at org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.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:816) 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.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$2bdd185c.addConnector(generated) at org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:274) at org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80) at org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229) at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) 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.doInclude(ApplicationDispatcher.java:574) at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499) at org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120) at org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68) at org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164) at org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82) at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) 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:482) at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:336) at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) at
[jira] Updated: (GERONIMO-2007) Avoid Classloader warnings generated by BasicProxyManager
[ http://issues.apache.org/jira/browse/GERONIMO-2007?page=all ] Sachin Patel updated GERONIMO-2007: --- Assignee: (was: Matt Hogstrom) Avoid Classloader warnings generated by BasicProxyManager - Key: GERONIMO-2007 URL: http://issues.apache.org/jira/browse/GERONIMO-2007 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Paul McMahan Fix For: 1.1.1 Attachments: GERONIMO-2007.patch Several views in the console create proxies for objects that implement interfaces not available in the console's classloader. The warning messages look like: 08:56:26,315 WARN [BasicProxyManager] Could not load interface org.apache.geronimo.tomcat.TomcatWebContainer in provided ClassLoader for geronimo/tomcat/1.1-SNAPSHOT/car?ServiceModule=geronimo/tomcat/1.1-SNAPSHOT/car,j2eeType=GBean,name=TomcatWebContainer This warning message can be avoided by getting the classloader for the proxied object from the kernel and then using it to create the proxy. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2073) Copyright date in the console needs to be updated
[ http://issues.apache.org/jira/browse/GERONIMO-2073?page=all ] Sachin Patel updated GERONIMO-2073: --- Assignee: (was: Matt Hogstrom) Copyright date in the console needs to be updated - Key: GERONIMO-2073 URL: http://issues.apache.org/jira/browse/GERONIMO-2073 Project: Geronimo Issue Type: Task Security Level: public(Regular issues) Components: console Affects Versions: 1.1 Reporter: Hernan Cunico Fix For: 1.1.1 Attachments: index-dates.patch, welcomeNormal-date.patch The welcome page, once you logged in the Geronimo Administration Console shows: Copyright © 1999-2005 Apache Software Foundation All Rights Reserved it needs to be updated to 2006 Copyright © 1999-2006 Apache Software Foundation All Rights Reserved -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2072) Client-Deployer config is using wrong/hardcoded commons-primitives version
[ http://issues.apache.org/jira/browse/GERONIMO-2072?page=all ] Sachin Patel updated GERONIMO-2072: --- Assignee: (was: Matt Hogstrom) Client-Deployer config is using wrong/hardcoded commons-primitives version -- Key: GERONIMO-2072 URL: http://issues.apache.org/jira/browse/GERONIMO-2072 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Donald Woods Fix For: 1.1.1 Attachments: Geronimo-2072.patch Client-Deployer config is using a hardcoded commons-primitives version of 1.0 instead of using the project.properties value of 20041207.202534. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1476) Changes to default log4j.rootCategory are not dynamic
[ http://issues.apache.org/jira/browse/GERONIMO-1476?page=all ] Sachin Patel updated GERONIMO-1476: --- Assignee: (was: Donald Woods) Unassigning this so it can be picked up by a committer for inclusion in 1.1.1 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 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] Updated: (GERONIMO-1817) Test a Login while adding LDAP Realm fails with NullPointerException
[ http://issues.apache.org/jira/browse/GERONIMO-1817?page=all ] Sachin Patel updated GERONIMO-1817: --- Assignee: (was: Donald Woods) Unassigning this so it can be picked up by a committer for inclusion in 1.1.1 Test a Login while adding LDAP Realm fails with NullPointerException -- Key: GERONIMO-1817 URL: http://issues.apache.org/jira/browse/GERONIMO-1817 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.0, 1.2, 1.1 Environment: WinXP, Sun JDK 1.4.2_08 Reporter: Vamsavardhana Reddy Fix For: 1.1.1 Attachments: GERONIMO-1817.patch Test a Login function while adding LDAP Realm through Admin Console fails with NullPointerException due to connectionProtocol parameter. The problem is similar to GERONIMO-1791. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1791) LDAP Security Realm created via Console can fail deployment
[ http://issues.apache.org/jira/browse/GERONIMO-1791?page=all ] Sachin Patel updated GERONIMO-1791: --- Assignee: (was: Donald Woods) Unassigning this so it can be picked up by a committer for inclusion in 1.1.1 LDAP Security Realm created via Console can fail deployment --- Key: GERONIMO-1791 URL: http://issues.apache.org/jira/browse/GERONIMO-1791 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 1.0, 1.1, 1.2 Environment: Geronimo 1.0.0 Reporter: Donald Woods Priority: Minor Fix For: 1.1.1 Attachments: G1791.patch, Geronimo-1791.patch Creation of an LDAP Security Realm through the Console can fail at runtime, due to a NullPointerException being thrown by the LDAPLoginModule not checking that the optional connectionProtocl and authentication attributes have not been supplied, while other attributes are being checked for null and empty string. 655: 17:43:45,328 WARN [TomcatGeronimoRealm] Login exception authenticating username system 656: javax.security.auth.login.LoginException: Error filling callback list 657: at org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:78) 658: at org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189) 659: at org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113) 660: at sun.reflect.GeneratedMethodAccessor218.invoke(Unknown Source) 661: at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java(Compiled Code)) 662: at java.lang.reflect.Method.invoke(Method.java(Compiled Code)) 663: at javax.security.auth.login.LoginContext.invoke(LoginContext.java:699) 664: at javax.security.auth.login.LoginContext.access$000(LoginContext.java:151) 665: at javax.security.auth.login.LoginContext$4.run(LoginContext.java:634) 666: at java.security.AccessController.doPrivileged1(Native Method) 667: at java.security.AccessController.doPrivileged(AccessController.java(Compiled Code)) 668: at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:631) 669: at javax.security.auth.login.LoginContext.login(LoginContext.java:557) 670: at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.authenticate(TomcatGeronimoRealm.java:332) 671: at org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.authenticate(TomcatGeronimoRealm.java:282) 672: at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:256) 673: at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:391) 674: at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:273) 675: at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31) 676: at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) 677: at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) 678: at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) 679: at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:526) 680: at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) 681: at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) 682: at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744) 683: at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) 684: at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) 685: at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) 686: at java.lang.Thread.run(Thread.java:570) 687: Caused by: javax.security.auth.login.LoginException: LDAP Error 688: at org.apache.geronimo.security.realm.providers.LDAPLoginModule.login(LDAPLoginModule.java:162) 689: at org.apache.geronimo.security.jaas.server.JaasLoginService.performLogin(JaasLoginService.java:236) 690: at org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.invoke(generated) 691: at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java(Inlined Compiled Code)) 692: at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java(Compiled Code)) 693: at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java(Inlined Compiled Code)) 694: at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java(Compiled Code)) 695: at
[jira] Updated: (GERONIMO-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1716?page=all ]
Sachin Patel updated GERONIMO-1716:
---
Assignee: (was: Donald Woods)
Unassigning this so it can be picked up by a committer for inclusion in 1.1.1
Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
Key: GERONIMO-1716
URL: http://issues.apache.org/jira/browse/GERONIMO-1716
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: security
Affects Versions: 1.0, 1.1, 1.2
Environment: Any
Reporter: Donald Woods
Priority: Minor
Fix For: 1.1.1
Attachments: Geronimo-1716.patch
Enhancement to the default PropertiesFileLoginModule and Console to encrypt
user passwords in users.properties.
To do this, PropertiesFileLoginModule and Console will be updated to use the
SimpleEncryption utility class, just like the deployer, to read/write
passwords that have the {Simple} key in front of encrypted passwords.
The loadProperties() method in PropertiesFileLoginModule will also be updated
to rewrite the users.properties file if it detects unencrypted passwords,
which will allow users to manually edit the file to update a password and
then have it automatically encrypted when the next login event occurs.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1037) Clicking on uninstall link in Applications management pages deletes the configuration without any confirmation from user
[ http://issues.apache.org/jira/browse/GERONIMO-1037?page=all ]
Sachin Patel updated GERONIMO-1037:
---
Assignee: (was: Donald Woods)
Unassigning this so it can be picked up by a committer for inclusion in 1.1.1
Clicking on uninstall link in Applications management pages deletes the
configuration without any confirmation from user
--
Key: GERONIMO-1037
URL: http://issues.apache.org/jira/browse/GERONIMO-1037
Project: Geronimo
Issue Type: Improvement
Security Level: public(Regular issues)
Components: console
Affects Versions: 1.0-M5
Reporter: Vamsavardhana Reddy
Priority: Trivial
Fix For: 1.1.1
Attachments: fix.txt, GERONIMO-1037.patch, jmsserver.patch, normal.jsp
Clicking on uninstall link in Applications Management pages deletes the
configuration without giving a second chance to the user to confirm or cancel
the uninstall operation. Asking for user confirmation will definitely
prevent accidental uninstallation of wrong configuration. This can be
achieved by handling the onClick event of the corresponding link.
File to be updated:
applications/console-standard/src/webapp/WEB-INF/view/configmanager/normal.jsp
Add onClick=return confirm('Are you sure you want to uninstall
${configInfo.configID}?'); to the the link conrresponsding to Uninstall
operation.
--
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-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Rick McGuire reassigned GERONIMO-1695: -- Assignee: Kevan Miller (was: Rick McGuire) CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: CORBA Affects Versions: 1.0 Reporter: Aaron Mulder Assigned To: Kevan Miller Priority: Critical Fix For: 1.2, 1.1.1 Attachments: GERONIMO-1695.diff-1.1.1, GERONIMO-1695.diff-1.2, GERONIMO-1695.diff-1.2a I have an EJB with a local interface and I tried applying CORBA settings. It blows up during deployment. My guess is that it wants a remote interface to be there, but somehow, the checks in StandardServant:126 are not working and the interface just comes up as null. Caused by: java.lang.NullPointerException at org.openejb.corba.util.Util.getAllInterfaces(Util.java:593) at org.openejb.corba.util.Util.getAllMethods(Util.java:815) at org.openejb.corba.util.Util.iiopMap(Util.java:608) at org.openejb.corba.util.Util.mapOperationToMethod(Util.java:604) at org.openejb.corba.StandardServant.init(StandardServant.java:135) at org.openejb.corba.StandardServant.init(StandardServant.java:116) at org.openejb.corba.Adapter.init(Adapter.java:100) ... 67 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-2198) CSSBean creates 2 unnecessary threads for every instance.
[ http://issues.apache.org/jira/browse/GERONIMO-2198?page=all ] Rick McGuire reassigned GERONIMO-2198: -- Assignee: Kevan Miller (was: Rick McGuire) CSSBean creates 2 unnecessary threads for every instance. - Key: GERONIMO-2198 URL: http://issues.apache.org/jira/browse/GERONIMO-2198 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: OpenEJB Affects Versions: 1.1 Reporter: Rick McGuire Assigned To: Kevan Miller Fix For: 1.1.1 Attachments: geronimo-2198.diff The CSSBean creates 2 ORB instances, then spins off a thread for each that calls orb.run(). This is completely unnecessary, since orb.run() doesn't actually run anythingit just causes the thread to wait until orb.destroy() is called. These two thread instances are pure overhead, with no functional purpose. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2092) Modules migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2092?page=all ] Jason Dillon closed GERONIMO-2092. -- Resolution: Invalid Assignee: Jason Dillon Not really sure what the point of this issue is... The one problem mentioned in the comments are managed by GERONIMO-2210. Modules migration to M2 --- Key: GERONIMO-2092 URL: http://issues.apache.org/jira/browse/GERONIMO-2092 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2 Environment: All Reporter: Anita Kulshreshtha Assigned To: Jason Dillon Fix For: 1.2 The work done by Jacek Laskowski, Prasad Kashyap, Anita Kulshreshtha, reghuram rajakumar vasanthakumari, Anders Hessellund Jensen, and Andrew Steeley under GERONIMO-851 has been committed to the new trunk. This issue is to keep up with the changes to M1 build. -- 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: Re: Upgrading JIRA later today
How are we doing on performance and memory for the new JIRA version? Are we ready to add some more plugins? * Toolkit * Chart * Label? --jason On 7/14/06, Jeff Turner [EMAIL PROTECTED] wrote: On Fri, Jul 14, 2006 at 10:30:53AM -0700, Jason Dillon wrote: How did this go? Looks like issues is running 3.6.3-DEV-ASF-#156... does this fix the wiki bits? Yes. I've just reenabled wiki syntax for GERONIMO and GBUILD. I don't see the tools plugin or the graph plugin though :-( Are those going to make it in? Not immediately. In the past the toolkit/charting plugins have introduced performance and memory problems, and I'd like to see JIRA running for a few days on vanilla 3.6.x before introducing new variables. --Jeff --jason On Jul 13, 2006, at 8:06 PM, Jeff Turner wrote: Hi, At about 7am UTC: http://www.timeanddate.com/worldclock/fixedtime.html? month=7day=14year=2006hour=17min=0sec=0p1=240 I'd like to upgrade JIRA to 3.6.x This will fix an XSS hole in wiki rendering (currently disabled), fix the bug that led to HTTPS being disabled, and allow us to import the Torque CSV data. --Jeff
[m2 build] Problem with car:package, rmi-naming and mvn site
Anyone know why this error (um set of errors?) might happen in rmi- naming when running car:package? This only happens when you run a `mvn site` build. You can `cd configs/rmi-naming; mvn site` to quickly reproduce (assuming you have a bootstrap/build before). snip Packaging configuration /Users/jason/ws/apache/geronimo/svkmerge/ m2migration/configs/rmi-naming/target/clover/plan/plan.xml ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException: Unable to resolve reference ServerInfo in gbean org.apache.geronimo.configs/rmi- naming/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/rmi- naming/1.2-SNAPSHOT/car,j2eeType=GBean,name=SystemProperties to a gbean matching the pattern [? j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.Ser verInfo] Unable to resolve reference PluginAttributeStore in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=AttributeStore,name=AttributeManager#org.apache.geronimo.system .configuration.PluginAttributeStore] Unable to resolve reference ConfigStore in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=ConfigurationStore,name=Local#org.apache.geronimo.kernel.config .ConfigurationStore] Unable to resolve reference ConfigManager in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=ConfigurationManager,name=ConfigurationManager#org.apache.geron imo.kernel.config.ConfigurationManager] Unable to resolve reference Repository in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=Repository,name=Repository#org.apache.geronimo.kernel.repositor y.WritableListableRepository] Unable to resolve reference ServerInfo in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.Ser verInfo] org.apache.geronimo.common.DeploymentException: Unable to resolve reference ServerInfo in gbean org.apache.geronimo.configs/rmi- naming/1.2-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/rmi- naming/1.2-SNAPSHOT/car,j2eeType=GBean,name=SystemProperties to a gbean matching the pattern [? j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.Ser verInfo] Unable to resolve reference PluginAttributeStore in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=AttributeStore,name=AttributeManager#org.apache.geronimo.system .configuration.PluginAttributeStore] Unable to resolve reference ConfigStore in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=ConfigurationStore,name=Local#org.apache.geronimo.kernel.config .ConfigurationStore] Unable to resolve reference ConfigManager in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=ConfigurationManager,name=ConfigurationManager#org.apache.geron imo.kernel.config.ConfigurationManager] Unable to resolve reference Repository in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=Repository,name=Repository#org.apache.geronimo.kernel.repositor y.WritableListableRepository] Unable to resolve reference ServerInfo in gbean org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/car? ServiceModule=org.apache.geronimo.configs/rmi-naming/1.2-SNAPSHOT/ car,j2eeType=GBean,name=PluginInstaller to a gbean matching the pattern [? j2eeType=GBean,name=ServerInfo#org.apache.geronimo.system.serverinfo.Ser verInfo] at org.apache.geronimo.deployment.DeploymentContext.getConfigurationData (DeploymentContext.java:381) at org.apache.geronimo.deployment.Deployer.deploy (Deployer.java:304) at
[jira] Commented: (GERONIMO-2145) NPE in Maven1Repository
[ http://issues.apache.org/jira/browse/GERONIMO-2145?page=comments#action_12422735 ] Jason Dillon commented on GERONIMO-2145: What is the problem this issue is talking about? I don't see anything wrong. What is the stack of the NPE? NPE in Maven1Repository --- Key: GERONIMO-2145 URL: http://issues.apache.org/jira/browse/GERONIMO-2145 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Circa line 66: path.listFiles() returns null if it's not a directory or whatever. -- 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-1781) FileSystemRepository not able to handle entry with version number which is a single digit
[ http://issues.apache.org/jira/browse/GERONIMO-1781?page=comments#action_12422738 ] Jason Dillon commented on GERONIMO-1781: Where is FileSystemRepository.java? Looks like this is for Maven1Repository... FileSystemRepository not able to handle entry with version number which is a single digit - Key: GERONIMO-1781 URL: http://issues.apache.org/jira/browse/GERONIMO-1781 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.0, 1.1, 1.2 Reporter: Vamsavardhana Reddy Priority: Minor Fix For: 1.1.x I see the following in FileSystemRepository.java Pattern.compile((.+)/(.+)s/(.+)-([0-9].+)\\.([^0-9]+)); This reqular expression is not matching an entry like the following. group/jars/artifact-1.jar Here the version number is 1, a single digit. FIX: Change to Pattern.compile((.+)/(.+)s/(.+)-([0-9].*)\\.([^0-9]+)) -- 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-2072) Client-Deployer config is using wrong/hardcoded commons-primitives version
[ http://issues.apache.org/jira/browse/GERONIMO-2072?page=comments#action_12422754 ] Jason Dillon commented on GERONIMO-2072: Any idea which is the right version? Client-Deployer config is using wrong/hardcoded commons-primitives version -- Key: GERONIMO-2072 URL: http://issues.apache.org/jira/browse/GERONIMO-2072 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: dependencies Affects Versions: 1.2, 1.1, 1.1.1 Reporter: Donald Woods Fix For: 1.1.1 Attachments: Geronimo-2072.patch Client-Deployer config is using a hardcoded commons-primitives version of 1.0 instead of using the project.properties value of 20041207.202534. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: 1.1.1 Status - Help please
Some of these look easy to fix: * https://issues.apache.org/jira/browse/GERONIMO-2072 * https://issues.apache.org/jira/browse/GERONIMO-2007 * https://issues.apache.org/jira/browse/GERONIMO-2073 But, I am not actively building m1 due to the work I'm doing on m2... and can not easily test the fixes. But these look like low-hanging fruit for those that need a sweet easy to reach snack. --jason On Jul 21, 2006, at 8:54 AM, Matt Hogstrom wrote: All, I am attempting to get some vacation time in this week so I haven't been too active on the list or doing work. There are still most of the JIRAs for 1.1.1 our there for consumption. The ones assigned to me are fair game and if you have some extra cycles and can help please feel free to take any of the JIRAs for me and assign them to yourself. Current course and speed I think we've closed 1 or 2 thanks to Sachin. Any and all help is appreciated to get 1.1.1 done by the end of next week. Thanks in advance. Matt
[jira] Created: (SM-492) Fail Run ServiceMix 3-0-M1.
Fail Run ServiceMix 3-0-M1. --- Key: SM-492 URL: https://issues.apache.org/activemq/browse/SM-492 Project: ServiceMix Issue Type: Bug Environment: ServiceMix 3.0-M1 Binary Package on Windows. 1. Jdk1.6 2. Maven 1.0.2 3. ServiceMix Binary 3-0-M1 Reporter: Praful Shah When I run on ServiceMix after download zip version servicemix binary 3-0-M1 fail with following error msg. Apache ServiceMix ESB: 3.0-M1 Loading Apache ServiceMix from servicemix.xml on the CLASSPATH ERROR - BrokerService.start(370) | Failed to start ActiveMQ JMS Message Broker. Reason: java.io.IOException: Illegal character in hostname at index 11: tcp://ps hah_PC:61616 java.io.IOException: Illegal character in hostname at index 11: tcp://pshah_PC:6 1616 at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport .java:42) at org.apache.activemq.transport.tcp.TcpTransportFactory.doBind(TcpTrans portFactory.java:59) at org.apache.activemq.transport.TransportFactory.bind(TransportFactory. java:108) at org.apache.activemq.broker.TransportConnector.createTransportServer(T ransportConnector.java:237) at org.apache.activemq.broker.TransportConnector.getServer(TransportConn ector.java:110) at org.apache.activemq.broker.TransportConnector.asManagedConnector(Tran sportConnector.java:90) at org.apache.activemq.broker.BrokerService.startTransportConnector(Brok erService.java:1084) at org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerSer vice.java:1052) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:364 ) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBean BrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory. preInstantiateSingletons(DefaultListableBeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:320) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init( ResourceXmlApplicationContext.java:64) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init( ResourceXmlApplicationContext.java:52) at org.apache.activemq.xbean.BrokerFactoryBean.afterPropertiesSet(Broker FactoryBean.java:76) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.AbstractBeanFactory.getType (AbstractBeanFactory.java:342) at org.springframework.beans.factory.support.DefaultListableBeanFactory. isBeanTypeMatch(DefaultListableBeanFactory.java:249) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeanNamesForType(DefaultListableBeanFactory.java:144) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeansOfType(DefaultListableBeanFactory.java:198) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeansOfType(DefaultListableBeanFactory.java:192) at org.springframework.context.support.AbstractApplicationContext.getBea nsOfType(AbstractApplicationContext.java:608) at org.jencks.factory.GeronimoTransactionManagerFactoryBean.getTransacti onContextManager(GeronimoTransactionManagerFactoryBean.java:69) at org.jencks.factory.GeronimoTransactionManagerFactoryBean.getObject(Ge ronimoTransactionManagerFactoryBean.java:47) at org.springframework.beans.factory.support.AbstractBeanFactory.getObje ctForSharedInstance(AbstractBeanFactory.java:813) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:235) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.BeanDefinitionValueResolver
[jira] Updated: (GERONIMO-2145) NPE in Maven1Repository
[ http://issues.apache.org/jira/browse/GERONIMO-2145?page=all ] Aaron Mulder updated GERONIMO-2145: --- Attachment: 2145-NPE.patch Attached patch against 1.1 branch to fix this problem. NPE in Maven1Repository --- Key: GERONIMO-2145 URL: http://issues.apache.org/jira/browse/GERONIMO-2145 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: kernel Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.x Attachments: 2145-NPE.patch Circa line 66: path.listFiles() returns null if it's not a directory or whatever. -- 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: Virtual Topics (was Re: Failover topic subscribers)
Thanks James, that test case works for me too. I wrote a use case that (I
think) covers the base Virtual Topic functionality. There is a problem
somewhere that causes this test to fail. Running it in debug I can see that
the Message is dispatched, but not delivered for some reason. Most of the
internals for virtual topics seem to be working fine though, so thats good
news. If you run the test case below, you can see that the MessageListeners
on the queue don't get any messages. There is some additional code to add
the VirtualTopicBroker to the interceptor chain in BrokerService (or it can
be added as a plugin).
Test case:
package org.apache.activemq.usecases;
import org.apache.log4j.Logger;
import org.apache.activemq.EmbeddedBrokerTestSupport;
import org.apache.activemq.command.ActiveMQQueue;
import org.apache.activemq.command.ActiveMQTopic;
import javax.jms.Session;
import javax.jms.Connection;
import javax.jms.MessageProducer;
import javax.jms.MessageConsumer;
import javax.jms.MessageListener;
import javax.jms.Message;
public class VirtualTopicPubSubTest extends EmbeddedBrokerTestSupport {
private Connection connection;
public void testVirtualTopicCreation( )throws Exception{
if(connection == null){
connection = createConnection();
}
String queueAName = ActiveMQ.Virtual.A.TEST;
//create consumer 'cluster'
ActiveMQQueue queue1 = new ActiveMQQueue(queueAName);
ActiveMQQueue queue2 = new ActiveMQQueue(queueAName);
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageConsumer c1 = session.createConsumer(queue1);
MessageConsumer c2 = session.createConsumer(queue2);
MessageCountListener exclusive1 = new MessageCountListener();
c1.setMessageListener(exclusive1);
MessageCountListener exclusive2 = new MessageCountListener();
c2.setMessageListener(exclusive2);
//create topic producer
MessageProducer producer =
session.createProducer(new ActiveMQTopic(TEST));
assertNotNull(producer);
int total = 10;
for(int i = 0; i total; i++){
producer.send(session.createTextMessage(xx));
}
int delivered = exclusive1.getCount( ) exclusive2.getCount();
assertTrue(Expected +total+ delivered, found +delivered,
delivered == total);
}
class MessageCountListener implements MessageListener{
private int count = 0;
public void onMessage(Message m){
System.out.println(Got one! +count);
count++;
}
public int getCount(){
return count;
}
}
protected void tearDown() throws Exception {
if (connection != null) {
connection.close();
}
super.tearDown();
}
the Broker:
package org.apache.activemq.broker;
import org.apache.activemq.broker.region.Destination;
import org.apache.activemq.command.ActiveMQQueue;
import org.apache.activemq.command.Message;
import java.util.Iterator;
import java.util.Set;
public class VirtualTopicBroker
extends BrokerFilter
implements BrokerPlugin {
public static final String VIRTUAL_WILDCARD = ActiveMQ.Virtual.*;
public VirtualTopicBroker(Broker next) {
super(next);
}
public VirtualTopicBroker() {
super(null);
}
public void send(ConnectionContext ctx,
Message message) throws Exception {
String name = message.getDestination().getPhysicalName();
String virtualName = VIRTUAL_WILDCARD+ name;
Set destinations = getDestinations(
new ActiveMQQueue(virtualName));
for (Iterator iter = destinations.iterator();
iter.hasNext();) {
Destination dest = (Destination) iter.next();
dest.send(ctx, message);
}
next.send(ctx, message);
}
public Broker installPlugin(Broker broker) throws Exception {
return new VirtualTopicBroker(broker);
}
}
--
View this message in context:
http://www.nabble.com/Re%3A-Virtual-Topics-%28was-Re%3A-Failover-topic-subscribers%29-tf1942508.html#a5439965
Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Maven2 Conversation Status
FYI... windows users should extract the assembly dist into c:\ to avoid long file issues. Looks like the longest file in the dist is about 218c (including the basedir name), so extracting into c:\ should avoid any issues on the evil platform of names that must be short. If anyone believes they have run into a log filename problem on windows either building or running the server please let me know asap. --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John Jason Dillon wrote: This should do the trick: 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/startup.sh --user system --password manager --jason PS. I just typed this up in this email, did not actually run this... in my drunken stupor I might have mistyped something... but the general steps are solid (i've been testing w/this for some time). On Jul 19, 2006, at 12:24 AM, Jacek Laskowski wrote: On 7/19/06, Jason Dillon [EMAIL PROTECTED] wrote: Can we get some commitment from PMC members to review and vote in these changes so that we can finally finish the move to Maven 2? I'm on holidays in 2 weeks and would be happy to help out as much as it requires to get it tested and merged with the trunk. How do you want us to help out with it? How should we test it out? Will you send some helpful hints to get us started? Taking the chance I'd like to encourage *anyone* to check out svkmerge/m2conversion branch and give it a whirl. It's a great chance to learn a couple of tips and tricks of using M2 in a project. Jacek --Jacek Laskowski http://www.laskowski.net.pl
Re: GroupId for DayTrader needed.
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: What is product-versions.properties used for?
On Jul 20, 2006, at 9:09 PM, Jason Dillon wrote: Anyone know? Got me. What's in it? -dain
Re: JDBC based Master Slave
If you are using the Geronimo transaction manager, you may want to use the org.apache.geronimo.connector.outbound.transactionlog.JDBCLog, which stores the tx log in the database. This will allow you to support full XA with a single non-xa jdbc connection. -dain On Jul 21, 2006, at 7:24 AM, James Strachan wrote: I've just committed this fairly simple addition to allow users who are not using the high performance journal and are just using pure JDBC for persistence to use a JDBC specific version of master slave which allows many slaves to be run with auto-failover http://activemq.org/site/jdbc-master-slave.html This works in a similar way to the shared file system master slave approach, using an exclusive lock to implement the master but relying on an exclusive database lock rather than a file lock. http://activemq.org/site/shared-file-system-master-slave.html -- James --- http://radio.weblogs.com/0112098/
Re: What is product-versions.properties used for?
snip tranql=1.4-SNAPSHOT openejb=2.2-SNAPSHOT geronimo=1.2-SNAPSHOT activemq=3.2.4-SNAPSHOT /snip --jason On Jul 21, 2006, at 4:36 PM, Dain Sundstrom wrote: On Jul 20, 2006, at 9:09 PM, Jason Dillon wrote: Anyone know? Got me. What's in it? -dain
[jira] Commented: (SM-492) Fail Run ServiceMix 3-0-M1.
[ https://issues.apache.org/activemq/browse/SM-492?page=comments#action_36606 ] Ramon Buckland commented on SM-492: --- The error is caused because the name of the computer has an underscore in it. java.io.IOException: Illegal character in hostname at index 11: tcp://pshah_PC:61616 index 11 means the 11th character (0th based string), Change the name of your computer to not have an underscore and it will be okay. It is a standard that underscores are not permitted because of their confusion with a dash (-) in written form. http://www.camtp.uni-mb.si/books/Internet-Book/DNS_NameFormat.html This issue should be closed. Fail Run ServiceMix 3-0-M1. --- Key: SM-492 URL: https://issues.apache.org/activemq/browse/SM-492 Project: ServiceMix Issue Type: Bug Environment: ServiceMix 3.0-M1 Binary Package on Windows. 1. Jdk1.6 2. Maven 1.0.2 3. ServiceMix Binary 3-0-M1 Reporter: Praful Shah When I run on ServiceMix after download zip version servicemix binary 3-0-M1 fail with following error msg. Apache ServiceMix ESB: 3.0-M1 Loading Apache ServiceMix from servicemix.xml on the CLASSPATH ERROR - BrokerService.start(370) | Failed to start ActiveMQ JMS Message Broker. Reason: java.io.IOException: Illegal character in hostname at index 11: tcp://ps hah_PC:61616 java.io.IOException: Illegal character in hostname at index 11: tcp://pshah_PC:6 1616 at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport .java:42) at org.apache.activemq.transport.tcp.TcpTransportFactory.doBind(TcpTrans portFactory.java:59) at org.apache.activemq.transport.TransportFactory.bind(TransportFactory. java:108) at org.apache.activemq.broker.TransportConnector.createTransportServer(T ransportConnector.java:237) at org.apache.activemq.broker.TransportConnector.getServer(TransportConn ector.java:110) at org.apache.activemq.broker.TransportConnector.asManagedConnector(Tran sportConnector.java:90) at org.apache.activemq.broker.BrokerService.startTransportConnector(Brok erService.java:1084) at org.apache.activemq.broker.BrokerService.startAllConnectors(BrokerSer vice.java:1052) at org.apache.activemq.broker.BrokerService.start(BrokerService.java:364 ) at org.apache.activemq.xbean.XBeanBrokerService.afterPropertiesSet(XBean BrokerService.java:43) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.DefaultListableBeanFactory. preInstantiateSingletons(DefaultListableBeanFactory.java:275) at org.springframework.context.support.AbstractApplicationContext.refres h(AbstractApplicationContext.java:320) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init( ResourceXmlApplicationContext.java:64) at org.apache.xbean.spring.context.ResourceXmlApplicationContext.init( ResourceXmlApplicationContext.java:52) at org.apache.activemq.xbean.BrokerFactoryBean.afterPropertiesSet(Broker FactoryBean.java:76) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1059) at org.springframework.beans.factory.support.AbstractAutowireCapableBean Factory.createBean(AbstractAutowireCapableBeanFactory.java:363) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:226) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean (AbstractBeanFactory.java:147) at org.springframework.beans.factory.support.AbstractBeanFactory.getType (AbstractBeanFactory.java:342) at org.springframework.beans.factory.support.DefaultListableBeanFactory. isBeanTypeMatch(DefaultListableBeanFactory.java:249) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeanNamesForType(DefaultListableBeanFactory.java:144) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeansOfType(DefaultListableBeanFactory.java:198) at org.springframework.beans.factory.support.DefaultListableBeanFactory. getBeansOfType(DefaultListableBeanFactory.java:192) at
[jira] Commented: (SM-491) Links in apache-servicemix-3.0-M2-incubating/README are stale/broken.
[ https://issues.apache.org/activemq/browse/SM-491?page=comments#action_36607 ] Ramon Buckland commented on SM-491: --- The correct URLs (at the moment) should be .. Getting Started === To find out how to get started try this http://www.servicemix.org/site/getting-started.html If you need more help try talking to us on our mailing lists http://www.servicemix.org/site/mailing-lists.html We welcome contributions http://www.servicemix.org/site/contributing.html Many thanks for using Apache ServiceMix. The ServiceMix Team http://www.servicemix.org/site/team.html Links in apache-servicemix-3.0-M2-incubating/README are stale/broken. - Key: SM-491 URL: https://issues.apache.org/activemq/browse/SM-491 Project: ServiceMix Issue Type: Wish Affects Versions: 3.0-M2 Environment: All (documentation) Reporter: Jeffrey Grabell Priority: Trivial Original Estimate: 1 day Remaining Estimate: 1 day These links in the README do not work: Getting Started === To find out how to get started try this http://incubator.apache.org/servicemix/Getting+Started If you need more help try talking to us on our mailing lists http://incubator.apache.org/servicemix/Mailing+Lists We welcome contributions http://incubator.apache.org/servicemix/Contributing Many thanks for using Apache ServiceMix. The ServiceMix Team http://incubator.apache.org/servicemix/Team -- 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: Maven2 Conversation Status
Jason Dillon wrote: John, if you can please post the surefire reports for the failed tests in timer so I can verify they are indeed related to GERONIMO-2183 (and unrelated to the m2 work). Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). I did try again today and for some reason I am being prompted for a svn password for codehaus, which I didn't get before: [INFO] Geronimo :: Timer . SUCCESS [1:22.672s] [INFO] Geronimo :: Tomcat SUCCESS [1:13.828s] [INFO] Geronimo :: Tomcat :: Builder . SUCCESS [20.610s] [INFO] Geronimo :: Upgrade ... SUCCESS [5.203s] [INFO] Geronimo :: Plugins ... SUCCESS [0.125s] [INFO] Geronimo Plugins :: CAR ... SUCCESS [11.047s] [INFO] Geronimo Plugins :: Deployment SUCCESS [2.968s] [INFO] [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 10 minutes 34 seconds [INFO] Finished at: Sat Jul 22 10:52:38 EST 2006 [INFO] Final Memory: 27M/56M [INFO] Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': John Thanks, --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John
Re: Where the heck does this come from?
I don't see your mail there http://mail-archives.apache.org/mod_mbox/ws-scout-dev/ John Jason Dillon wrote: So far no response from the scout peeps... :-( --jason On Jul 19, 2006, at 4:34 PM, John Sisson wrote: I noticed the scout.log entry below. I looked in geronimo-1.1\repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value=[FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Re: Maven2 Conversation Status
Yes, I just started seeing that too... not sure wtf is going on... Changing to use http instead of https fixes... But something recently changed at the haus. --jason On Jul 21, 2006, at 6:01 PM, John Sisson wrote: Jason Dillon wrote: John, if you can please post the surefire reports for the failed tests in timer so I can verify they are indeed related to GERONIMO-2183 (and unrelated to the m2 work). Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). I did try again today and for some reason I am being prompted for a svn password for codehaus, which I didn't get before: [INFO] Geronimo :: Timer . SUCCESS [1:22.672s] [INFO] Geronimo :: Tomcat SUCCESS [1:13.828s] [INFO] Geronimo :: Tomcat :: Builder . SUCCESS [20.610s] [INFO] Geronimo :: Upgrade ... SUCCESS [5.203s] [INFO] Geronimo :: Plugins ... SUCCESS [0.125s] [INFO] Geronimo Plugins :: CAR ... SUCCESS [11.047s] [INFO] Geronimo Plugins :: Deployment SUCCESS [2.968s] [INFO] -- -- [INFO] -- -- [INFO] BUILD SUCCESSFUL [INFO] -- -- [INFO] Total time: 10 minutes 34 seconds [INFO] Finished at: Sat Jul 22 10:52:38 EST 2006 [INFO] Final Memory: 27M/56M [INFO] -- -- Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': John Thanks, --jason On Jul 20, 2006, at 10:02 PM, John Sisson wrote: It built successfully for me in cygwin (first attempt failed in timer tests). I'll try to do some tests on the weekend. I agree with Jeff's comments that we should have this pass the TCK before it is merged back to trunk. Thanks, John
Re: Where the heck does this come from?
K, I will send again... gods must be toying with me. --jason On Jul 21, 2006, at 6:04 PM, John Sisson wrote: I don't see your mail there http://mail-archives.apache.org/mod_mbox/ws-scout-dev/ John Jason Dillon wrote: So far no response from the scout peeps... :-( --jason On Jul 19, 2006, at 4:34 PM, John Sisson wrote: I noticed the scout.log entry below. I looked in geronimo-1.1 \repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value= [FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Fix scout-0.5.jar (was Re: Where the heck does this come from?)
Ug, well this time I got back a failure telling me I have subscribe... and right now I'm seriously melting into my couch and not really happy to need to subscribe yet another list to go and tell some developers about a problem with there code. Maybe I will go crawl in the fridge for a few hours and feel better and try again. But, is anyone on that list already? We need this commented: snip # Uncomment to have log4j be verbose while parsing this file log4j.debug /snip from their log4j.properties... or better IMO the log4j.properties removed from the jar. --jason On Jul 21, 2006, at 6:04 PM, John Sisson wrote: I don't see your mail there http://mail-archives.apache.org/mod_mbox/ws-scout-dev/ John Jason Dillon wrote: So far no response from the scout peeps... :-( --jason On Jul 19, 2006, at 4:34 PM, John Sisson wrote: I noticed the scout.log entry below. I looked in geronimo-1.1 \repository\scout\scout\0.5\scout-0.5.jar in the log4j.properties file and it has log4j.debug uncommented! I think that is the culprit. May want to send a mail to the scout project http://ws.apache.org/scout/ John Jason Dillon wrote: snip log4j: Parsing for [root] with value=[WARN, LOGFILE]. log4j: Level token is [WARN]. log4j: Category root set to WARN log4j: Parsing appender named LOGFILE. log4j: Parsing layout options for LOGFILE. log4j: Setting property [dateFormat] to [ISO8601]. log4j: Setting property [contextPrinting] to [true]. log4j: End of parsing for LOGFILE. log4j: Setting property [maxBackupIndex] to [3]. log4j: Setting property [maxFileSize] to [10MB]. log4j: Setting property [file] to [scout.log]. log4j: setFile called: scout.log, true log4j: setFile ended log4j: Parsed LOGFILE options. log4j: Parsing for [org.apache.axis.enterprise] with value= [FATAL, CONSOLE]. log4j: Level token is [FATAL]. log4j: Category org.apache.axis.enterprise set to FATAL log4j: Parsing appender named CONSOLE. log4j: Parsing layout options for CONSOLE. log4j: Setting property [conversionPattern] to [- %m%n]. log4j: End of parsing for CONSOLE. log4j: Setting property [threshold] to [INFO]. log4j: Parsed CONSOLE options. log4j: Handling log4j.additivity.org.apache.axis.enterprise=[null] log4j: Finished configuring. /snip --jason
Re: Maven2 Conversation Status
Unfortunately I didn't keep the reports from when it failed. I assumed it was due to other stuff running on my machine (Thunderbird seems to be looping a lot lately consuming most of the cpu). No worries, I'm 99% sure they failed in a harmless way to due to lack of cpu availability for the test to complete in the alloted time. I'm considering turning those tests off until they are fixed to pass unless something is actually broken. - Building OpenEJB2... Authentication realm: https://svn.codehaus.org:443 openejb Repo Password for 'sissonj': This is fixed now. If you sync your workspace (to at least #424511), then run this, it should take off from where it failed asking for a passwd: ./bootstrap openejb2 ./build -Dstage=assemble --jason
