[jira] Resolved: (AMQ-1072) TimeToLive doesn't work on MessageListener
[ https://issues.apache.org/activemq/browse/AMQ-1072?page=all ] james strachan resolved AMQ-1072. - Fix Version/s: 4.1.0 Resolution: Fixed This has been fixed in 4.1 TimeToLive doesn't work on MessageListener Key: AMQ-1072 URL: https://issues.apache.org/activemq/browse/AMQ-1072 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 4.0.1 Reporter: Joseph Leung Fix For: 4.1.0 When a queue message is consumed using MessageListener throught the setMessageListener method, it could recieve the messages even if they are expired. (While using consumer.receive() will discard them). Reproduce Steps: 1. deliver a number of message to a queue with a short expire time. 2. wait until the message should be expired. 3. use MessageConsumer.receive() method to receive the messages, -- You should not receive any messages, and through the monitor console, you should see some messages are left and not discarded. 4. stop the receive() method. 5. add a MessageListener to the same queue, the messages which found left is received by the onMessage() method. ps. if step3 is skipped, likely you would receive all the expired message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-1054) XA recover fails for 4.0.1
[ https://issues.apache.org/activemq/browse/AMQ-1054?page=all ] james strachan updated AMQ-1054: Fix Version/s: 4.1.1 updated fix versions XA recover fails for 4.0.1 -- Key: AMQ-1054 URL: https://issues.apache.org/activemq/browse/AMQ-1054 Project: ActiveMQ Issue Type: Bug Environment: Java, JDK 1.4, Windows, Atomikos TransactionsEssentials for the JTA/XA part Reporter: Guy Pardon Fix For: 4.2.0, 4.1.1 Attachments: pom.xml XAResource.recover seems to fail for 4.x of ActiveMQ: ERROR IN RECOVERY [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 [Lorg.apache.activemq.command.DataStructure; [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 at: org.apache.activemq.TransactionContext.recover(TransactionContext.java:508) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 at: com.atomikos.datasource.xa.XATransactionalResource.recover(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 at: com.atomikos.datasource.xa.XATransactionalResource.endRecovery(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,152 at: com.atomikos.icatch.imp.TransactionServiceImp.recover(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 at: com.atomikos.datasource.xa.XATransactionalResource.setRecoveryService(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 at: com.atomikos.icatch.system.Configuration.addResource(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 at: com.atomikos.jms.QueueConnectionFactoryBean.checkSetup(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 at: com.atomikos.jms.QueueConnectionFactoryBean.createQueueConnection(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 at: com.atomikos.jms.QueueConnectionFactoryBean.createConnection(Unknown Source) [thread: SimpleAsyncTaskExecutor-3] on: 06-11-16 08:43:35,153 Also see http://www.atomikos-support.com/forums/viewtopic.php?t=351 (where I borrowed this stack trace from). We have seen similar things in other applications that tried to use ActiveMQ. I think this is a class cast error in ActiveMQ... With 3.1 there is no problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-583) DiscoveryTransportBrokerTest can fail on some platforms
[ https://issues.apache.org/activemq/browse/AMQ-583?page=all ] Fritz Oconer resolved AMQ-583. -- Resolution: Fixed Assignee: Fritz Oconer (was: Darwin Flores) Test now successfully working in trunk - revision: 480854. DiscoveryTransportBrokerTest can fail on some platforms --- Key: AMQ-583 URL: https://issues.apache.org/activemq/browse/AMQ-583 Project: ActiveMQ Issue Type: Test Components: Test Cases Affects Versions: 4.0 RC2 Reporter: james strachan Assigned To: Fritz Oconer e.g. on our CI test rig it works on aladdin but fils on iago, jafa, spinach. Could this be an envrionment thing? (other processes running on the box or something - multicast not properly supported etc?) Or is it just something to do with the test case? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-1078) Messages consumed with the Resource Adapter are intermittently not delivered
[ https://issues.apache.org/activemq/browse/AMQ-1078?page=comments#action_37604 ] Hiram Chirino commented on AMQ-1078: fix in 4.1 branch rev 480862 Messages consumed with the Resource Adapter are intermittently not delivered Key: AMQ-1078 URL: https://issues.apache.org/activemq/browse/AMQ-1078 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.2.0, 4.1.1 The cause is that the ActiveMQSessionExecutor was starting and using it's dispatch thread instead of the Thread managed by the resource adapter. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-1079) Slave Fail Error when Receiving message on a MasterSlave configuration
Slave Fail Error when Receiving message on a MasterSlave configuration -- Key: AMQ-1079 URL: https://issues.apache.org/activemq/browse/AMQ-1079 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 4.2.0 Environment: Windows XP, jdk1.5 Reporter: Marlon Santos Fix For: 4.2.0 Attachments: ConsumerTool.java, MasterSlave.java A slave fail error is caught while receiving message from master broker on a master slave configuration. I included the java files that I used. Running this through xbean/xml config also produces the same error. SEVERE: Slave Failed java.lang.AssertionError: Unsupported Method at org.apache.activemq.transport.TransportSupport.request(TransportSupport.java:71) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.TransportFilter.request(TransportFilter.java:88) at org.apache.activemq.transport.MutexTransport.request(MutexTransport.java:49) at org.apache.activemq.broker.ft.MasterBroker.sendSyncToSlave(MasterBroker.java:363) at org.apache.activemq.broker.ft.MasterBroker.sendToSlave(MasterBroker.java:345) at org.apache.activemq.broker.ft.MasterBroker.acknowledge(MasterBroker.java:320) at org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:88) at org.apache.activemq.broker.TransportConnection.processMessageAck(TransportConnection.java:491) at org.apache.activemq.command.MessageAck.visit(MessageAck.java:179) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:287) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:178) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:65) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:133) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:84) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2579) TestNG testcases in testsuite broken. JUnit expected. Move to JUnit 4.0 ?
[ http://issues.apache.org/jira/browse/GERONIMO-2579?page=all ] Jason Dillon closed GERONIMO-2579. -- Resolution: Won't Fix TestNG with Surefire 2.3-SNAPSHOT appears to work fine with JDK 1.5 annotations. Appears that you need to use a suite.xml to get the @BeforeSuite and @AfterSuite annotations to get triggered though... that may be a bug in how Surefire has implemented TestNG support though. TestNG testcases in testsuite broken. JUnit expected. Move to JUnit 4.0 ? - Key: GERONIMO-2579 URL: http://issues.apache.org/jira/browse/GERONIMO-2579 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 2.0 Reporter: Prasad Kashyap Assigned To: Jason Dillon Fix For: 2.0 Attachments: testng-jdk15.patch The testng testcases broke soon after we moved to building G with jdk1.5. cd geronimo/testsuite apply testng-jdk15.patch: Patch changes testng dependency to use jdk15 classifier. It configures the maven-compiler-plugin to use 1.5 for source and target. It updates the test methods to use jdk1.5 annotations instead of javadoc style comments. Problem: [INFO] [INFO] Compilation failure [INFO] [INFO] C:\Apache\geronimo\trunk\testsuite\console-testsuite\basic\src\test\java\org\apache\geronimo\testsuite\console\LinkCheckTest.java:[30,5] annotations are not supported in -source 1.4 [INFO] (try -source 1.5 to enable annotations) [INFO] @Test [INFO] [INFO] C:\Apache\geronimo\trunk\testsuite\console-testsuite\basic\src\test\java\org\apache\geronimo\testsuite\console\SeleniumTestSupport.java:[53,5] annotations are not supported in -source 1.4 [INFO] (try -source 1.5 to enable annotations) [INFO] @BeforeSuite -- 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: OpenEJB 2 test failures
On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: OpenEJB 2 (2.2 or 2.3) will not build due to test failures in OpenEJB :: Builder: Whoops! It's probably me who broke it. I intentionally turned off the tests to speed up the build and incidentally introduced the failures. Dave J. has proposed to comment out the respective tests in OpenEJB that seem to be the culprit, so at least one possible solution already exist. I should have it fixed soon. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: OpenEJB 2 test failures
Unit tests should not really take to much time... and thus should not really be turned off. Tests may need to be revisited to improve the speed, or split them off into unit and integration tests (easy to do with TestNG using groups). Also, not sure what the fork mode is set to currently for OpenEJB, but if you can, use once to only spin off one jvm for the entire flight of tests. Using pertest will slow things down significantly. --jason On Nov 29, 2006, at 12:09 AM, Jacek Laskowski wrote: On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: OpenEJB 2 (2.2 or 2.3) will not build due to test failures in OpenEJB :: Builder: Whoops! It's probably me who broke it. I intentionally turned off the tests to speed up the build and incidentally introduced the failures. Dave J. has proposed to comment out the respective tests in OpenEJB that seem to be the culprit, so at least one possible solution already exist. I should have it fixed soon. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Created: (GERONIMO-2605) NPE if exporting plugin for module having dependency on module with no groupId
NPE if exporting plugin for module having dependency on module with no groupId -- Key: GERONIMO-2605 URL: http://issues.apache.org/jira/browse/GERONIMO-2605 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: Plugins Affects Versions: 2.0 Reporter: Rakesh Midha Assigned To: Rakesh Midha Fix For: 2.0 If you have an application say ABC.war which has dependency on ABC.jar and if dependency is defined without groupid like in this case dependencies dependency artifactIdABC/artifactId /dependency /dependencies You will get NPE with stacktrace: java.lang.NullPointerException at org.apache.geronimo.system.plugin.PluginInstallerGBean.processDepende ncyList(PluginInstallerGBean.java:1561) at org.apache.geronimo.system.plugin.PluginInstallerGBean.createDefaultM etadata(PluginInstallerGBean.java:1204) at org.apache.geronimo.system.plugin.PluginInstallerGBean.getPluginMetad ata(PluginInstallerGBean.java:204) at org.apache.geronimo.system.plugin.PluginInstallerGBean$$FastClassByCG LIB$$cebc327e.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) -- 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: (GERONIMODEVTOOLS-117) Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies
Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies -- Key: GERONIMODEVTOOLS-117 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.2.0 Environment: http://people.apache.org:80/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v200611280908-deployable.zip Reporter: Michael Moser Trying to add the axis library as dependency to my application. After clicking the Add-button on the deployment configuration tab I get a dialog. When - after entering the data - I click Finish nothing happens. The dialog remains and the .xml file remains as it was. When I hit finish again, the dialog disappears but the XML file still remains unchanged. And the reason is: Unhandled event loop exception java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:619) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:323) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:280) at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:600) at org.apache.geronimo.st.v11.ui.wizards.DependencyWizard.performFinish(DependencyWizard.java:241) at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355) at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.apache.geronimo.st.ui.sections.AbstractTableSection$3.widgetSelected(AbstractTableSection.java:217) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) According to NG (news:[EMAIL PROTECTED]) this should have been fixed, but I just downloaded the latest available build (see environment) and the same bug still exists. Michael -- 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: OpenEJB 2 test failures
On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: OpenEJB 2 (2.2 or 2.3) will not build due to test failures in OpenEJB :: Builder: ... It would be really nice if someone could get this fixed... as G is stuck in the water until these pass. It should be fixed now. Give it a shot and report back. Many thanks for Dave J. for his patch that I have merely checked in. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Created: (AMQ-1077) Bug in STOMP transport unsubscribe
Bug in STOMP transport unsubscribe -- Key: AMQ-1077 URL: https://issues.apache.org/activemq/browse/AMQ-1077 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 4.0.2 Environment: linux 2.6, java 1.5 Reporter: Danielius Jurna Attachments: patch.txt After several ubscribe/unsubscribe commands to activemq, subscribtions are not removed and there's error log in the broker: java.lang.IllegalStateException: Cannot remove a consumer that had not been registered: ID:das-32775-1164773607925-3:1881:-1:2 at org.apache.activemq.broker.AbstractConnection.processRemoveConsumer(AbstractConnection.java:551) at org.apache.activemq.command.RemoveInfo.visit(RemoveInfo.java:64) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:237) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:61) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:92) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:67) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:123) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:70) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:112) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:376) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommad(ProtocolConverter.java:144) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:60) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:88) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:137) at java.lang.Thread.run(Thread.java:595) The problem is that there's internal map of subscriptions in ProtocolConverter class. On unsubscribe command, subscription is not removed from this internal map. Attached patch (against ProtocolConverter.java) fixes this bug -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12454303 ] Vamsavardhana Reddy commented on GERONIMO-2283: --- Each of the repository entries listed on the Common Libs page is made a link which shows usage help upon clicking. Fixed in rev 480561 (branches\1.1), rev 480564 (branches\1.2) and rev 480565 (trunk). Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=comments#action_12454305 ] Vamsavardhana Reddy commented on GERONIMO-2283: --- Regarding the groupId part of the issue, I am noticing on Windows that the groupId filled in upon selecting a file is the directory name in which the jar file is located. I don't see much of a problem with that. The problem I notice is with the artifactId and version. When I select a file like utils-1-r118.jar, the filled in artifactId is utils-1 and version is r118. Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-908) Authorization plugin should have configurable principal classes
[ https://issues.apache.org/activemq/browse/AMQ-908?page=all ]
Jonas Lim resolved AMQ-908.
---
Fix Version/s: (was: 4.0.3)
Resolution: Fixed
Thanks Ken!
patch applied to trunk: r480575
Authorization plugin should have configurable principal classes
---
Key: AMQ-908
URL: https://issues.apache.org/activemq/browse/AMQ-908
Project: ActiveMQ
Issue Type: Improvement
Components: Broker
Affects Versions: 4.0.1
Reporter: Aaron Mulder
Fix For: 4.2.0
Attachments: AuthorizationPlugin.patch, AuthorizationPlugin.patch
Currently, if you configure the authorization plugin, it assumes that all
principals listed should be of type
{{org.apache.activemq.jaas.GroupPrincipal}}. This is OK if you're using
ActiveMQ LoginModules, but since there's a fairly small supply of those, it
would be great if you could use arbitrary login modules and tell the
authorization plugin which principal classes to use. For example,
{{groupClass=weblogic.security.principal.WLSGroupImpl}} or something like
that. A good first step would be to let you change the group class. A good
second step would be to let you specify user and group classes and then
somehow indicate which names are which (e.g.
{{admin=administrators,user:aaron,user:bob}} or whatever). Someday maybe
it will be nice to support any arbitrary combination of principal classes but
that seems far away.
When instantiating the principal classes, I imagine we should use a
constructor with a single String argument if available, or else a default
constructor plus a setName method, or else I guess bail.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2283) Common libs portlet guesses wrong group ID, gives no usage advice
[ http://issues.apache.org/jira/browse/GERONIMO-2283?page=all ] Vamsavardhana Reddy updated GERONIMO-2283: -- Fix Version/s: 1.2 2.0 Common libs portlet guesses wrong group ID, gives no usage advice - Key: GERONIMO-2283 URL: http://issues.apache.org/jira/browse/GERONIMO-2283 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Affects Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2, 1.1.x, 2.0 When selecting a file for the repository portlet, it selected the version number as the group ID. It should probably default to a blank group ID and make the user enter it -- the best it can select from the file name is probably the artifact, version, and type. Also, it should have an option where you pick a JAR and it gives you the dependency syntax you need to add that JAR to the classpath for an application or other Geronimo module. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-2603) Building 1.2 if there are 2.0 artifacts in the repo results in mostly 2.0 artifacts in the server.
[ http://issues.apache.org/jira/browse/GERONIMO-2603?page=comments#action_12454301 ] Anita Kulshreshtha commented on GERONIMO-2603: -- David, That is exactly where I looked for the car-maven-plugin version. After I wrote this comemnt I found it in configs pom. I was glad to see that geronimoVersion property has been reincarnated into a property named 'version': version2.0-SNAPSHOT/version AFAIK, maven allows 'pom.version' and 'version' to be used interchangeably. We are using the above line twice, once in the version declaration and once in properties. Will it cause problems? Building 1.2 if there are 2.0 artifacts in the repo results in mostly 2.0 artifacts in the server. -- Key: GERONIMO-2603 URL: http://issues.apache.org/jira/browse/GERONIMO-2603 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2, 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 2.0 PackageMojo basically uses the local maven repo to run geronimo off of. This only really works if only the versions of geronimo stuff you want are in the repo, otherwise you keep picking up later versions. Solution seems to be to make the repository adapter only let you see the transitive dependencies of the stuff in your pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-117) Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117?page=comments#action_12454328 ] Sachin Patel commented on GERONIMODEVTOOLS-117: --- When you extracted the daily driver over the existing install, did you relaunch eclipse with -clean? I was able to reproduce the problem and I committed a fix and it should be resolved in that driver. Geronimo deployement plan editor crashes with ArrayStoreException when adding dependencies -- Key: GERONIMODEVTOOLS-117 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-117 Project: Geronimo-Devtools Issue Type: Bug Affects Versions: 1.2.0 Environment: http://people.apache.org:80/dist/geronimo/eclipse/unstable/g-eclipse-plugin-1.2.0-v200611280908-deployable.zip Reporter: Michael Moser Trying to add the axis library as dependency to my application. After clicking the Add-button on the deployment configuration tab I get a dialog. When - after entering the data - I click Finish nothing happens. The dialog remains and the .xml file remains as it was. When I hit finish again, the dialog disappears but the XML file still remains unchanged. And the reason is: Unhandled event loop exception java.lang.ArrayStoreException at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:188) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:619) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:323) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:280) at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:600) at org.apache.geronimo.st.v11.ui.wizards.DependencyWizard.performFinish(DependencyWizard.java:241) at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:680) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:355) at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:660) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.jface.window.Window.runEventLoop(Window.java:820) at org.eclipse.jface.window.Window.open(Window.java:796) at org.apache.geronimo.st.ui.sections.AbstractTableSection$3.widgetSelected(AbstractTableSection.java:217) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:280) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) According to NG (news:[EMAIL PROTECTED]) this should have been fixed, but I just downloaded the latest available build (see environment) and the same bug still exists. Michael -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
David,
I think this is a great idea. However, I'm curious about the need for
the 1.4 specs in trunk. Do you envision this soon being replaced by a
JavaEE5 specs car? Should we just rename this now to be JavaEE5 and
then update the individual specs contained within it? Just curious on
how you were thinking that we would handle the 1.4 to EE 5 move.
I'd also like to get the Jetty6 implementation from the sandbox included
in trunk soon. Along the same lines as above, I assume that we would
drop the -jee5 suffixes as well as the 6 from the jetty artifacts
and integrate these changes directly into the appropriate items in
trunk. Being that we now have a branch for 1.2 and trunk is building
exclusively using 1.5 (both source and target) I don't think there is a
need to continue to maintain the Jetty 5.* in trunk. If you don't have
any objects I'll be looking moving these changes into trunk with those
assumptions.
Joe
[EMAIL PROTECTED] wrote:
Author: djencks
Date: Tue Nov 28 17:54:42 2006
New Revision: 480329
URL: http://svn.apache.org/viewvc?view=revrev=480329
Log:
GERONIMO-2604 create a specs car
Added:
geronimo/server/trunk/configs/j2ee-1.4-specs/
- copied from r476125, geronimo/server/trunk/configs/rmi-naming/
geronimo/server/trunk/configs/j2ee-1.4-specs/LICENSE.txt
- copied unchanged from r480282,
geronimo/server/trunk/configs/rmi-naming/LICENSE.txt
geronimo/server/trunk/configs/j2ee-1.4-specs/NOTICE.txt
- copied unchanged from r480282,
geronimo/server/trunk/configs/rmi-naming/NOTICE.txt
geronimo/server/trunk/configs/j2ee-1.4-specs/pom.xml
- copied, changed from r480282,
geronimo/server/trunk/configs/rmi-naming/pom.xml
geronimo/server/trunk/configs/j2ee-1.4-specs/src/
- copied from r480282, geronimo/server/trunk/configs/rmi-naming/src/
Modified:
geronimo/server/trunk/configs/client/pom.xml
geronimo/server/trunk/configs/j2ee-1.4-specs/src/plan/plan.xml
geronimo/server/trunk/configs/j2ee-server/pom.xml
geronimo/server/trunk/configs/pom.xml
geronimo/server/trunk/configs/rmi-naming/pom.xml
Modified: geronimo/server/trunk/configs/client/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/configs/client/pom.xml?view=diffrev=480329r1=480328r2=480329
==
--- geronimo/server/trunk/configs/client/pom.xml (original)
+++ geronimo/server/trunk/configs/client/pom.xml Tue Nov 28 17:54:42 2006
@@ -42,6 +42,12 @@
version${version}/version
typecar/type
/dependency
+dependency
+groupIdorg.apache.geronimo.configs/groupId
+artifactIdj2ee-1.4-specs/artifactId
+version${version}/version
+typecar/type
+/dependency
!-- ThreadPool --
dependency
@@ -120,76 +126,6 @@
version${version}/version
/dependency
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-activation_1.0.2_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-ejb_2.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-j2ee-management_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-javamail_1.3.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jaxrpc_1.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jaxr_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jms_1.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jsp_2.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jta_1.0.1B_spec/artifactId
-/dependency
-
-!--dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-qname_1.1_spec/artifactId
-/dependency--
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-saaj_1.1_spec/artifactId
-
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
+1
Thanks
Anita
--- Joe Bohn [EMAIL PROTECTED] wrote:
David,
I think this is a great idea. However, I'm curious about the need
for
the 1.4 specs in trunk. Do you envision this soon being replaced by
a
JavaEE5 specs car? Should we just rename this now to be JavaEE5 and
then update the individual specs contained within it? Just curious
on
how you were thinking that we would handle the 1.4 to EE 5 move.
I'd also like to get the Jetty6 implementation from the sandbox
included
in trunk soon. Along the same lines as above, I assume that we would
drop the -jee5 suffixes as well as the 6 from the jetty artifacts
and integrate these changes directly into the appropriate items in
trunk. Being that we now have a branch for 1.2 and trunk is building
exclusively using 1.5 (both source and target) I don't think there is
a
need to continue to maintain the Jetty 5.* in trunk. If you don't
have
any objects I'll be looking moving these changes into trunk with
those
assumptions.
Joe
[EMAIL PROTECTED] wrote:
Author: djencks
Date: Tue Nov 28 17:54:42 2006
New Revision: 480329
URL: http://svn.apache.org/viewvc?view=revrev=480329
Log:
GERONIMO-2604 create a specs car
Added:
geronimo/server/trunk/configs/j2ee-1.4-specs/
- copied from r476125,
geronimo/server/trunk/configs/rmi-naming/
geronimo/server/trunk/configs/j2ee-1.4-specs/LICENSE.txt
- copied unchanged from r480282,
geronimo/server/trunk/configs/rmi-naming/LICENSE.txt
geronimo/server/trunk/configs/j2ee-1.4-specs/NOTICE.txt
- copied unchanged from r480282,
geronimo/server/trunk/configs/rmi-naming/NOTICE.txt
geronimo/server/trunk/configs/j2ee-1.4-specs/pom.xml
- copied, changed from r480282,
geronimo/server/trunk/configs/rmi-naming/pom.xml
geronimo/server/trunk/configs/j2ee-1.4-specs/src/
- copied from r480282,
geronimo/server/trunk/configs/rmi-naming/src/
Modified:
geronimo/server/trunk/configs/client/pom.xml
geronimo/server/trunk/configs/j2ee-1.4-specs/src/plan/plan.xml
geronimo/server/trunk/configs/j2ee-server/pom.xml
geronimo/server/trunk/configs/pom.xml
geronimo/server/trunk/configs/rmi-naming/pom.xml
Modified: geronimo/server/trunk/configs/client/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/configs/client/pom.xml?view=diffrev=480329r1=480328r2=480329
==
--- geronimo/server/trunk/configs/client/pom.xml (original)
+++ geronimo/server/trunk/configs/client/pom.xml Tue Nov 28
17:54:42 2006
@@ -42,6 +42,12 @@
version${version}/version
typecar/type
/dependency
+dependency
+groupIdorg.apache.geronimo.configs/groupId
+artifactIdj2ee-1.4-specs/artifactId
+version${version}/version
+typecar/type
+/dependency
!-- ThreadPool --
dependency
@@ -120,76 +126,6 @@
version${version}/version
/dependency
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-
artifactIdgeronimo-activation_1.0.2_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-ejb_2.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-
artifactIdgeronimo-j2ee-connector_1.5_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-j2ee-jacc_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-
artifactIdgeronimo-j2ee-management_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-javamail_1.3.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jaxrpc_1.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jaxr_1.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jms_1.1_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jsp_2.0_spec/artifactId
-/dependency
-
-dependency
-groupIdorg.apache.geronimo.specs/groupId
-artifactIdgeronimo-jta_1.0.1B_spec/artifactId
-/dependency
-
-
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
I think it would be cool to be able to build mixed 1.4/JEE5 assemblies but I'm not clear on how to make that happen without creating a proliferation of modules, configs, and assemblies. So I have been working under the assumption that trunk is strictly for EE5 and that any references to J2EE 1.4 artifacts will be upgraded in place. If I understand Joe's proposal correctly then he plans to overwrite geronimo-jetty, geronimo-jetty-builder, etc to use jetty v6 instead of merging them into trunk as they appear in sandbox, which would be in line with my initial approach for tomcat v6 as well. But that seems to contradict the intent of GERONIMO-2604. Will trunk continue to support J2EE 1.4 and if so how will the src tree be organized? Best wishes, Paul On 11/29/06, Joe Bohn [EMAIL PROTECTED] wrote: David, I think this is a great idea. However, I'm curious about the need for the 1.4 specs in trunk. Do you envision this soon being replaced by a JavaEE5 specs car? Should we just rename this now to be JavaEE5 and then update the individual specs contained within it? Just curious on how you were thinking that we would handle the 1.4 to EE 5 move. I'd also like to get the Jetty6 implementation from the sandbox included in trunk soon. Along the same lines as above, I assume that we would drop the -jee5 suffixes as well as the 6 from the jetty artifacts and integrate these changes directly into the appropriate items in trunk. Being that we now have a branch for 1.2 and trunk is building exclusively using 1.5 (both source and target) I don't think there is a need to continue to maintain the Jetty 5.* in trunk. If you don't have any objects I'll be looking moving these changes into trunk with those assumptions. Joe
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
Personally I'd prefer to move forward with Java EE 5.0. I think 1.4 assemblies would be nice but we have existing branches for that area and based on user feedback that isn't an area that is really interesting to them. On Nov 29, 2006, at 12:20 PM, Paul McMahan wrote: I think it would be cool to be able to build mixed 1.4/JEE5 assemblies but I'm not clear on how to make that happen without creating a proliferation of modules, configs, and assemblies. So I have been working under the assumption that trunk is strictly for EE5 and that any references to J2EE 1.4 artifacts will be upgraded in place. If I understand Joe's proposal correctly then he plans to overwrite geronimo-jetty, geronimo-jetty-builder, etc to use jetty v6 instead of merging them into trunk as they appear in sandbox, which would be in line with my initial approach for tomcat v6 as well. But that seems to contradict the intent of GERONIMO-2604. Will trunk continue to support J2EE 1.4 and if so how will the src tree be organized? Best wishes, Paul On 11/29/06, Joe Bohn [EMAIL PROTECTED] wrote: David, I think this is a great idea. However, I'm curious about the need for the 1.4 specs in trunk. Do you envision this soon being replaced by a JavaEE5 specs car? Should we just rename this now to be JavaEE5 and then update the individual specs contained within it? Just curious on how you were thinking that we would handle the 1.4 to EE 5 move. I'd also like to get the Jetty6 implementation from the sandbox included in trunk soon. Along the same lines as above, I assume that we would drop the -jee5 suffixes as well as the 6 from the jetty artifacts and integrate these changes directly into the appropriate items in trunk. Being that we now have a branch for 1.2 and trunk is building exclusively using 1.5 (both source and target) I don't think there is a need to continue to maintain the Jetty 5.* in trunk. If you don't have any objects I'll be looking moving these changes into trunk with those assumptions. Joe Matt Hogstrom [EMAIL PROTECTED] When the clouds are full they pour the rain out on the earth; and whether a tree falls to the north, or it falls to the south, wherever the tree falls, there is lies.
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
On Nov 29, 2006, at 9:47 AM, Matt Hogstrom wrote: Personally I'd prefer to move forward with Java EE 5.0. I think 1.4 assemblies would be nice but we have existing branches for that area and based on user feedback that isn't an area that is really interesting to them. We're going to have mixed assemblies for a while until we complete all the ee 5 bits. I don't see any value in removing functionality from our server before we have an ee5 replacement. On Nov 29, 2006, at 12:20 PM, Paul McMahan wrote: I think it would be cool to be able to build mixed 1.4/JEE5 assemblies but I'm not clear on how to make that happen without creating a proliferation of modules, configs, and assemblies. So I have been working under the assumption that trunk is strictly for EE5 and that any references to J2EE 1.4 artifacts will be upgraded in place. If I understand Joe's proposal correctly then he plans to overwrite geronimo-jetty, geronimo-jetty-builder, etc to use jetty v6 instead of merging them into trunk as they appear in sandbox, which would be in line with my initial approach for tomcat v6 as well. But that seems to contradict the intent of GERONIMO-2604. Will trunk continue to support J2EE 1.4 and if so how will the src tree be organized? You can use the artifact_aliases.properties file in var/config to substitute one config for another. For instance the geronimo-jetty6- jee5 server in sandbox uses a lot of regular geronimo modules but points them to the jee5 tm instead of the j2ee1.4 tm. I've wondered if it would be a good idea to have fake nonexistent generic configs for some things and use aliases to point to a specific implementation, but I haven't come up with a strong argument for this. Best wishes, Paul On 11/29/06, Joe Bohn [EMAIL PROTECTED] wrote: David, I think this is a great idea. However, I'm curious about the need for the 1.4 specs in trunk. Do you envision this soon being replaced by a JavaEE5 specs car? Should we just rename this now to be JavaEE5 and then update the individual specs contained within it? Just curious on how you were thinking that we would handle the 1.4 to EE 5 move. Dunno, I had this sitting on my machine for a couple of weeks since before the 1.2 branch and wanted to get it out. I'd also like to get the Jetty6 implementation from the sandbox included in trunk soon. Along the same lines as above, I assume that we would drop the -jee5 suffixes as well as the 6 from the jetty artifacts and integrate these changes directly into the appropriate items in trunk. Being that we now have a branch for 1.2 and trunk is building exclusively using 1.5 (both source and target) I don't think there is a need to continue to maintain the Jetty 5.* in trunk. If you don't have any objects I'll be looking moving these changes into trunk with those assumptions. I kinda like the jetty6 rather than jetty for the modules and configs (jars and modules???) I'm not thrilled about dropping the jetty5 support until it gets in the way of progress which I don't think it has yet. For assembly names I think jee5 is more appropriate than j2ee. Does jee5 show up somewhere else? thanks david jencks Joe Matt Hogstrom [EMAIL PROTECTED] When the clouds are full they pour the rain out on the earth; and whether a tree falls to the north, or it falls to the south, wherever the tree falls, there is lies.
Re: Testsuite ready for action !
On Nov 27, 2006, at 3:45 PM, David Blevins wrote: On Nov 27, 2006, at 2:16 PM, Prasad Kashyap wrote: On 11/27/06, David Blevins [EMAIL PROTECTED] wrote: This looks like a problem with surefire. These test classes run fine in the released version of surefire, but looks like something broke in the snapshot version you're using. It's trying to call getName() on instances of junit.framework.Test and that interface does not have getName(). Seems they've decided to code in the assumption that all tests are subclasses of the TestCase abstract class. They need to unbreak surefire. I added a getName() method and published new binaries. It may help you get farther. Prasad, you getting any farther on this? Did the added getName() method do the trick? -David
[jira] Closed: (GERONIMODEVTOOLS-116) Publish command timeout values should be customizable
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-116?page=all ] Sachin Patel closed GERONIMODEVTOOLS-116. - Resolution: Fixed Publish command timeout values should be customizable - Key: GERONIMODEVTOOLS-116 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-116 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.x Reporter: Sachin Patel Assigned To: Sachin Patel Fix For: 1.x -- 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: (GERONIMODEVTOOLS-114) New ASF Source Header
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-114?page=all ] Sachin Patel closed GERONIMODEVTOOLS-114. - Fix Version/s: 1.2.0 Resolution: Fixed New ASF Source Header - Key: GERONIMODEVTOOLS-114 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-114 Project: Geronimo-Devtools Issue Type: Task Components: eclipse-plugin Affects Versions: 1.x Reporter: Jacek Laskowski Assigned To: Jacek Laskowski Priority: Blocker Fix For: 1.2.0 Update source headers as described at http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Make trunk 1.5 only!
+1 to make trunk Java5 only dain On Nov 27, 2006, at 8:18 AM, Paul McMahan wrote: On 11/27/06, anita kulshreshtha [EMAIL PROTECTED] wrote: I would like to change (at least) the target to 1.5 in the trunk. comments? +1 on changing the target to 1.5 in trunk. I think the branches should stay at 1.4 for now. Best wishes, Paul
Is this a new test framework candidate? was: Re: Error deploying EAR because of DataSource
Here's a problem that requires 2 apps (datasource and ear) to demonstrate, and manifests as a deployment failure. Does the new test framework make it easy to set up tests like this? Is there a sample? Any volunteers for this one? I have a few test apps kind of like this sitting around from fixing various bugs, some fail with deployment failures, others need to be used to demonstrate problems. It would be great to get them integrated somehow. thanks david jencks On Nov 29, 2006, at 11:00 AM, niteryder wrote: Hi, I used geronimo 1.1.1 which i downloaded with this link http://www.apache.org/dyn/closer.cgi/geronimo/1.1.1/geronimo-tomcat- j2ee-1.1.1.zip I got a deployment error on console 'Deploy New' feauture In ear file there is only one module which is the web app It has web.xml and geronimo-web.xml under WEB-INF As you see jdbc/TEST1 is linked with dependency to the console db pool TEST1 And i am sure the names are correct because it is running when you deploy only that war. then i put it in an ear and add as the only module in geronimo-application.xml but it gave error about jdbc/TEST1 then i put a copy of geronimo-web.xml under deployment folder at top level of ear and add alt-dd node to the module but again it couldn't reach then i added dependency nodes to geronimo-application.xml when I saw on Guillaume's message and it is deployed. i also checked ear and war file in it. all xml files are in their places but it cannot or doesn't check geronimo-web.xml for datasource dependencies. thanks, seckin djencks wrote: This sounds like a bug to me. Which version of geronimo are you using? Are you only accessing the datasources from the web app with the dependendencies in the geronimo-web.xml and not from any other module in the ear? Just to be clear, you get a deployment error not a runtime error? many thanks david jencks On Nov 29, 2006, at 5:29 AM, niteryder wrote: Hi Lasantha, I've already answered Guillaume's answer, it is deployed now. But i want to ask a question about the structure. First i created database pools from the console then I deployed a war project with geronimo-web.xml in it geronimo-web.xml -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; environment moduleId artifactIdtest-war/artifactId /moduleId dependencies dependency groupIdconsole.dbpool/groupId artifactIdTEST1/artifactId /dependency dependency groupIdconsole.dbpool/groupId artifactIdTEST2/artifactId /dependency /dependencies /environment context-root/test-war/context-root !-- define a reference name to the db pool-- resource-ref ref-namejdbc/TEST1/ref-name resource-linkTEST1/resource-link /resource-ref resource-ref ref-namejdbc/TEST2/ref-name resource-linkTEST2/resource-link /resource-ref /web-app Later I want to put this war project into an ear and deploy to geronimo. This time i had to prepare geronimo-application.xml but I didn't realize that i have to put dependencies again to geronimo-application.xml I was expecting it to find from geronimo-web.xml (I put it also under a folder named 'deployment' in ear and referenced it with alt-dd under module) application xmlns=http://geronimo.apache.org/xml/ns/j2ee/ application-1.1 xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; application-name=test-ear sys:environment sys:moduleId sys:groupIddefault/sys:groupId sys:artifactIdtest-ear/sys:artifactId sys:version1.0/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies/ /sys:environment module webtest-war.war/web alt-dddeployment/geronimo-web.xml/alt-dd /module /application this was giving unable to resolve resource reference jdbc/TEST1 then i changed geronimo-application.xml like below and it is deployed application xmlns=http://geronimo.apache.org/xml/ns/j2ee/ application-1.1 xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; application-name=test-ear sys:environment sys:moduleId sys:groupIddefault/sys:groupId sys:artifactIdtest-ear/sys:artifactId sys:version1.0/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies sys:dependency sys:groupIdconsole.dbpool/sys:groupId sys:artifactIdTEST1/sys:artifactId sys:version1.0/sys:version sys:typerar/sys:type /sys:dependency sys:dependency
[jira] Commented: (GERONIMO-2603) Building 1.2 if there are 2.0 artifacts in the repo results in mostly 2.0 artifacts in the server.
[ http://issues.apache.org/jira/browse/GERONIMO-2603?page=comments#action_12454416 ] Jason Dillon commented on GERONIMO-2603: I certainly hope not... if so... mvn is more annoying and lame than I had thought. When are we going to come to our senses are drop it... Building 1.2 if there are 2.0 artifacts in the repo results in mostly 2.0 artifacts in the server. -- Key: GERONIMO-2603 URL: http://issues.apache.org/jira/browse/GERONIMO-2603 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: buildsystem Affects Versions: 1.2, 2.0 Reporter: David Jencks Assigned To: David Jencks Fix For: 1.2, 2.0 PackageMojo basically uses the local maven repo to run geronimo off of. This only really works if only the versions of geronimo stuff you want are in the repo, otherwise you keep picking up later versions. Solution seems to be to make the repository adapter only let you see the transitive dependencies of the stuff in your pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Trunk is now 1.5 only!
Hi All, The build for the trunk expects source to be 1.5 and the generated code will be 1.5. Thanks, Anita Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: Testsuite ready for action !
On Nov 29, 2006, at 11:16 AM, Prasad Kashyap wrote: Hi David, I haven't seriously tried the new test jars after your added the getName(). It failed once but I didn't give it a serious thought since I could have been running 2.2-SNAPSHOT. I realized much later that there is now a 2.3-SNAPSHOT. I put it in both 2.2 and 2.3 and published new jars of each. Thanks for putting this in. I shall give it a shot soon. Cool. Let me know if there's more I can do. -David Cheers Prasad. On 11/29/06, David Blevins [EMAIL PROTECTED] wrote: On Nov 27, 2006, at 3:45 PM, David Blevins wrote: On Nov 27, 2006, at 2:16 PM, Prasad Kashyap wrote: On 11/27/06, David Blevins [EMAIL PROTECTED] wrote: This looks like a problem with surefire. These test classes run fine in the released version of surefire, but looks like something broke in the snapshot version you're using. It's trying to call getName() on instances of junit.framework.Test and that interface does not have getName(). Seems they've decided to code in the assumption that all tests are subclasses of the TestCase abstract class. They need to unbreak surefire. I added a getName() method and published new binaries. It may help you get farther. Prasad, you getting any farther on this? Did the added getName() method do the trick? -David
Re: Is this a new test framework candidate? was: Re: Error deploying EAR because of DataSource
Without going too deep into the history of this long mail, I believe the test framework does make it easy to setup tests like this where you need a running server and need to deploy multiple apps. If there is a need for more common tooling, we can definitely provide them. I am wondering if those test apps that you have to demonstrate common problems should end up in the testsupport tree. That would be a place to put it if can be used and reused by many suites. If not, the deployment-suite is another place to put it too. Cheers Prasad On 11/29/06, David Jencks [EMAIL PROTECTED] wrote: Here's a problem that requires 2 apps (datasource and ear) to demonstrate, and manifests as a deployment failure. Does the new test framework make it easy to set up tests like this? Is there a sample? Any volunteers for this one? I have a few test apps kind of like this sitting around from fixing various bugs, some fail with deployment failures, others need to be used to demonstrate problems. It would be great to get them integrated somehow. thanks david jencks On Nov 29, 2006, at 11:00 AM, niteryder wrote: Hi, I used geronimo 1.1.1 which i downloaded with this link http://www.apache.org/dyn/closer.cgi/geronimo/1.1.1/geronimo-tomcat- j2ee-1.1.1.zip I got a deployment error on console 'Deploy New' feauture In ear file there is only one module which is the web app It has web.xml and geronimo-web.xml under WEB-INF As you see jdbc/TEST1 is linked with dependency to the console db pool TEST1 And i am sure the names are correct because it is running when you deploy only that war. then i put it in an ear and add as the only module in geronimo-application.xml but it gave error about jdbc/TEST1 then i put a copy of geronimo-web.xml under deployment folder at top level of ear and add alt-dd node to the module but again it couldn't reach then i added dependency nodes to geronimo-application.xml when I saw on Guillaume's message and it is deployed. i also checked ear and war file in it. all xml files are in their places but it cannot or doesn't check geronimo-web.xml for datasource dependencies. thanks, seckin djencks wrote: This sounds like a bug to me. Which version of geronimo are you using? Are you only accessing the datasources from the web app with the dependendencies in the geronimo-web.xml and not from any other module in the ear? Just to be clear, you get a deployment error not a runtime error? many thanks david jencks On Nov 29, 2006, at 5:29 AM, niteryder wrote: Hi Lasantha, I've already answered Guillaume's answer, it is deployed now. But i want to ask a question about the structure. First i created database pools from the console then I deployed a war project with geronimo-web.xml in it geronimo-web.xml -- web-app xmlns=http://geronimo.apache.org/xml/ns/j2ee/web-1.1; environment moduleId artifactIdtest-war/artifactId /moduleId dependencies dependency groupIdconsole.dbpool/groupId artifactIdTEST1/artifactId /dependency dependency groupIdconsole.dbpool/groupId artifactIdTEST2/artifactId /dependency /dependencies /environment context-root/test-war/context-root !-- define a reference name to the db pool-- resource-ref ref-namejdbc/TEST1/ref-name resource-linkTEST1/resource-link /resource-ref resource-ref ref-namejdbc/TEST2/ref-name resource-linkTEST2/resource-link /resource-ref /web-app Later I want to put this war project into an ear and deploy to geronimo. This time i had to prepare geronimo-application.xml but I didn't realize that i have to put dependencies again to geronimo-application.xml I was expecting it to find from geronimo-web.xml (I put it also under a folder named 'deployment' in ear and referenced it with alt-dd under module) application xmlns=http://geronimo.apache.org/xml/ns/j2ee/ application-1.1 xmlns:sec=http://geronimo.apache.org/xml/ns/security-1.1; xmlns:sys=http://geronimo.apache.org/xml/ns/deployment-1.1; application-name=test-ear sys:environment sys:moduleId sys:groupIddefault/sys:groupId sys:artifactIdtest-ear/sys:artifactId sys:version1.0/sys:version sys:typecar/sys:type /sys:moduleId sys:dependencies/ /sys:environment module webtest-war.war/web alt-dddeployment/geronimo-web.xml/alt-dd /module /application this was giving unable to resolve resource reference jdbc/TEST1 then i changed geronimo-application.xml like below and it is deployed application xmlns=http://geronimo.apache.org/xml/ns/j2ee/ application-1.1
Re: svn commit: r480329 - in /geronimo/server/trunk/configs: ./ client/ j2ee-1.4-specs/ j2ee-1.4-specs/src/ j2ee-1.4-specs/src/plan/ j2ee-server/ rmi-naming/
David Jencks wrote: We're going to have mixed assemblies for a while until we complete all the ee 5 bits. I don't see any value in removing functionality from our server before we have an ee5 replacement. Is it possible to have mixed assemblies without changing components that are common? For example, this change made rmi-naming dependent upon the 1.4 specs. When we create a jee5 specs do we need to also create another jee5 rmi-naming that is dependent upon it rather than the 1.4 specs? I kinda like the jetty6 rather than jetty for the modules and configs (jars and modules???) I'm not thrilled about dropping the jetty5 support until it gets in the way of progress which I don't think it has yet. For assembly names I think jee5 is more appropriate than j2ee. Does jee5 show up somewhere else? So is jetty6 just temporary until we get a working assembly and then at that time we would drop jetty5 and rename jetty6 to simply jetty? Joe
Re: Trunk is now 1.5 only!
Thanks Anita On Nov 29, 2006, at 2:25 PM, anita kulshreshtha wrote: Hi All, The build for the trunk expects source to be 1.5 and the generated code will be 1.5. Thanks, Anita __ __ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com Matt Hogstrom [EMAIL PROTECTED] When the clouds are full they pour the rain out on the earth; and whether a tree falls to the north, or it falls to the south, wherever the tree falls, there is lies.
Re: Re: OpenEJB 2 test failures
Now I am seeing OutOfMemoryError: PermGen space: snip Running org.apache.openejb.deployment.entity.cmp.cmr.onetomany.OneToManyTest org.apache.maven.surefire.booter.SurefireExecutionException: org.apache.openejb.deployment.entity.cmp.cmr.onetomany.OneToManyTest; nested exception is java.lang.OutOfMemoryError: PermGen space; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: org.apache.openejb.deployment.entity.cmp.cmr.onetomany.OneToManyTest; nested exception is java.lang.OutOfMemoryError: PermGen space org.apache.maven.surefire.testset.TestSetFailedException: org.apache.openejb.deployment.entity.cmp.cmr.onetomany.OneToManyTest; nested exception is java.lang.OutOfMemoryError: PermGen space java.lang.OutOfMemoryError: PermGen space /snip --jason On 11/29/06, Jacek Laskowski [EMAIL PROTECTED] wrote: On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: OpenEJB 2 (2.2 or 2.3) will not build due to test failures in OpenEJB :: Builder: ... It would be really nice if someone could get this fixed... as G is stuck in the water until these pass. It should be fixed now. Give it a shot and report back. Many thanks for Dave J. for his patch that I have merely checked in. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Re: Re: OpenEJB 2 test failures
On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: Now I am seeing OutOfMemoryError: PermGen space: I saw it once or twice but then it disappeared. I wonder whether it's related to the change or something else. PermGen space is where classes are loaded to so perhaps we need to increase it for M2? -XX:MaxPermSize=128m might be of help. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
[jira] Created: (AMQ-1078) Messages consumed with the Resource Adapter are intermittently not delivered
Messages consumed with the Resource Adapter are intermittently not delivered Key: AMQ-1078 URL: https://issues.apache.org/activemq/browse/AMQ-1078 Project: ActiveMQ Issue Type: Bug Components: Broker, Connector Affects Versions: 4.0 Reporter: Hiram Chirino Assigned To: Hiram Chirino Fix For: 4.1.1, 4.2.0 The cause is that the ActiveMQSessionExecutor was starting and using it's dispatch thread instead of the Thread managed by the resource adapter. -- 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: OpenEJB 2 test failures
This seems to be a transient failure... sometimes I get the OOME, sometimes I don't :-( --jason On Nov 29, 2006, at 1:12 PM, Jacek Laskowski wrote: On 11/29/06, Jason Dillon [EMAIL PROTECTED] wrote: Now I am seeing OutOfMemoryError: PermGen space: I saw it once or twice but then it disappeared. I wonder whether it's related to the change or something else. PermGen space is where classes are loaded to so perhaps we need to increase it for M2? -XX:MaxPermSize=128m might be of help. Jacek -- Jacek Laskowski http://www.jaceklaskowski.pl
Release 1.2-beta?
First off I'd like to give everyone a hearty thank you to everyone that has (already) worked on 1.2, so THANK YOU. Now that we have branched 1.2, I think we should get the code out to our users as soon as possible, and I think this means releasing an uncertified 1.2-beta. This will allow us to work our any remaining kinks, legal issues and bugs, while the remaining TCK work is being completed. With good luck, we should be able to get out a single beta and incorporate the feedback just as the TCK work is finished. So to kick things off, I have just published our regular Wednesday snapshot build here: http://people.apache.org/dist/geronimo/unstable/1.2-r480769/ Please, review this with an eye for a Release vote later this week. If you see a problem, let us know. If you don't see any problems, let us know that also. When no release stopping problems exist, I'll create proposed final 1.2-beta assemblies and post them to my home directory for voting (hopefully later this week). Again, thank you, -dain
[STATUS] (geronimo) Wed Nov 29 23:47:48 2006
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2006-11-05 18:03:59 -0500 (Sun, 05 Nov 2006) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS Upcoming Releases: Geronimo 1.2 -- geronimo/server/trunk/ Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: Q4 2006 RELEASE SHOWSTOPPERS: Certification - Historically certification has been the most time consuming portion of a release, and there is no reason to expect it to be any different for this release. To make matters worse, the certification test suite was not run for several months while major changes were made to the build, EJB, Transaction, Connector and Servlet Session. In the last two weeks we have gotten the TCK running and using Maven 2, and have made good progress on the test suite. Additionally, the GBuild servers are back online and processing some tests. There are stability issues with GBuild but we are hopeful it will be fully running soon. Currently, the biggest concerns for the TCK are ActiveMQ 4 and Yoko. Both of these are new libraries and may take a considerable amount of effort to certify. Also, there are few people that understand these new libraries, the geronimo integrations, and the TCK. In the case of ActiveMQ, the one person that understands that can certify the code, is unavailable for the next two weeks. Fit and Finish - This is another item that has historically taken a significant amount of time to complete. A process has been started to tie up the loose ends in the software so it can be released. Dead 1.2 - There are still 26 unmerged commits the dead 1.2 branch. These commits must be merged before the 1.2 release. The current status of the dead-1.2 changes can be found at http://svn.apache.org/repos/asf/geronimo/server/trunk/all_changes.log PENDING PATCHES: GERONIMO-2485 PersistenceUnitGBean needs a NamespaceDrivenDeployer GERONIMO-1277 Change group-id to org.apache.geronimo Status: New proposal by Jason Dillon to change base the groupId to org.apache.geronimo.server GERONIMO-2015 Let's replace JKS to PKCS12 key store type - Opened Status: No active discussion GERONIMO-2409 Provide config/module aliasing ability Status: 3 +1 votes GERONIMO-2413 Add a Certification Authority (CA) portlet to Geronimo console Status: Not reviewed RELEASE HISTORY: 2006-09-18 Geronimo 1.1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
build error in branches\1.2 in configs\dojo-jetty
Build is failing with a NullPointerException. Console output given below: [INFO] Packaging module configuration: C:\G1.2\configs\dojo-jetty\target\plan\pl an.xml [INFO] [ERROR] BUILD ERROR [INFO] [INFO] java.lang.NullPointerException [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: java.lang.NullPointerExc eption at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:559) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (Defau ltLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLi fecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java :315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java :430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: java.lang.NullPointer Exception at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java :137) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPlugi nManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (Defa ultLifecycleExecutor.java:534) ... 16 more Caused by: org.apache.geronimo.common.DeploymentException: java.lang.NullPointer Exception at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:383) at org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.i nvoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:855) at org.apache.geronimo.kernel.basic.BasicKernel.invoke( BasicKernel.java: 239) at org.apache.geronimo.mavenplugins.car.PackageMojo.invokeDeployer (Packa geMojo.java:639) at org.apache.geronimo.mavenplugins.car.PackageMojo.buildPackage (Package Mojo.java:460) at org.apache.geronimo.mavenplugins.car.PackageMojo.doExecute (PackageMoj o.java:290) at org.apache.geronimo.genesis.MojoSupport.execute(MojoSupport.java :122) ... 18 more Caused by: java.lang.NullPointerException at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.createModule( JettyModuleBuilder.java:262) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder.createMod ule(AbstractWebModuleBuilder.java:154) at org.apache.geronimo.web.deployment.AbstractWebModuleBuilder$$FastClas sByCGLIB$$459e0cc.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke (FastMethod Invoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke (GBeanOperatio n.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke (GBeanInstance. java:820) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke( RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke (RawOperat ionInvoker.java:35) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept (Pro xyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4 21aae74.createModule(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.createModu le(SwitchingModuleBuilder.java:94) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClass ByCGLIB$$d0c31844.invoke(generated) at
