[jira] Commented: (AMQ-656) Update of AMQ C++ client
[ https://issues.apache.org/activemq/browse/AMQ-656?page=comments#action_36479 ] Heinrich Bernd commented on AMQ-656: Mats, thank you for that update and the patch. I have run the unittests with Broker 4.0 on Windows XP. The unittest are ok, but however there is an unknown command when closing the connection after receiving the Shutdown-message. Here is the last part of the output when running with uri: tcp://localhost:61616/trace=true . . . Send/receive a text message to a queue synchronously Sending command: cmd.id = 35, corr.id = -1, type = SESSION_INFO Received command: cmd.id = 32, corr.id = 35, type = RESPONSE Sending command: cmd.id = 36, corr.id = -1, type = CONSUMER_INFO Received command: cmd.id = 33, corr.id = 36, type = RESPONSE Sending command: cmd.id = 37, corr.id = -1, type = PRODUCER_INFO Received command: cmd.id = 34, corr.id = 37, type = RESPONSE Sending command: cmd.id = 38, corr.id = -1, type = ACTIVEMQ_TEXT_MESSAGE Received command: cmd.id = 35, corr.id = -1, type = ACTIVEMQ_MSG_DISPATCH Received command: cmd.id = 36, corr.id = 38, type = RESPONSE Sending command: cmd.id = 39, corr.id = -1, type = ACTIVEMQ_MSG_ACK Sending command: cmd.id = 40, corr.id = -1, type = REMOVE_INFO Received command: cmd.id = 37, corr.id = 40, type = RESPONSE Sending command: cmd.id = 41, corr.id = -1, type = REMOVE_INFO Received command: cmd.id = 38, corr.id = 41, type = RESPONSE Sending command: cmd.id = 42, corr.id = -1, type = REMOVE_INFO Received command: cmd.id = 39, corr.id = 42, type = RESPONSE [ OK ] Sending command: cmd.id = 43, corr.id = -1, type = REMOVE_INFO Received command: cmd.id = 40, corr.id = 43, type = RESPONSE Sending command: cmd.id = 44, corr.id = -1, type = SHUTDOWN Received command: cmd.id = 41, corr.id = -1, type = SHUTDOWN ERROR: Unknown command: #9794; Received exception = 'Unmarshal failed; unknown data structure type 204, at c:\programme\incubator-activemq-4.0\openwire-cpp-bugfix\src\main\cpp\activemq\protocol\openwire\openwireprotocol.cpp line 144' ERROR: Received a broker exception: Unmarshal failed; unknown data structure type 204, at c:\programme\incubator-activemq-4.0\openwire-cpp-bugfix\src\main\cpp\activemq\protocol\openwire\openwireprotocol.cpp line 144 Exiting read loop due to exception: Unmarshal failed; unknown data structure type 204, at c:\programme\incubator-activemq-4.0\openwire-cpp-bugfix\src\main\cpp\activemq\protocol\openwire\openwireprotocol.cpp line 144 - Where does this additional stuff come from? Thanks for your help Heinrich Update of AMQ C++ client Key: AMQ-656 URL: https://issues.apache.org/activemq/browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: README.TXT, patch_060518.zip, source_060323.zip, source_060324.zip, source_060404.zip, source_060406.zip, source_060425.zip, source_060508.zip, source_060515.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- 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-782) Support specifiying destinationOptions on the Ajax Sevlet
Support specifiying destinationOptions on the Ajax Sevlet - Key: AMQ-782 URL: https://issues.apache.org/activemq/browse/AMQ-782 Project: ActiveMQ Type: Improvement Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.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
[jira] Resolved: (AMQ-782) Support specifiying destinationOptions on the Ajax Sevlet
[ https://issues.apache.org/activemq/browse/AMQ-782?page=all ] Hiram Chirino resolved AMQ-782: --- Resolution: Fixed Support a destinationOptions servlet parameter that configures the destination options used on a destination Commited in r 418311 on trunk Support specifiying destinationOptions on the Ajax Sevlet - Key: AMQ-782 URL: https://issues.apache.org/activemq/browse/AMQ-782 Project: ActiveMQ Type: Improvement Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.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
[jira] Created: (AMQ-783) Ajax servlet could deadlock if async dispatch is in use.
Ajax servlet could deadlock if async dispatch is in use. Key: AMQ-783 URL: https://issues.apache.org/activemq/browse/AMQ-783 Project: ActiveMQ Type: Bug Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.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
[jira] Resolved: (AMQ-783) Ajax servlet could deadlock if async dispatch is in use.
[ https://issues.apache.org/activemq/browse/AMQ-783?page=all ] Hiram Chirino resolved AMQ-783: --- Resolution: Fixed If the server and client are configured to disable async dispatch, the servlet could cause a deadlock due to the way it was syncing on the WebClient Fixed in rev 418306 on trunk Ajax servlet could deadlock if async dispatch is in use. Key: AMQ-783 URL: https://issues.apache.org/activemq/browse/AMQ-783 Project: ActiveMQ Type: Bug Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.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
[jira] Created: (AMQ-785) Allow the connector to override if async dispatch is allowed.
Allow the connector to override if async dispatch is allowed. - Key: AMQ-785 URL: https://issues.apache.org/activemq/browse/AMQ-785 Project: ActiveMQ Type: New Feature Components: Connector Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.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
[jira] Resolved: (AMQ-784) If sessionAsyncDispatch==false we do not need to create a session thread.
[ https://issues.apache.org/activemq/browse/AMQ-784?page=all ] Hiram Chirino resolved AMQ-784: --- Resolution: Fixed Fixed in rev 418285 on trunk If sessionAsyncDispatch==false we do not need to create a session thread. - Key: AMQ-784 URL: https://issues.apache.org/activemq/browse/AMQ-784 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.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
[jira] Resolved: (AMQ-785) Allow the connector to override if async dispatch is allowed.
[ https://issues.apache.org/activemq/browse/AMQ-785?page=all ] Hiram Chirino resolved AMQ-785: --- Resolution: Fixed The trasport connector now had a new disableAsyncDispatch property that is false by default. fixed in revision 418162 and 418164 and in trunk Allow the connector to override if async dispatch is allowed. - Key: AMQ-785 URL: https://issues.apache.org/activemq/browse/AMQ-785 Project: ActiveMQ Type: New Feature Components: Connector Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.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
[jira] Created: (AMQ-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.
The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes. - Key: AMQ-787 URL: https://issues.apache.org/activemq/browse/AMQ-787 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assigned to: Hiram Chirino Fix For: 4.1 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED -- 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-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.
[ https://issues.apache.org/activemq/browse/AMQ-787?page=all ] Hiram Chirino updated AMQ-787: -- Version: 4.0 The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes. Key: AMQ-787 URL: https://issues.apache.org/activemq/browse/AMQ-787 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED -- 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-787) The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes.
[ https://issues.apache.org/activemq/browse/AMQ-787?page=all ] Hiram Chirino resolved AMQ-787: --- Resolution: Fixed We have noticed that on some platfoms like linux, after you close down a previously bound socket, it can take a little while before we can bind it again. We now atempt to bind in a loop up to 5 seconds before failing. fix in trunk rev 418413. The UdpTransport could potentialy fail to bind on linux.. caused the UdpTransportTest to fail sometimes. Key: AMQ-787 URL: https://issues.apache.org/activemq/browse/AMQ-787 Project: ActiveMQ Type: Bug Versions: 4.0 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 4.1 [junit] [ERROR] Test org.apache.activemq.transport.udp.UdpTransportTest FAILED -- 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-411) Add Hash Password Rewrite to File Realm
[ http://issues.apache.org/jira/browse/GERONIMO-411?page=all ]
Aaron Mulder updated GERONIMO-411:
--
Assign To: (was: Aaron Mulder)
Add Hash Password Rewrite to File Realm
---
Key: GERONIMO-411
URL: http://issues.apache.org/jira/browse/GERONIMO-411
Project: Geronimo
Type: Improvement
Components: security
Versions: 1.0-M2
Reporter: Aaron Mulder
Priority: Minor
Fix For: 1.2
It would be nice if the properties file realm could rewrite your properties
file with hashed passwords when it reads it. We would need to be able to
recognize hashed vs. unhashed entries and perhaps even different algorithms.
Perhaps it could go like this:
user1=plaintext
user2=MD5{...}
user3=SHA1{...}
Anyway, the idea is that this could be a reasonably secure alternative, but
you still wouldn't need to manually hash things to add or update entries --
just put a plain text entry in and the next time the server reads the file it
would hash it for you.
I guess we'd need to synchronize on the hash operation to avoid threading
problems if multiple apps or whatever use the same properties file, but it
shouldn't be bad if we only rewrite the file if we find any plain text
entries.
--
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-1690) Additional support for Targets passed into JSR88
[ http://issues.apache.org/jira/browse/GERONIMO-1690?page=all ] Aaron Mulder updated GERONIMO-1690: --- Assign To: (was: Aaron Mulder) Additional support for Targets passed into JSR88 Key: GERONIMO-1690 URL: http://issues.apache.org/jira/browse/GERONIMO-1690 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Sachin Patel Priority: Critical Fix For: 1.1.1 Attachments: patch.txt From an earlier dev list note... 1) The Target is currently discarded by our JSR-88 code because the Deployer GBean does not accept a Target/ConfigStore as an argument. That needs to be changed, but it should be pretty straightforward. 2) I think the Target name is the full ObjectName of the ConfigStore, which means it would be pretty heinous to type on the command line. Hopefully we can make it just the name= component of the ObjectName or something like that, but that would require some thought about what to do in case of non-unique names. 3) I don't think the Hot Deploy Dir GBean lets you specify a Target, and it probably should take that as a config param. -- 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-1367) Shutdown JAR should use deployer stored username/password
[ http://issues.apache.org/jira/browse/GERONIMO-1367?page=all ] Aaron Mulder updated GERONIMO-1367: --- Assign To: (was: Aaron Mulder) Shutdown JAR should use deployer stored username/password - Key: GERONIMO-1367 URL: http://issues.apache.org/jira/browse/GERONIMO-1367 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: startup/shutdown, usability Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List It would be nice if the shutdown script used the username and password saved by the deployer so you didn't need to specify them or re-enter them. -- 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 ]
Aaron Mulder updated GERONIMO-1037:
---
Assign To: (was: Aaron Mulder)
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
Type: Improvement
Security: public(Regular issues)
Components: console
Versions: 1.0-M5
Reporter: Vamsavardhana Reddy
Priority: Trivial
Fix For: 1.2
Attachments: fix.txt, 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] Updated: (GERONIMO-1888) Better help for bad references
[ http://issues.apache.org/jira/browse/GERONIMO-1888?page=all ] Aaron Mulder updated GERONIMO-1888: --- Assign To: (was: Aaron Mulder) Better help for bad references -- Key: GERONIMO-1888 URL: http://issues.apache.org/jira/browse/GERONIMO-1888 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: usability Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: Wish List If a GBean can't start beacuse of a missing reference, it would be great to give a more helpful error message. Like if the reference included the name Foo, print a list of all AbstractNames including name=Foo in the format you'd expect for the reference in question (slightly different for GBean-to-GBean references vs J2EE Component-to-Resource references, etc.). It would be great if it came out like this: Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. Did you mean one of these instead? * artifactIdbaz/artifactIdnameFoo/name * artifactIdother/artifactIdnameFoo/name Unable to resolve reference to artifactIdbar/artifactIdnameFoo/name. There are no components with nameFoo/name in this module or any of its dependencies. Perhaps you need to add a dependency to this module and point it to one of the following modules which has a component with nameFoo/name: * mygroup/myartifact/1.0/car * other/something/3.4/rar This is aggravated by the fact that our resource target names are no longer JMX names, so we can't tell people to look up the component in the JMX debug tool. However, it's mitigated by the fact that you have to declare dependencies explicitly and can more often just use nameFoo/name. -- 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-1173) Make DatabaseInfo load from file; separate JDBC and XA portlets
[ http://issues.apache.org/jira/browse/GERONIMO-1173?page=all ] Aaron Mulder updated GERONIMO-1173: --- Assign To: (was: Aaron Mulder) Make DatabaseInfo load from file; separate JDBC and XA portlets --- Key: GERONIMO-1173 URL: http://issues.apache.org/jira/browse/GERONIMO-1173 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: databases, console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List It would be nice if the database pool portlet loaded its information on known database drivers and URLs from a config file. That way we wouldn't need code changes to support new entries. (Note: this is different than the driver download feature, which does load parameters from a config file URL.) Once that is done, it would be nice to separate JDBC and XA drivers into separate portlets, reusing the same code but different config files to produce a separate list of supporting drivers/products. -- 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-1445) Allow deployment and use of exploded EAR modules
[ http://issues.apache.org/jira/browse/GERONIMO-1445?page=all ] Aaron Mulder updated GERONIMO-1445: --- Assign To: (was: Aaron Mulder) Allow deployment and use of exploded EAR modules Key: GERONIMO-1445 URL: http://issues.apache.org/jira/browse/GERONIMO-1445 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Environment: Windows XP Reporter: Todd Williams Priority: Critical Fix For: 1.1.1 Attachments: GeronimoTestEar.ear.zip Using the Geronimo 1.0 / Tomcat bundle, placing an exploded WAR into the deploy directory causes it to be picked up and deployed by the hot deployer as expected. However, if I wrap the exploded war with an exploded EAR, Geronimo fails to deploy with the error message : 17:00:50,282 INFO [Hot Deployer] Deploying GeronimoTestEar.ear 17:00:51,494 ERROR [Hot Deployer] Unable to deploy: Module was not a war: GeronimoTestWeb.war org.apache.geronimo.common.DeploymentException: Module was not a war: GeronimoTestWeb.war at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.addModules(EARConfigBuilder.java:544) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getEarPlan(EARConfigBuilder.java:226) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.getDeploymentPlan(EARConfigBuilder.java:122) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$1c79c440.getDeploymentPlan(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:219) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:59) at java.lang.Thread.run(Thread.java:534) I'll attached a zip that when unzipped contains the exploded hierarchy for the EAR. The application is small, but valid, as it deploys just fine when created as an archived EAR. -- 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-1869) Percent complete goes over 100% when installing configurations
[ http://issues.apache.org/jira/browse/GERONIMO-1869?page=all ] Aaron Mulder updated GERONIMO-1869: --- Assign To: (was: Aaron Mulder) Percent complete goes over 100% when installing configurations -- Key: GERONIMO-1869 URL: http://issues.apache.org/jira/browse/GERONIMO-1869 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 Looks like the UnpackArtifactTypeHandler counts the uncompressed bytes, whereas the % is based on the content size returned by the server for the download (the compressed byte count). Probably should use an InputStream between the download stream and the ZIP stream that performs the count on read(byte[],int,int) and them use that count instead of the uncompressed count. -- 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-933) Move Improve RMI naming service
[ http://issues.apache.org/jira/browse/GERONIMO-933?page=all ] Aaron Mulder updated GERONIMO-933: -- Assign To: (was: Aaron Mulder) Move Improve RMI naming service - Key: GERONIMO-933 URL: http://issues.apache.org/jira/browse/GERONIMO-933 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: naming Versions: 1.0-M4 Reporter: Aaron Mulder Fix For: 1.2 Move the RMI naming services out of the system module. Move the GBean declarations from system/client-system configuration(s) to server/client configurations. Add a listen host attribute to RMIRegistryService Make RMIRegistryService implement NetworkConnector (and thus depend on the management module) Add the RMI registry and Naming Properties to config.xml with appropriate substitution variables -- 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-1273) JMS Network Listener add dialogs should give some context information on the protocol.
[ http://issues.apache.org/jira/browse/GERONIMO-1273?page=all ] Aaron Mulder updated GERONIMO-1273: --- Assign To: (was: Aaron Mulder) JMS Network Listener add dialogs should give some context information on the protocol. -- Key: GERONIMO-1273 URL: http://issues.apache.org/jira/browse/GERONIMO-1273 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Rick McGuire Priority: Minor Fix For: Wish List Attachments: 1273-jms-listener-add-dialog.patch The JMS Network Listener add dialogs (add activieio listener, etc) should give some kind of context information rather than presenting the exact dialog for all listener types. This causes a bit of uncertainty on the user's part that the correct operation is being performed. -- 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-1884) Samples not installed properly in G1.1 - several issues
[ http://issues.apache.org/jira/browse/GERONIMO-1884?page=all ] Aaron Mulder updated GERONIMO-1884: --- Assign To: (was: Aaron Mulder) Samples not installed properly in G1.1 - several issues --- Key: GERONIMO-1884 URL: http://issues.apache.org/jira/browse/GERONIMO-1884 Project: Geronimo Type: Bug Security: public(Regular issues) Components: sample apps Versions: 1.1 Reporter: Dave Colasurdo Priority: Critical Fix For: 1.2 IT appears that the Geronimo samples have recently been removed from the default distributions and replaced with the ability to download them through the admin console. There are several issues that need to be addressed: 1) The Sample links on the Geronimo welcome page are dead.. This needs to be updated with instructions on how to download, start and access the samples.. 2) Assuming that the admin console plugins is the correct spot to download the samples.. 2a) The initial panel presented to the user is a bit confusing and is missing the ldap-demo.. 2b) After downloading the jsp or servlet examples.. The user is presented with a start examples box.. Selecting this does not work and results in an exception (attached below) 2c) start examples box does not return any status 2d) Manually starting the example via the command line also does not work. and results in an exception... Exception for 2b Geronimo Application Server started # Installed configuration # id = geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car # location = /home/davecola/geronimo-1.1-041906/assemblies/j2ee-tomcat-server/target/geronimo-1.1-SNAPSHOT/repository/geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/jsp-examples-tomcat-1.1-SNAPSHOT.car 14:12:04,651 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car?configurationName=geronimo/jsp-examples-tomcat/1.1-SNAPSHOT/car java.lang.ClassCastException at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:380) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:274) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:932) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:525) at org.apache.geronimo.kernel.basic.BasicKernel.startGBean(BasicKernel.java:376) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:143) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:267) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:235) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:210) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.kernel.config.KernelConfigurationManager$$FastClassByCGLIB$$b117102f.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java: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.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$a14ba351.loadConfiguration(generated) at
[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 ] Aaron Mulder updated GERONIMO-1451: --- Assign To: (was: Aaron Mulder) 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 Type: Bug Security: public(Regular issues) Components: ActiveMQ 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-1531) KeyStore portlet should support deletion of certificates and private keys
[ http://issues.apache.org/jira/browse/GERONIMO-1531?page=all ] Aaron Mulder updated GERONIMO-1531: --- Assign To: (was: Aaron Mulder) KeyStore portlet should support deletion of certificates and private keys - Key: GERONIMO-1531 URL: http://issues.apache.org/jira/browse/GERONIMO-1531 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console 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-1082) Deployment doesn't ensure queries defined for ejbSelect methods
[ http://issues.apache.org/jira/browse/GERONIMO-1082?page=all ] Aaron Mulder updated GERONIMO-1082: --- Assign To: (was: Aaron Mulder) Deployment doesn't ensure queries defined for ejbSelect methods --- Key: GERONIMO-1082 URL: http://issues.apache.org/jira/browse/GERONIMO-1082 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, OpenEJB Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required I deployed a CMP entity bean with an ejbSelect method, but I forgot to actually define a query for it in my ejb-jar.xml. This caused a very bizarre NullPointerException at runtime. Instead, the deployment should check that all ejbSelect methods have queries defined. (And the same for finders, if it doesn't already.) -- 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-897) Finish implementing JMS Broker portlet
[ http://issues.apache.org/jira/browse/GERONIMO-897?page=all ] Aaron Mulder updated GERONIMO-897: -- Assign To: (was: Aaron Mulder) Finish implementing JMS Broker portlet -- Key: GERONIMO-897 URL: http://issues.apache.org/jira/browse/GERONIMO-897 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.x The JMS broker portlet applications/console-standard/src/java/org/apache/geronimo/console/jmsmanager/server/JMSBrokerPortlet.java has a few missing features -- adding and removing a broker, and editing a broker if there's anything to edit. Also, when you stop and start a broker, it doesn't actually start again -- it gets hung up in the starting state. -- 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-2143) ENCConfigBuilder blocks outside callers
[ http://issues.apache.org/jira/browse/GERONIMO-2143?page=all ] Aaron Mulder updated GERONIMO-2143: --- Assign To: (was: Aaron Mulder) ENCConfigBuilder blocks outside callers --- Key: GERONIMO-2143 URL: http://issues.apache.org/jira/browse/GERONIMO-2143 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, naming Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.1 ENCConfigBuilder makes strategic methods private and some methods require an EAR context, module ID, JNDI builder, etc. that are only relevant for EAR callers. For plugins, etc. that want to create EJB/Resource/Service references, they need a lot of copy and paste and refactoring of code that should be reusable. The ENCConfigBuilder should be fixed to be equally useful to internal (J2EE) and external (non-J2EE) callers. -- 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-1865) Add ability to restart and reload configurations
[ http://issues.apache.org/jira/browse/GERONIMO-1865?page=all ] Aaron Mulder updated GERONIMO-1865: --- Assign To: (was: Aaron Mulder) Add ability to restart and reload configurations Key: GERONIMO-1865 URL: http://issues.apache.org/jira/browse/GERONIMO-1865 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: kernel, console Versions: 1.1 Reporter: Dain Sundstrom Priority: Critical Fix For: 1.1.1 Add the ability to restart and reload configurations. The core feature has been added to the ConfigurationManager, and now we just need to expose it via the CLI and web console. -- 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-1079) Better error for missing primkey-field
[ http://issues.apache.org/jira/browse/GERONIMO-1079?page=all ] Aaron Mulder updated GERONIMO-1079: --- Assign To: (was: Aaron Mulder) Better error for missing primkey-field -- Key: GERONIMO-1079 URL: http://issues.apache.org/jira/browse/GERONIMO-1079 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, OpenEJB Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required I forgot the primkey-field for my CMP entity, and I got this: Error: Unable to distribute LoadMagus.ear: Could not deploy module caused by EJB [TestRunMachine] is misconfigured: could not find CMP fields for following pk fields: [TYPE] [MAX_VALUE] [MIN_VALUE] Now, I don't know where it got TYPE, MAX_VALUE, and MIN_VALUE from -- those are not fields on my EJB or the table or anything. I did have a prim-key-class set to java.lang.Integer, so perhaps it picked up the static fields on java.lang.Integer (if so why? I wouldn't have thought statics were relevant). It would be better if the error said missing primkey-field or prim-key-class does not have properties matching CMP field names or something like that. -- 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-1926) Changes to navigation break remote clients
[ http://issues.apache.org/jira/browse/GERONIMO-1926?page=all ]
Aaron Mulder updated GERONIMO-1926:
---
Assign To: (was: Aaron Mulder)
Changes to navigation break remote clients
--
Key: GERONIMO-1926
URL: http://issues.apache.org/jira/browse/GERONIMO-1926
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: core
Versions: 1.1
Reporter: Aaron Mulder
Priority: Critical
Fix For: 1.2
Attachments: peek-remote.jar, peek.jar
From an e-mail:
I have created a simple program that calls J2EEDomain.getServerInstances() on
J2EEDomain obtained from remote kernel. Detatch the two jars to bin
directory and run the program using the cmd java -jar peek.jar. Here is
the code in the main() method.
public static void main(String[] args) throws Exception {
String host = localhost;
String username = system;
String password = manager;
for(int i = 0; i args.length-1; ++i) {
if(--username.equalsIgnoreCase(args[i])) username = args[i+1];
if(--host.equalsIgnoreCase(args[i])) host = args[i+1];
if(--password.equalsIgnoreCase(args[i])) password = args[i+1];
}
System.out.println(Using host=+host+, username=+username+,
password=+password);
KernelManagementHelper mgr =
KernelManagementHelper.getRemoteKernelManager(host, username, password);
System.out.println(KernelManagementHelper = +mgr);
J2EEDomain domain = mgr.getDomains()[0];
System.out.println(J2EEDomain = +domain);
J2EEServer[] j2eeServers = domain.getServerInstances();
System.out.println(J2EEServer = +j2eeServers[0]);
}
--
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-817) deploy-jsr88 module has dependency on openejb
[ http://issues.apache.org/jira/browse/GERONIMO-817?page=all ] Aaron Mulder updated GERONIMO-817: -- Assign To: (was: Aaron Mulder) deploy-jsr88 module has dependency on openejb - Key: GERONIMO-817 URL: http://issues.apache.org/jira/browse/GERONIMO-817 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0-M4, 1.0-M5 Reporter: David Jencks Fix For: 1.2 Attachments: nobuilderdependencies Apparently in an attempt to support dconfig beans, the deploy-jsr88 module grew dependencies on several builder modules including openejb builder. This is a totally non-extensible archtecture and prevents building geronimo and openejb in any semblance of a reasonable order. I think that some kind of registration scheme might be plausible but the current hard-coded dependencies to specific builder implementations are not acceptable. -- 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-2142) EJB Refs to EJB in parent module often fail
[ http://issues.apache.org/jira/browse/GERONIMO-2142?page=all ] Aaron Mulder updated GERONIMO-2142: --- Assign To: (was: Aaron Mulder) EJB Refs to EJB in parent module often fail --- Key: GERONIMO-2142 URL: http://issues.apache.org/jira/browse/GERONIMO-2142 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, deployment Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.1 In OpenEJBReferenceBuilder: createEJBLocalRef and createEJBRemoteRef accept a targetConfigId argument. Then they often call getMatch or getImplicitMatch and don't use the targetConfigId. As a result, the current module's ID is always used as the targetConfigId: context.findGBeans(new AbstractNameQuery(context.getId(), ... This means that the query will never match EJBs in a parent of the current configuration. It should be changed to use the targetConfigId instead of the current module's ID. This does not come up if a pattern element is used in the mapping, though that mapping strategy runs into a different 1.1 bug (ClassCastException on org.openejb.proxy.ProxyInfo) -- 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-1023) Web DD option to disable directory listings
[ http://issues.apache.org/jira/browse/GERONIMO-1023?page=all ] Aaron Mulder updated GERONIMO-1023: --- Assign To: (was: Aaron Mulder) Web DD option to disable directory listings --- Key: GERONIMO-1023 URL: http://issues.apache.org/jira/browse/GERONIMO-1023 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: web Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Minor Fix For: 1.x It would be nice if there was a simple web deployment plan option that would disable directory listings. For now, you can just use a welcome file list, but still, that means you need a welcome file (for example) in your images directory, in your CSS directory, in your JS directory, etc. -- 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-1056) Redeploy database pool, app blows up (in CMP finder/prefetch code)
[ http://issues.apache.org/jira/browse/GERONIMO-1056?page=all ] Aaron Mulder updated GERONIMO-1056: --- Assign To: (was: Aaron Mulder) Redeploy database pool, app blows up (in CMP finder/prefetch code) -- Key: GERONIMO-1056 URL: http://issues.apache.org/jira/browse/GERONIMO-1056 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, connector, naming Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: 1.x Using Head (10/10). I redeployed a database pool, and the app that uses in then blew up with this: Caused by: java.lang.NullPointerException at org.tranql.sql.DataSourceDelegate.getConnection(DataSourceDelegate.java:36) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:61) at org.tranql.sql.prefetch.PrefetchGroupHandler.execute(PrefetchGroupHandler.java:160) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:95) at org.openejb.entity.cmp.CollectionValuedFinder.execute(CollectionValuedFinder.java:81) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.java:72) at org.openejb.security.EJBSecurityInterceptor.invoke(EJBSecurityInterceptor.java:104) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(ComponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingInterceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheInterceptor.java:90) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:119) ... 55 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] Updated: (GERONIMO-1642) Deployment plan namespace validation
[ http://issues.apache.org/jira/browse/GERONIMO-1642?page=all ] Aaron Mulder updated GERONIMO-1642: --- Assign To: (was: Aaron Mulder) Deployment plan namespace validation Key: GERONIMO-1642 URL: http://issues.apache.org/jira/browse/GERONIMO-1642 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: web, deployment, OpenEJB Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 When you deploy with a geronimo deployment plan packaged in the archive, but it has the wrong namespace, the file is ignored. If anything, you get a message saying the plan is required, or that the archive is not a WAR/JAR/etc. We should have special detection for geronimo-application.xml, geronimo-ra.xml, geronimo-web.xml, and openejb-jar.xml that notices if the file is present but has the wrong namespace, and prints a suggestive WARN or ERROR message to the console. Probably for the application.xml, web.xml, ra.xml, and ejb-jar.xml too. People have asked for help on the mailing list several times recently when they had this (bad namespace) problem. -- 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-2146) GBeanOverride ignores reference name when saving if artifact is not set
[ http://issues.apache.org/jira/browse/GERONIMO-2146?page=all ] Aaron Mulder updated GERONIMO-2146: --- Assign To: (was: Aaron Mulder) GBeanOverride ignores reference name when saving if artifact is not set --- Key: GERONIMO-2146 URL: http://issues.apache.org/jira/browse/GERONIMO-2146 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.1 In writeXml the writing of name and module should be outside the if(artifact != null) block -- 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-1585) Web app security on /* causes deployment exception
[ http://issues.apache.org/jira/browse/GERONIMO-1585?page=all ] Aaron Mulder updated GERONIMO-1585: --- Assign To: (was: Aaron Mulder) Web app security on /* causes deployment exception -- Key: GERONIMO-1585 URL: http://issues.apache.org/jira/browse/GERONIMO-1585 Project: Geronimo Type: Bug Security: public(Regular issues) Components: web, security Versions: 1.1 Environment: Geronimo 1.0 with Jetty and tomcat Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 Attachments: security.patch Deploying a web app with the following security block causes a deployment error: security-constraint web-resource-collection web-resource-nameAll Pages/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameUser/role-name /auth-constraint /security-constraint Note this is essentially right out of the spec (see SRV.12.8.2 in the Servlet 2.4 spec). The error is: org.apache.geronimo.common.DeploymentException: Unable to initialize webapp GBean at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:842) ... Caused by: java.lang.IllegalArgumentException: Qualifier patterns in the URLPatternSpec cannot match the first URLPattern at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:54) at javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:54) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildSpecSecurityConfig(JettyModuleBuilder.java:1215) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:821) ... 70 more Changing the url-pattern to / fixes the problem, but it seems to me that /* ought to work too. -- 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-1857) Prompt before stopping a stopping a cofiguration that outher configurations depend on
[ http://issues.apache.org/jira/browse/GERONIMO-1857?page=all ] Aaron Mulder updated GERONIMO-1857: --- Assign To: (was: Aaron Mulder) Prompt before stopping a stopping a cofiguration that outher configurations depend on - Key: GERONIMO-1857 URL: http://issues.apache.org/jira/browse/GERONIMO-1857 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Dain Sundstrom Fix For: 1.2 The cli and webconsole should prompt before stopping any configuration that other configurations depend on. The cli should provide a --force flag to bypass this prompt. -- 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-1580) Better error message for missing WSDL file for EJB web service
[ http://issues.apache.org/jira/browse/GERONIMO-1580?page=all ] Aaron Mulder updated GERONIMO-1580: --- Assign To: (was: Aaron Mulder) Better error message for missing WSDL file for EJB web service -- Key: GERONIMO-1580 URL: http://issues.apache.org/jira/browse/GERONIMO-1580 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 If your webservices.xml file for a stateless session bean web service refers to a WSDL file that is not there, the error produced is java.lang.RuntimeException: Could not open stream to wsdl file It would be better if it produced a DeploymentException with a message something like: webservices.xml file for EJB JAR points to non-existant WSDL file 'META-INF/foo.wsdl' for service 'MyEJBWebService' The stack trace is 10:56:24,259 ERROR [Deployer] Deployment failed due to java.lang.RuntimeException: Could not open stream to wsdl file at org.apache.geronimo.axis.builder.SchemaInfoBuilder$JarWSDLLocator.getBaseInputSource(SchemaInfoBuilder.java:652) at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.readWsdl(SchemaInfoBuilder.java:555) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:141) at org.apache.geronimo.axis.builder.SchemaInfoBuilder.init(SchemaInfoBuilder.java:125) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:312) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at
[jira] Updated: (GERONIMO-2145) NPE in Maven1Repository
[ http://issues.apache.org/jira/browse/GERONIMO-2145?page=all ] Aaron Mulder updated GERONIMO-2145: --- Assign To: (was: Aaron Mulder) NPE in Maven1Repository --- Key: GERONIMO-2145 URL: http://issues.apache.org/jira/browse/GERONIMO-2145 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1.1 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] Updated: (GERONIMO-1704) Console security realm doesn't let you pick a JAR
[ http://issues.apache.org/jira/browse/GERONIMO-1704?page=all ] Aaron Mulder updated GERONIMO-1704: --- Assign To: (was: Aaron Mulder) Console security realm doesn't let you pick a JAR - Key: GERONIMO-1704 URL: http://issues.apache.org/jira/browse/GERONIMO-1704 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, security Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List It's not possible to use the console to deploy a custom login module because we don't let you specify a JAR that holds the login module and principal classes! -- 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-1967) /remote-deploy url link throws Error 404.
[ http://issues.apache.org/jira/browse/GERONIMO-1967?page=all ] Aaron Mulder updated GERONIMO-1967: --- Assign To: (was: Aaron Mulder) /remote-deploy url link throws Error 404. - Key: GERONIMO-1967 URL: http://issues.apache.org/jira/browse/GERONIMO-1967 Project: Geronimo Type: Bug Security: public(Regular issues) Components: usability Versions: 1.1 Reporter: Prasad Kashyap Priority: Critical Fix For: 1.1.1 Attachments: logo_head_570x86.gif, remote-deploy.patch The following page on the console (http://localhost:8080/console/portal/apps/apps_war) lists all the WARs with their URL links. Accessing the /remote-deploy link throws an Error 404. Though this app is used by the CLI tool to deploy apps remotely, we should handle this gracefully instead of showing it as an error. Please review and apply the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2103) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR
[ http://issues.apache.org/jira/browse/GERONIMO-2103?page=all ] Aaron Mulder updated GERONIMO-2103: --- Assign To: (was: Aaron Mulder) Console config declares dependency on Jetty/Tomcat JAR instead of Jetty/Tomcat CAR -- Key: GERONIMO-2103 URL: http://issues.apache.org/jira/browse/GERONIMO-2103 Project: Geronimo Type: Bug Security: public(Regular issues) Components: buildsystem, console Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1592) Add NamedUPCredentialLoginModule to Console Realm Wizard
[ http://issues.apache.org/jira/browse/GERONIMO-1592?page=all ] Aaron Mulder updated GERONIMO-1592: --- Assign To: (was: Aaron Mulder) Add NamedUPCredentialLoginModule to Console Realm Wizard Key: GERONIMO-1592 URL: http://issues.apache.org/jira/browse/GERONIMO-1592 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console, security, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List The console currently has a checkbox to store credentials (using the GeronimoPasswordCredentialLoginModule). It should likewise have a checkbox and text field to store credentials using the NamedUPCredentialLoginModule (where the text field specifies the name to save under). -- 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-866) Management API: EJB Container Support
[ http://issues.apache.org/jira/browse/GERONIMO-866?page=all ] Aaron Mulder updated GERONIMO-866: -- Assign To: (was: Aaron Mulder) Management API: EJB Container Support - Key: GERONIMO-866 URL: http://issues.apache.org/jira/browse/GERONIMO-866 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: management, OpenEJB Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.x Add interfaces for EJBContainer / EJBConnector like we have for WebContainer/WebConnector. Should allow you to add protocols and manipulate ports and adjust thread pools and so on. Implement these interfaces in the OpenEJB GBeans. -- 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-1695) CORBA for EJB with Local interface only causes NPE
[ http://issues.apache.org/jira/browse/GERONIMO-1695?page=all ] Aaron Mulder updated GERONIMO-1695: --- Assign To: (was: Aaron Mulder) CORBA for EJB with Local interface only causes NPE -- Key: GERONIMO-1695 URL: http://issues.apache.org/jira/browse/GERONIMO-1695 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2, 1.1.1 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] Updated: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=all ] Aaron Mulder updated GERONIMO-1887: --- Assign To: (was: Aaron Mulder) Remove unneeded jars from console WEB-INF/lib directories - Key: GERONIMO-1887 URL: http://issues.apache.org/jira/browse/GERONIMO-1887 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.x Reporter: Paul McMahan Priority: Minor Fix For: 1.1.1 Several of the jars in the console's WEB-INF/lib directories are unneeded - both copies of jasper-compiler-5.5.12.jar (400K each) - both copies of jasper-runtime-5.5.12.jar (80K each) - the copy of castor-0.9.5.3.jar in console-standard (1.7M) Removing these jars will decrease the server footprint and binary image download size. -- 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-1383) Connector DConfigBeans don't load correctly from XML
[ http://issues.apache.org/jira/browse/GERONIMO-1383?page=all ] Aaron Mulder updated GERONIMO-1383: --- Assign To: (was: Aaron Mulder) Connector DConfigBeans don't load correctly from XML Key: GERONIMO-1383 URL: http://issues.apache.org/jira/browse/GERONIMO-1383 Project: Geronimo Type: Bug Security: public(Regular issues) Components: connector, deployment Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 When you load an existing geronimo-ra.xml plan using the connector DConfigBeans, most of the incoming data seems to be lost (e.g. there are no connection definition instances). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1285) Deployer does not list all modules that have been stopped
[ http://issues.apache.org/jira/browse/GERONIMO-1285?page=all ] Aaron Mulder updated GERONIMO-1285: --- Assign To: (was: Aaron Mulder) Deployer does not list all modules that have been stopped - Key: GERONIMO-1285 URL: http://issues.apache.org/jira/browse/GERONIMO-1285 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required When you, for example, stop the tomcat configuration, all the web apps deployed to Tomcat are stopped too. However, the deployer does not let you know this. It should list all modules that were stopped, just like it does when starting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1176) Bad resource reference is not caught at deployment time
[ http://issues.apache.org/jira/browse/GERONIMO-1176?page=all ] Aaron Mulder updated GERONIMO-1176: --- Assign To: (was: Aaron Mulder) Bad resource reference is not caught at deployment time - Key: GERONIMO-1176 URL: http://issues.apache.org/jira/browse/GERONIMO-1176 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB Versions: 1.0-M5 Environment: Windows XP, Sun JDK1.4.2_09 Reporter: Manu T George Priority: Critical Fix For: 1.2 In openejb-jar.xml file for a cmp entity bean if the cmp-connection-factory element contains a name tag instead of a resource-link tag a null pointer exception is thrown instead of an error message shown during deployment. This is a problem with both the deployer and openEJB I guess. cmp-connection-factory nameSystemDatasource/name /cmp-connection-factory Stack trace Exception in thread main java.rmi.RemoteException: The bean encountered a non- application exception. method; nested exception is: java.lang.NullPointerException at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.ja va:303) at org.openejb.server.ejbd.EjbRequestHandler.doEjbHome_FIND(EjbRequestHa ndler.java:394) at org.openejb.server.ejbd.EjbRequestHandler.processRequest(EjbRequestHa ndler.java:209) at org.openejb.server.ejbd.EjbDaemon.service(EjbDaemon.java:150) at org.openejb.server.ejbd.EjbServer.service(EjbServer.java:87) at org.openejb.server.ejbd.EjbServer$$FastClassByCGLIB$$d379d2ff.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance. java:760) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:5 7) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperat ionInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(Pro xyMethodInterceptor.java:96) at org.activeio.xnet.ServerService$$EnhancerByCGLIB$$461aa4d2.service(g enerated) at org.activeio.xnet.ServicePool$2.run(ServicePool.java:67) at org.activeio.xnet.ServicePool$3.run(ServicePool.java:90) at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(Th readPool.java:138) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown So urce) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NullPointerException at org.tranql.sql.DataSourceDelegate.getConnection(DataSourceDelegate.ja va:36) at org.tranql.sql.jdbc.JDBCQueryCommand.execute(JDBCQueryCommand.java:61 ) at org.openejb.entity.cmp.CMPFinder.execute(CMPFinder.java:98) at org.openejb.entity.cmp.CollectionValuedFinder.execute(CollectionValue dFinder.java:81) at org.openejb.dispatch.DispatchInterceptor.invoke(DispatchInterceptor.j ava:72) at org.apache.geronimo.naming.java.ComponentContextInterceptor.invoke(Co mponentContextInterceptor.java:56) at org.openejb.ConnectionTrackingInterceptor.invoke(ConnectionTrackingIn terceptor.java:81) at org.openejb.entity.EntityInstanceInterceptor.invoke(EntityInstanceInt erceptor.java:136) at org.openejb.entity.cmp.InTxCacheInterceptor.invoke(InTxCacheIntercept or.java:84) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPo licy.java:140) at org.openejb.transaction.TransactionContextInterceptor.invoke(Transact ionContextInterceptor.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionIntercep tor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.server.ejbd.EjbRequestHandler.invoke(EjbRequestHandler.ja va:297) ... 18 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] Updated: (GERONIMO-1680) MDB without activation-config in openejb-jar.xml silently fails
[ http://issues.apache.org/jira/browse/GERONIMO-1680?page=all ] Aaron Mulder updated GERONIMO-1680: --- Assign To: (was: Aaron Mulder) MDB without activation-config in openejb-jar.xml silently fails --- Key: GERONIMO-1680 URL: http://issues.apache.org/jira/browse/GERONIMO-1680 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, ActiveMQ Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 I created a queue and sent a couple messages to it. Then I created an MDB with a message-destination-type of javax.jms.Queue and a message-destination-link pointing to a message-destination with the name of the Queue. It seems like this is enough information to point the MDB to that queue, assuming that openejb-jar.xml lists the resource adapter for the MDB. This deployed successfully, but no messages were received by the MDB. Adding an activation-config section to openejb-jar.xml fixed the problem -- the pending messages were received during deployment. One of these two issues strikes me as a bug: 1) Why wasn't the MDB hooked up to the queue without needing an activation-config block in openejb-jar.xml? 2) If that's an error, why is activation-config optional for an MDB in openejb-jar.xml and why didn't it cause a deployment error? In any case, I think deployment should always fail if an MDB is not actually hooked up to a destination. -- 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-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Aaron Mulder updated GERONIMO-1703: --- Assign To: (was: Aaron Mulder) ServerInfo.getBaseDirectory() returns null -- Key: GERONIMO-1703 URL: http://issues.apache.org/jira/browse/GERONIMO-1703 Project: Geronimo Type: Bug Security: public(Regular issues) Components: startup/shutdown Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat Reporter: Vamsavardhana Reddy 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
[jira] Updated: (GERONIMO-1384) Web app with no Geronimo plan makes all secure pages insecure
[ http://issues.apache.org/jira/browse/GERONIMO-1384?page=all ] Aaron Mulder updated GERONIMO-1384: --- Assign To: (was: Aaron Mulder) Web app with no Geronimo plan makes all secure pages insecure - Key: GERONIMO-1384 URL: http://issues.apache.org/jira/browse/GERONIMO-1384 Project: Geronimo Type: Bug Security: public(Regular issues) Components: security, web Versions: 1.0-M5 Reporter: Aaron Mulder Priority: Trivial Fix For: 1.1.1 Attachments: security-reject.patch If you deploy a web application with certain pages/URLs protected by a login, but you don't include a Geronimo deployment plan, all those pages/URLs are unprotected. To replicate: Deploy this with no plan: http://cvs.apache.org/repository/geronimo/wars/geronimo-ldap-demo-1.0-SNAPSHOT.war and then visit http://localhost:8080/geronimo-ldap-demo-1.0-SNAPSHOT and click the links to secure and forbidden. Both links work, with no login prompt. Instead, you should get a login prompt and (since no realm was configured) all logins should fail. The web.xml in this case contains: security-constraint web-resource-collection web-resource-nameAdmin Role/web-resource-name url-pattern/protect/*/url-pattern /web-resource-collection auth-constraint role-namecontent-administrator/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameNo Access/web-resource-name url-pattern/forbidden/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint login-config auth-methodFORM/auth-method realm-nameMYREALM/realm-name form-login-config form-login-page/auth/logon.html?param=test/form-login-page form-error-page/auth/logonError.html?param=test/form-error-page /form-login-config /login-config security-role role-namecontent-administrator/role-name /security-role -- 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-1922) Plugin Export should check for shared libs
[ http://issues.apache.org/jira/browse/GERONIMO-1922?page=all ] Aaron Mulder updated GERONIMO-1922: --- Assign To: (was: Aaron Mulder) Plugin Export should check for shared libs -- Key: GERONIMO-1922 URL: http://issues.apache.org/jira/browse/GERONIMO-1922 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.1, 1.1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 The export process should check configation.findGBeans(new AbstractNameQuery(SharedLib.class.getName()) -- 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-1879) Make ConfigurationManager take a list of configurations/versions to reload
[ http://issues.apache.org/jira/browse/GERONIMO-1879?page=all ] Aaron Mulder updated GERONIMO-1879: --- Assign To: (was: Aaron Mulder) Make ConfigurationManager take a list of configurations/versions to reload -- Key: GERONIMO-1879 URL: http://issues.apache.org/jira/browse/GERONIMO-1879 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List Currently each call to ConfigurationManager.reload provides only one artifact/version per call. This may make it challenging to perform a large upgrade, where it may not be easy to find an order to apply all the changes in. It would be nice to be able to pass e.g. a Map of artifacts to versions to cause a bunch of things to be updated to new versions all at once. -- 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-1596) Repeated interface in JMS connection factory plan causes deployment failure
[ http://issues.apache.org/jira/browse/GERONIMO-1596?page=all ] Aaron Mulder updated GERONIMO-1596: --- Assign To: (was: Aaron Mulder) Repeated interface in JMS connection factory plan causes deployment failure --- Key: GERONIMO-1596 URL: http://issues.apache.org/jira/browse/GERONIMO-1596 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, ActiveMQ Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 If you deploy a connection factory with an implemented-interface that has the same value as the connectionfactory-interface, then there are explosions during deployment. However, the deployment is not actually rejected, it just ends up deploying something that doesn't work. The cause appears to be generating code that implements the same interface twice -- we should either silently ignore one of them (preferable) or reject the deployment alltogether (workable, I guess). The plan that caused this contained: ... outbound-resourceadapter connection-definition connectionfactory-interface javax.jms.TopicConnectionFactory /connectionfactory-interface connectiondefinition-instance namejms/MyTopicConnectionFactory/name implemented-interface javax.jms.TopicConnectionFactory /implemented-interface ... And the error is: 23:39:59,747 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2EEServer=geronimo,JCAResource=MyTopicConnectionFactory,j2eeType=JCAManagedConnectionFactory,name=jms/MyTopicConnectionFactory net.sf.cglib.core.CodeGenerationException: java.lang.reflect.InvocationTargetException--null at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304) at org.apache.geronimo.connector.outbound.ManagedConnectionFactoryWrapper.doStart(ManagedConnectionFactoryWrapper.java:215) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:173) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl.start(ConfigurationManagerImpl.java:142) at org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at
[jira] Updated: (GERONIMO-1930) Make security real types into GBeans so they can be added in new/updated configurations
[ http://issues.apache.org/jira/browse/GERONIMO-1930?page=all ] Aaron Mulder updated GERONIMO-1930: --- Assign To: (was: Aaron Mulder) Make security real types into GBeans so they can be added in new/updated configurations --- Key: GERONIMO-1930 URL: http://issues.apache.org/jira/browse/GERONIMO-1930 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: security, console Versions: 1.1 Reporter: Aaron Mulder Fix For: Wish List -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1892) Make JMS Provider Properties a GBean
[ http://issues.apache.org/jira/browse/GERONIMO-1892?page=all ] Aaron Mulder updated GERONIMO-1892: --- Assign To: (was: Aaron Mulder) Make JMS Provider Properties a GBean Key: GERONIMO-1892 URL: http://issues.apache.org/jira/browse/GERONIMO-1892 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Priority: Minor Fix For: Wish List It would be great to declare an interface and GBean for the JMS provider properties. Then the portlet could look up all matching GBeans by interface. So, if you want to add another JMS provider, you just include that GBean in your JMS server module and it's immediately available in the console. -- 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-1641) Using default Console Realm, when delete a user it will not be removed from the groups
[ http://issues.apache.org/jira/browse/GERONIMO-1641?page=all ] Aaron Mulder updated GERONIMO-1641: --- Assign To: (was: Aaron Mulder) Using default Console Realm, when delete a user it will not be removed from the groups -- Key: GERONIMO-1641 URL: http://issues.apache.org/jira/browse/GERONIMO-1641 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Hernan Cunico Fix For: 1.1.1 Attachments: G-1641.patch When using the default console realm and you add a user to a group, if that user is deleted later it will not be removed from the group it was added. The Geronimo console shows that the user has been removed but the groups.properties still shows the user. -- 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-1368) Remote deployment probably doesn't handle exploded JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1368?page=all ] Aaron Mulder updated GERONIMO-1368: --- Assign To: (was: Aaron Mulder) Remote deployment probably doesn't handle exploded JARs --- Key: GERONIMO-1368 URL: http://issues.apache.org/jira/browse/GERONIMO-1368 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: Wish List If you pass an exploded JAR to the deploy tool when running on a remote machine, it should zip it on the fly when uploading to the server. -- 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-960) NPE related to EJB while deploying EAR
[ http://issues.apache.org/jira/browse/GERONIMO-960?page=all ] Aaron Mulder updated GERONIMO-960: -- Assign To: (was: Aaron Mulder) NPE related to EJB while deploying EAR -- Key: GERONIMO-960 URL: http://issues.apache.org/jira/browse/GERONIMO-960 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment, OpenEJB Reporter: Aaron Mulder Priority: Critical Fix For: 1.x Reported on the user list: Unable to distribute Myapp.ear : Unable to initialize EJBContainer GBean: ejbName [MyAddressBean] caused by null i have the entry in openejb-jar.xml for this bean it is as below ejb-local-ref ref-nameMyAddress/ref-name nameMyAddressBean/name /ejb-local-ref The XML looks wrong but that shouldn't throw an NPE... Whatever the issue is we should try to avoid the NPE. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1579) NPE while deploying EJB as Web Service
[ http://issues.apache.org/jira/browse/GERONIMO-1579?page=all ] Aaron Mulder updated GERONIMO-1579: --- Assign To: (was: Aaron Mulder) NPE while deploying EJB as Web Service -- Key: GERONIMO-1579 URL: http://issues.apache.org/jira/browse/GERONIMO-1579 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 Surely caused by a coding/configuration error, but it would really be preferable to produce a better error message. 10:23:37,328 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.openejb.deployment.SessionBuilder.addWSContainerGBean(SessionBuilder.java:208) at org.openejb.deployment.SessionBuilder.buildBeans(SessionBuilder.java:187) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:527) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.KernelGBean.invoke(KernelGBean.java:125) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor265.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31)
[jira] Updated: (GERONIMO-348) Invalid module path or references in plan should result in failed deployment or warning
[ http://issues.apache.org/jira/browse/GERONIMO-348?page=all ] Aaron Mulder updated GERONIMO-348: -- Assign To: (was: Aaron Mulder) Invalid module path or references in plan should result in failed deployment or warning --- Key: GERONIMO-348 URL: http://issues.apache.org/jira/browse/GERONIMO-348 Project: Geronimo Type: Bug Components: deployment Reporter: Jeremy Boynes Priority: Critical Fix For: 1.2 If an EAR deployment plan contains a entry for a module but the path does not match that of a module in the application.xml then an error or warning should be issued at deployment time. A likely reason for this is that a developer copied the plan from another but forgot to change the uri entry for the submodule; or it could just be a simple typo. In either way, the plan won't match the intended module from the application.xml resulting in erroroneous behaviour. (added) In addition, elements in a plan that do not correspond to elements in the deployment descriptor should result in a warning or error. Examples would be an ejb listed in the openejb plan that does not correspond to an ejb in the ejb-jar.xml, or a resource-ref in the ejb that does not correspond to a resource-ref in the ejb-jar.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] Updated: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Aaron Mulder updated GERONIMO-1524: --- Assign To: (was: Aaron Mulder) DB pool portlet should let you select multiple driver JARs -- Key: GERONIMO-1524 URL: http://issues.apache.org/jira/browse/GERONIMO-1524 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 Attachments: GERONIMO-1524.patch Currently the database pool portlet can handle a driver requiring multiple JARs, but the UI doesn't actually let you select more than one. Some drivers known to need more include DB/2 and MS SQL Server. Perhaps the screen should have a checkbox to reveal another 2 driver selection pick lists (the security realm portlet advanced config screen has an example of revealing extra fields if you check a particular checkbox). -- 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-1586) In naming schema, make uri optional in portType
[ http://issues.apache.org/jira/browse/GERONIMO-1586?page=all ] Aaron Mulder updated GERONIMO-1586: --- Assign To: (was: Aaron Mulder) In naming schema, make uri optional in portType --- Key: GERONIMO-1586 URL: http://issues.apache.org/jira/browse/GERONIMO-1586 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: naming, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Minor Fix For: 1.1.1 Currently the portType requires uri. If you only want to add security settings to the web service, and are happy to default to the URI in the WSDL, you should not need to repeat the URI here. So technically, you should need either the uri or credentials-name or both, but I think it's easier to model in the schema as making them both optional, and if you add a port with nothing but a name, well then, nothing will change from the original J2EE DD service-ref and WSDL. -- 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-1907) Deploy command should redeploy if the app is already deployed
[ http://issues.apache.org/jira/browse/GERONIMO-1907?page=all ] Aaron Mulder updated GERONIMO-1907: --- Assign To: (was: Aaron Mulder) Deploy command should redeploy if the app is already deployed - Key: GERONIMO-1907 URL: http://issues.apache.org/jira/browse/GERONIMO-1907 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, usability Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: Wish List -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1873) Deployment must handle dynamically-registered module builders
[ http://issues.apache.org/jira/browse/GERONIMO-1873?page=all ] Aaron Mulder updated GERONIMO-1873: --- Assign To: (was: Aaron Mulder) Deployment must handle dynamically-registered module builders - Key: GERONIMO-1873 URL: http://issues.apache.org/jira/browse/GERONIMO-1873 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 Currently the deployment infrastructure does some things specific to different module types -- like identifying the embedded deployment plan in a xAR so it can look up the config ID, and searching for child modules of an EAR. This is currently hardcoded to the specific set of module types supported by Geronimo by default. It should be able to handle builders deployed later (e.g. Spring, ServiceMix, whatever), which probably means it needs to be able to ask something on the server-side what modules are available, what their nested plan files are called, and what their j2eeType would be. -- 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-1196) Keystore portlet: Viewing trusted certificate results in an error
[ http://issues.apache.org/jira/browse/GERONIMO-1196?page=all ] Aaron Mulder updated GERONIMO-1196: --- Assign To: (was: Aaron Mulder) Keystore portlet: Viewing trusted certificate results in an error - Key: GERONIMO-1196 URL: http://issues.apache.org/jira/browse/GERONIMO-1196 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console 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] Updated: (GERONIMO-734) Adding CORBA settings to local-only EJB appears to give NPE
[ http://issues.apache.org/jira/browse/GERONIMO-734?page=all ] Aaron Mulder updated GERONIMO-734: -- Assign To: (was: Aaron Mulder) Adding CORBA settings to local-only EJB appears to give NPE --- Key: GERONIMO-734 URL: http://issues.apache.org/jira/browse/GERONIMO-734 Project: Geronimo Type: Bug Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 I added a tss-link to an EJB with only local and local-home interfaces. I suspect the problem is the lack of remote interfaces, in which case this should result in a deployment error. What actually happened was: org.openejb.corba.CORBAException: java.lang.NullPointerException at org.openejb.corba.Adapter.init(Adapter.java:127) at org.openejb.corba.AdapterEntity.init(AdapterEntity.java:85) at org.openejb.corba.AdapterWrapper.start(AdapterWrapper.java:87) at org.openejb.corba.TSSBean.registerContainer(TSSBean.java:207) at org.openejb.corba.TSSBean$$FastClassByCGLIB$$57d49a76.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:719) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:94) at org.openejb.corba.TSSBean$$EnhancerByCGLIB$$7369adf9.registerContainer(generated) at org.openejb.GenericEJBContainer.doStart(GenericEJBContainer.java:396) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:850) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:328) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:111) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:133) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:141) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:503) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:207) at org.apache.geronimo.kernel.KernelGBean.startRecursiveGBean(KernelGBean.java:72) at org.apache.geronimo.kernel.KernelGBean$$FastClassByCGLIB$$1cccefc9.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:754) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:177) at org.apache.geronimo.kernel.jmx.MBeanServerDelegate.invoke(MBeanServerDelegate.java:117) at mx4j.remote.rmi.RMIConnectionInvoker.invoke(RMIConnectionInvoker.java:219) at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at mx4j.remote.rmi.RMIConnectionProxy.invoke(RMIConnectionProxy.java:34) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.chain(RMIConnectionSubjectInvoker.java:99) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.access$000(RMIConnectionSubjectInvoker.java:31) at mx4j.remote.rmi.RMIConnectionSubjectInvoker$1.run(RMIConnectionSubjectInvoker.java:90) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAsPrivileged(Subject.java:500) at mx4j.remote.MX4JRemoteUtils.subjectInvoke(MX4JRemoteUtils.java:163) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.subjectInvoke(RMIConnectionSubjectInvoker.java:86) at mx4j.remote.rmi.RMIConnectionSubjectInvoker.invoke(RMIConnectionSubjectInvoker.java:80) at $Proxy0.invoke(Unknown Source) at
[jira] Updated: (GERONIMO-1582) NPE for EJB webservices.xml with bad jaxrpc-mapping-file
[ http://issues.apache.org/jira/browse/GERONIMO-1582?page=all ] Aaron Mulder updated GERONIMO-1582: --- Assign To: (was: Aaron Mulder) NPE for EJB webservices.xml with bad jaxrpc-mapping-file -- Key: GERONIMO-1582 URL: http://issues.apache.org/jira/browse/GERONIMO-1582 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 If the jaxrpc-mapping-file points to an invalid location, a NullPointerException is produced. It should instead give a DeploymentException with a message like: webservices.xml for EJB JAR points to jaxrpc-mapping-file 'META-INF/foo.map' for service 'bar' but that file is not found. 11:47:01,051 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.deployment.util.NestedJarFile.getInputStream(NestedJarFile.java:187) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:95) at org.apache.geronimo.axis.builder.WSDescriptorParser.readJaxrpcMapping(WSDescriptorParser.java:88) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:315) at org.apache.geronimo.axis.builder.WSDescriptorParser.parseWebServiceDescriptor(WSDescriptorParser.java:379) at org.apache.geronimo.axis.builder.AxisBuilder.parseWebServiceDescriptor(AxisBuilder.java:106) at org.apache.geronimo.axis.builder.AxisBuilder$$FastClassByCGLIB$$16a52a9a.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.WebServiceBuilder$$EnhancerByCGLIB$$493cf3fa.parseWebServiceDescriptor(generated) at org.openejb.deployment.OpenEJBModuleBuilder.addGBeans(OpenEJBModuleBuilder.java:500) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) 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
[jira] Updated: (GERONIMO-1431) Make deploy tool and hot deploy directory work better together
[ http://issues.apache.org/jira/browse/GERONIMO-1431?page=all ] Aaron Mulder updated GERONIMO-1431: --- Assign To: (was: Aaron Mulder) Make deploy tool and hot deploy directory work better together -- Key: GERONIMO-1431 URL: http://issues.apache.org/jira/browse/GERONIMO-1431 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: deployment, Hot Deploy Dir Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 Right now if you deploy something with the deploy tool and then drop an update in the hot deploy directory, it doesn't work. The hot deploy dir expects you to only use the hot dpeloy dir for that module. Likewise, if you deploy something with the hot deploy dir and then undeploy it with the deploy tool, it is not deleted from the hot deploy dir. Both of those can be fixed. -- 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-803) Deploy failure during redeploy leaves app undeployed
[ http://issues.apache.org/jira/browse/GERONIMO-803?page=all ] Aaron Mulder updated GERONIMO-803: -- Assign To: (was: Aaron Mulder) Deploy failure during redeploy leaves app undeployed Key: GERONIMO-803 URL: http://issues.apache.org/jira/browse/GERONIMO-803 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0-M3 Reporter: Aaron Mulder Priority: Critical Fix For: 1.2 Ouch, this is a nasty one. If you deploy app Foo, then change it to be broken (invalid DD, whatever) and redeploy it, it goes like this: 1) undeploy old one 2) try to deploy new one 3) fail The result is that the old one has been undeployed but the new one hasn't been deployed. It would be ideal if we could try the deploy operation first, and only if it appears valid, undeploy the old version and start the new version. I'm not sure how that could be done. -- 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-1959) Console: plugin % complete shoudl reset to 0 while preparing a download
[ http://issues.apache.org/jira/browse/GERONIMO-1959?page=all ] Aaron Mulder updated GERONIMO-1959: --- Assign To: (was: Aaron Mulder) Console: plugin % complete shoudl reset to 0 while preparing a download --- Key: GERONIMO-1959 URL: http://issues.apache.org/jira/browse/GERONIMO-1959 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.1 Reporter: Aaron Mulder Priority: Minor Fix For: 1.1.1 The console progress bar should go back to 0 if the percent complete is set to -1 (which should handle resetting it to 0 during the preparing to download phase, whereas now it stays at whatever value it had for the last status message) -- 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-1687) NPE during deployment related to EJB Ref
[ http://issues.apache.org/jira/browse/GERONIMO-1687?page=all ] Aaron Mulder updated GERONIMO-1687: --- Assign To: (was: Aaron Mulder) NPE during deployment related to EJB Ref Key: GERONIMO-1687 URL: http://issues.apache.org/jira/browse/GERONIMO-1687 Project: Geronimo Type: Bug Security: public(Regular issues) Components: naming, OpenEJB Versions: 1.0 Environment: Geronimo 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: 1.1.1 In my case this was caused by an EAR containing an EJB JAR and WAR but only the WAR was listed in application.xml. Clearly a user error, but obviously we should have an error message not an NPE. 15:45:22,432 ERROR [Deployer] Deployment failed due to java.lang.NullPointerException at org.apache.geronimo.j2ee.deployment.RefContext.getEJBLocalRef(RefContext.java:111) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addEJBLocalRefs(ENCConfigBuilder.java:507) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponentContext(ENCConfigBuilder.java:781) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.buildComponentContext(JettyModuleBuilder.java:1291) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:464) at org.apache.geronimo.jetty.deployment.JettyModuleBuilder$$FastClassByCGLIB$$b30bba8a.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:160) at org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$4ca9e4d7.addGBeans(generated) at org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800) at org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) at org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) at org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) at org.apache.geronimo.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$5896ed49.buildConfiguration(generated) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:269) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:102) 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:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at
[jira] Updated: (GERONIMO-1581) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with /
[ http://issues.apache.org/jira/browse/GERONIMO-1581?page=all ] Aaron Mulder updated GERONIMO-1581: --- Assign To: (was: Aaron Mulder) webservices.xml wsdl-file and jaxrpc-mapping-file values can't start with / --- Key: GERONIMO-1581 URL: http://issues.apache.org/jira/browse/GERONIMO-1581 Project: Geronimo Type: Bug Security: public(Regular issues) Components: OpenEJB, webservices Versions: 1.0 Reporter: Aaron Mulder Priority: Critical Fix For: Verification Required It seems like it ought to be legal for the wsdl-file value to start with a / (in fact, the book I got my example from uses that). However, in Geronimo, that results in a java.lang.RuntimeException: Could not open stream to wsdl file. If we can't handle the preceding /, we should probably just strip it if it's there and then go on as normal (without the leading / everything is fine). The same appears to be true for the jaxrpc-mapping-file though it produces an NPE instead of the RuntimeException. -- 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-1271) Delete network listener action should ask for confirmation
[ http://issues.apache.org/jira/browse/GERONIMO-1271?page=all ] Aaron Mulder updated GERONIMO-1271: --- Assign To: (was: Aaron Mulder) Delete network listener action should ask for confirmation -- Key: GERONIMO-1271 URL: http://issues.apache.org/jira/browse/GERONIMO-1271 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0-M5 Reporter: Rick McGuire Priority: Minor Fix For: Wish List The Delete operation of the Web Server-Network Listeners should ask for confirmation before deleting. It is real easy to accidentally click on delete instead of edit and accidentally delete needed listenersfor example, the listener required by the console itself (ask me how I know :-)). -- 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-454) Support Group Name = Role Name Role Mapping
[ http://issues.apache.org/jira/browse/GERONIMO-454?page=all ] Aaron Mulder updated GERONIMO-454: -- Assign To: (was: Aaron Mulder) Support Group Name = Role Name Role Mapping --- Key: GERONIMO-454 URL: http://issues.apache.org/jira/browse/GERONIMO-454 Project: Geronimo Type: Improvement Components: deployment, security Versions: 1.0-M2 Reporter: Aaron Mulder Priority: Minor Fix For: 1.2 Currently, you must manually map principals to roles in the security component of a deployment descriptor. In the common case where group names match role names, this seems like unnecessary overhead. Alan and I talked and our plan is to make the role-mapping parts of the security elements look something like this: security ... automatic-role-mapping? principal-classfoo.GroupPrincipal/principal-class* /automatic-role-mapping role-mapping? ... /role-mapping /security The automatic-role-mapping is the new bit. If you specify that element empty, it would map every principal type the security realm considers to be a group to roles. For example, if you configure the seucrity realm to consider the principal class foo.GroupPrincipal as a role, and use an empty automatic-role-mapping element, that's what you'd get. You can also manually specify one or more principal classes that should be automatically mapped to roles. In any of these cases, the automatic mapping is done based on the role name and group name matching. If you specify automatic mapping *and* individual role mapping, then the user just needs to qualify for the role based on either one or the other (not both). So you could use a manual role mapping to add eligible users on top of the automatic role mapping, but not to subtract users from the automatic role mapping. -- 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: dependency ServiceMix SNAPSHOT on Maven2
The m2 repository for the latest snapshot distribution http://people.apache.org/maven-snapshot-repository/org/apache/servicemix/apache-servicemix/3.0-incubating-SNAPSHOT/ Cheers, Guillaume Nodet On 6/30/06, Charlesh [EMAIL PROTECTED] wrote: I work with Maven2 on repository 'http://servicemix.org/m2-snapshots'. This repository is not actualized? exist other repository for ServiceMix Snapshots for Maven2? thanks! -- View this message in context: http://www.nabble.com/dependency-ServiceMix-SNAPSHOT-on-Maven2-tf1870244.html#a5111577 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: support for oneway MEP in servicemix-http ?
I think you are right. A 202 code should be returned. Could you raise a JIRA for that please ? If you can provide a patch, that would be cool :) Cheers, Guillaume Nodet On 6/30/06, Renaud Bruyeron [EMAIL PROTECTED] wrote: I am trying to send a oneway message into a http endpoint, but I am having trouble doing this. Here's the endpoint declaration: http:endpoint service=mmx:mms-service endpoint=mms-service role=consumer soap=true locationURI=http://localhost/mm7; defaultMep=http://www.w3.org/2004/08/wsdl/in-only; wsdlResource=classpath:wsdl/gwxms.wsdl/ Notice the MEP is in-only. The proxied endpoint is actually a JMS queue: jms:endpoint service=mmx:mms-service endpoint=mms-service role=provider destinationStyle=queue soap=true jmsProviderDestinationName=queue.mms jndiConnectionFactoryName=java:comp/env/jms/ConnectionFactory/ I am using a Axis 1.4 client to send the message in (I must use Axis because I need proper SAAJ support). Because it is a oneway message, the client expects a HTTP 202 response. However servicemix-http only replies with HTTP 200, which means synchronous in HTTP/SOAP. The exchange is working ok (I see the mime message on the JMS queue), the trouble is with the http endpoint. Am I correct in setting up the MEP as in-only on the http:endpoint? Any idea on what the problem could be? (I suspect that http:endpoint should figure out from the WSDL that the message is oneway and return HTTP 202 accordingly, but I could be wrong). - Renaud
Re: Enable wiki-rendering for GERONIMO JIRA project
On 6/30/06, Jason Dillon [EMAIL PROTECTED] wrote: FYI, this has been enabled for GERONIMO. Is there a page we could take a look at within Geronimo space and see how it looks like after the change? Should probably also enable for GBUILD and GERONIMODEVTOOLS... assuming that it is acceptable. +1 to enable it for other Geronimo subprojects. --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Issues Closed: week of 06-30-2006
Project: Apache Geronimo Status: Resolved, Closed (23 items) Updated In Last: Week (7 days) ** New Feature * [GERONIMO-2046] no caching implementation ** Bug * [GERONIMO-2083] Use howl-logger-1.0.1-1.jar * [GERONIMO-1350] Web Console indicates that web server stats are available for Tomcat when they really are not * [GERONIMO-1379] Login Error page does not include updates to remove table and include About link * [GERONIMO-1225] The recently added Common Console Actions on welcome page doesn't work right * [GERONIMO-1864] Deploy no longer starts a web application by default * [GERONIMO-1882] Deploy from web console fails with NoSuchOperationException * [GERONIMO-1918] NoClassDefFoundError/ClassNotFoundException when attempting to deploy web app from console GUI * [GERONIMO-2044] Compilation failure: java.nio.BufferOverflowException ** Improvement * [GERONIMO-2152] Update for new OpenEJB 2.2 * [GERONIMO-1122] Updated view of configurations * [GERONIMO-1300] Add the new Geronimo powered by gif to the Welcome Page and the web console welcome portlet ** Task * [GERONIMO-2154] 1.1 Officially Released for Mirroring and Distribution * [GERONIMO-1702] The latest maven 1 Build process
if you are having maven2 build woes around JAXB/com.sun.*...
I've found performing rm -rf ~/.m2/repository/com/sun/ really helped. It seems that there are some clashes of m2 poms around the place in different repos around the JAXB-API and JAXB-impl jars which can mess things up pretty well. Many thanks to Guillaume for helping me figure that out on IM :) -- James --- http://radio.weblogs.com/0112098/
Re: M2 Issues and Actions
inline.. --- Jason Dillon [EMAIL PROTECTED] wrote: 2. Spec Jars - The geronimo spec jars need to be published along with the poms. This was supposed to happen soon after the 1.1 release. And it has happened. Thanks! Are there any issues with this? Does this have any relation to the proposed reorg of the specs into multiple trunks? 4. Maven does not allow building a plugin and a module if the module uses the plugin in the same build. As a result the first time build is a 3 step process. Jason suggested IMO we should have a completely separate tree for our build support tools. And once the plugins are stable we release them, until they are stable we make regular snaps, so that the main tree(s) can just build w/o having to worry about building plugins first. I'm not sure how easy this is going to be... We many need to introduce a bootstrap phase to build a few modules and a plugin or two and then run through the full build. Not terribly ideal IMO, but probably the easiest way to get the m2 build functional in the least amount of time. I hope that we can eventually eliminate the need for the bootstrap, but from what I understand so far this is not going to be something we can do easily in a short amount of time (defs not with the RTC muck). We should start publishing SNAPSHOTs ASAP to solve this problem, This is very user friendly. Once we have assembled our first full server, we can start thinking of reorganizing the source tree. While this may work most of the time, it is not ideal as when making changes to plugins, users will be mystified when those changes are not used on the first build. This is not true. The plugin is *not* used before it is built. The problem is that maven does not even start the build until it has downloaded all the plugins. Even a dummy plugin would work. I'd prefer to minimize the utilization of remote maven repositories... not increase them. IMO remote repository is growing to become more and more of a build anit-pattern. 5. checking out openejb - In M1 we could define goals like m:co, it is not possible to do this in M2. There is no way to specify executions in the top level pom that are not inherited by the children. And we must resort to checking out each module and building it! There are a few more options here. A module that exists to solely check out openejb and then run the openejb build as a part of our build. This can be easily facilitated with antrun and some well placed dependencies. Or use svn:externals ( http://svnbook.red-bean.com/nightly/en/svn- book.html#svn.advanced.externals ) to force SVN to check out the openejb tree when Geronimo is checked out. Would need to have users svn up in the openejb tree from time to time though, as last I checked svn:externals are ignored when the local working space is updated. Jacek is working on this. Thanks Jacek! Currently we ask the user to use svn command to checkout openejb. What are those exact commands that we ask them to use? http://cwiki.apache.org/confluence/display/GMOxDEV/Building+Apache+Geronimo+with+Maven+2 Thanks Anita --jason __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [RTC] Clarification please from the PMC
Jason Dillon wrote: I second your opinions, but that's how we operate and I can't do much regarding this matter other than to spare some time and vote at least. I think I'm not alone thinking that RTC is very painful, but some see it as a remedy of our troublesome happenings in the past. We'll see how it work out. The only thing I can do is to do my best to speed it up a bit and be more active in RTCs (given my manager doesn't get me swamped with other daily tasks that took me away for the past weeks). Not mentioning there're lots of bugs reported. I think that if the Apache Geronimo community is actually self-governing as I believed it was, then there is something that can be done about this. You are definitely not alone in thinking that RTC is painful (and non-functional I would like to add). I'm confused now... how can one send a RTC w/o having a patch or patches for others to review? Yes, you might've been confused as it's Matt's statement nor mine and thus the origin of your confusion, isn't it? Honestly... I don't know... but I am confused ;-) My point was that for very complicated changes like M1 - M2 a note outlining the proposed action should not require a fully baked patch. Perhaps I misstated. I have never been as active in open source projects (Apache Geronimo and OpenEJB in particular) as I should've been. I haven't been able to manage my daily workload wisely and spare more time to work on these OSSes at nights. At this point I'm completely overwhelmed with other stuff meaning I don't have as much time as is required from me to contribute. It happens... which is why we have a community of developers to help pick up the slack. Unfortunately some decisions have been made which limit the abilities of the bulk of the community and force the minorities to play a much bigger part, which unfortunately most have not stepped up to do. Jason, RTC was implemented because the PMC chair and the Board felt that the G community was not functioning in an open fashion. I don't want to repeat that whole debate as its been debated and nothing positive will come from rehashing it. RTC has improved communications I think is achieving its desired effect. Yes, the side effect is slowing down some development. I know its frustrating but if we work well together through the process changes (RTC) we will be moving back to CTR. Complaining about RTC won't get us there. Yes, we're all frustrated and we all will get through this working together. I see it as a threat to me being a PMC member. Do you think I should step down having failed so often? Not at all. I don't believe that you should step down at all. You are one of the few PMC folks that is actually trying to keep up with the RTC and I certainly don't want to see those numbers reduced. As I mentioned before, I was not aiming my comments at anyone in particular. I have just been quietly ignoring the situation for sometime, and feel that I can not do that anymore... it is not in my nature. I agree that Jacek is doing great. Collectively we all make this work and all contributions great and small move us forward. I remember having discussion about a distinction between a committer and PMC member. Some believed there's none. I'm not sure that there is (or should be) much difference. It's not my decision to activate RTC, which as far as I understand has never proven itself to be successful, but that's reality we need to live in. If our community is self-governing and the bulk of the community is in opposition to this rule, why then does that community need to live with it? See above about the Board and PMCs perspective of our community dynamics. BTW, that is my opinion... I have not performed any poll to see which parts of our community actually is in favor of RTC. I would suggest that most folks agree that improved and more frequent communication is desired... but I also suggest that RTC in its current incarnation is NOT the best way to achieve those goals. Its moved us back from where we were at. Certainly past where we should be but I'm optimistic that we'll move back to the center. I believe, though, that it won't kill the project, but strengthen. That all depends on how long it goes not for... IMO, the longer it does, the more chances are that the end-result will be a more and more defunct community. * * * Thanks for taking the time to respond. I apologize if my comments stir your frustration... but I felt and fell like I have to say something, to play my part in this community. --jason
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Alan D. Cabrera wrote: Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? The version that shipped with Geronimo 1.0 was missing a lot of features (threw unimplemented exceptions, etc.) as well as out right buggy in places. The version that just shipped with 1.1 should be complete (the APIs anyway). The version shipping with 1.1 only supports SMTP. However, the newly created javamail component (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in the works. 2) FYI, we're about to check in has JavaMail 1.4 as well. Regards, Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? 2) FYI, we're about to check in has JavaMail 1.4 as well. Regards, Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Rick McGuire wrote: Alan D. Cabrera wrote: Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? The version that shipped with Geronimo 1.0 was missing a lot of features (threw unimplemented exceptions, etc.) as well as out right buggy in places. The version that just shipped with 1.1 should be complete (the APIs anyway). The version shipping with 1.1 only supports SMTP. However, the newly created javamail component (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in the works. So this build tree, do you mean trunk? Regards, Alan
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Rick McGuire wrote: Alan D. Cabrera wrote: Rick McGuire wrote: Alan D. Cabrera wrote: Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? The version that shipped with Geronimo 1.0 was missing a lot of features (threw unimplemented exceptions, etc.) as well as out right buggy in places. The version that just shipped with 1.1 should be complete (the APIs anyway). The version shipping with 1.1 only supports SMTP. However, the newly created javamail component (separate build tree) supports POP3, NNTP, and NNTP-POST. IMAP is in the works. So this build tree, do you mean trunk? There are multiple pieces to the javamail support. The first piece is the specs, which is in the specs build tree. In Geronimo 1.1, the SMTP provider that went with this was a module in Geronimo (javamail-transport). A couple weeks ago, I created a new javamail repository that contains all of the providers. This project also builds an uber-jar that contains the specs and the providers. The source for this is: https://svn.apache.org/repos/asf/geronimo/javamail/trunk One of the javamail changes I recently submitted for [RTC] review will remove the javamail-transport module from the Geronimo code tree, and replace it with a dependency on the javamail-providers jar file. Thanks for the info Rick. Regards, Alan
Re: [RTC] Add javamail 1.4 spec implementation.
+1 david jencks On Jun 23, 2006, at 4:59 AM, Rick McGuire wrote: The following JIRA http://issues.apache.org/jira/browse/GERONIMO-2148 Contains patches for adding a javamail 1.4 module to the specs component. I've attached 2 patches to this JIRA for the review. The larger patch (javamail-1.4.diff) is the full patch required to create the new module. Included with this is renaming the geronimo- spec-javamail module to geronimo-spec-javamail-1.3.1. I don't believe that rename shows up in the diff, although one file in the renamed module gets updated. The smaller diff (1.4.diff) is a comparison of the new 1.4 code to the 1.3.1 implementation so reviewers can see the changes made for the new features. This is just an FYI patch for the benefit of reviewers. Rick
Re: [RTC] Clarification please from the PMC
This reflects my sentiments as well. Regards, Alan Matt Hogstrom wrote: Jason Dillon wrote: I second your opinions, but that's how we operate and I can't do much regarding this matter other than to spare some time and vote at least. I think I'm not alone thinking that RTC is very painful, but some see it as a remedy of our troublesome happenings in the past. We'll see how it work out. The only thing I can do is to do my best to speed it up a bit and be more active in RTCs (given my manager doesn't get me swamped with other daily tasks that took me away for the past weeks). Not mentioning there're lots of bugs reported. I think that if the Apache Geronimo community is actually self-governing as I believed it was, then there is something that can be done about this. You are definitely not alone in thinking that RTC is painful (and non-functional I would like to add). I'm confused now... how can one send a RTC w/o having a patch or patches for others to review? Yes, you might've been confused as it's Matt's statement nor mine and thus the origin of your confusion, isn't it? Honestly... I don't know... but I am confused ;-) My point was that for very complicated changes like M1 - M2 a note outlining the proposed action should not require a fully baked patch. Perhaps I misstated. I have never been as active in open source projects (Apache Geronimo and OpenEJB in particular) as I should've been. I haven't been able to manage my daily workload wisely and spare more time to work on these OSSes at nights. At this point I'm completely overwhelmed with other stuff meaning I don't have as much time as is required from me to contribute. It happens... which is why we have a community of developers to help pick up the slack. Unfortunately some decisions have been made which limit the abilities of the bulk of the community and force the minorities to play a much bigger part, which unfortunately most have not stepped up to do. Jason, RTC was implemented because the PMC chair and the Board felt that the G community was not functioning in an open fashion. I don't want to repeat that whole debate as its been debated and nothing positive will come from rehashing it. RTC has improved communications I think is achieving its desired effect. Yes, the side effect is slowing down some development. I know its frustrating but if we work well together through the process changes (RTC) we will be moving back to CTR. Complaining about RTC won't get us there. Yes, we're all frustrated and we all will get through this working together. I see it as a threat to me being a PMC member. Do you think I should step down having failed so often? Not at all. I don't believe that you should step down at all. You are one of the few PMC folks that is actually trying to keep up with the RTC and I certainly don't want to see those numbers reduced. As I mentioned before, I was not aiming my comments at anyone in particular. I have just been quietly ignoring the situation for sometime, and feel that I can not do that anymore... it is not in my nature. I agree that Jacek is doing great. Collectively we all make this work and all contributions great and small move us forward. I remember having discussion about a distinction between a committer and PMC member. Some believed there's none. I'm not sure that there is (or should be) much difference. It's not my decision to activate RTC, which as far as I understand has never proven itself to be successful, but that's reality we need to live in. If our community is self-governing and the bulk of the community is in opposition to this rule, why then does that community need to live with it? See above about the Board and PMCs perspective of our community dynamics. BTW, that is my opinion... I have not performed any poll to see which parts of our community actually is in favor of RTC. I would suggest that most folks agree that improved and more frequent communication is desired... but I also suggest that RTC in its current incarnation is NOT the best way to achieve those goals. Its moved us back from where we were at. Certainly past where we should be but I'm optimistic that we'll move back to the center. I believe, though, that it won't kill the project, but strengthen. That all depends on how long it goes not for... IMO, the longer it does, the more chances are that the end-result will be a more and more defunct community. * * * Thanks for taking the time to respond. I apologize if my comments stir your frustration... but I felt and fell like I have to say something, to play my part in this community. --jason
Re: svn commit: r418212 - /incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java
Where's the Apache copyright header?
Also I'm not sure if we can include support for JBoss SwiftMQ to the
m2 performance plugin. These would have have to be hosted outside of
Apache AFAIK such as maybe in the Mojo project.
On 6/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jgapuz
Date: Fri Jun 30 02:31:41 2006
New Revision: 418212
URL: http://svn.apache.org/viewvc?rev=418212view=rev
Log:
added to support SwiftMQ.
Added:
incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java
Added:
incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java
URL:
http://svn.apache.org/viewvc/incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java?rev=418212view=auto
==
---
incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java
(added)
+++
incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/src/main/java/org/apache/activemq/tool/spi/SwiftMQPojoSPI.java
Fri Jun 30 02:31:41 2006
@@ -0,0 +1,57 @@
+package org.apache.activemq.tool.spi;
+
+import javax.jms.ConnectionFactory;
+import javax.jms.JMSException;
+import javax.naming.InitialContext;
+import javax.naming.Context;
+import javax.naming.NamingException;
+import java.util.Properties;
+
+
+public class SwiftMQPojoSPI extends ClassLoaderSPIConnectionFactory {
+public static final String KEY_BROKER_URL = brokerUrl;
+public static final String KEY_DEST_TYPE = destType;
+public static final String DEFAULT_URL = smqp://localhost:4001;
+public static final String SWIFTMQ_CONTEXT =
com.swiftmq.jndi.InitialContextFactoryImpl;
+public static final String SMQP = com.swiftmq.jms.smqp;
+
+protected ConnectionFactory instantiateConnectionFactory(Properties
settings) throws Exception {
+String destType = settings.getProperty(KEY_DEST_TYPE);
+ConnectionFactory factory;
+
+InitialContext context = getInitialContext(settings);
+
+if (destType != null destType == queue) {
+factory = (ConnectionFactory)
context.lookup(QueueConnectionFactory);
+} else {
+factory = (ConnectionFactory)
context.lookup(TopicConnectionFactory);
+}
+
+return factory;
+}
+
+public void configureConnectionFactory(ConnectionFactory jmsFactory,
Properties settings) throws Exception {
+//To change body of implemented methods use File | Settings | File
Templates.
+}
+
+public InitialContext getInitialContext(Properties settings) throws
Exception {
+String url = settings.getProperty(KEY_BROKER_URL);
+
+Properties properties = new Properties();
+properties.put(Context.INITIAL_CONTEXT_FACTORY, SWIFTMQ_CONTEXT);
+properties.put(Context.URL_PKG_PREFIXES, SMQP);
+
+if (url != null url.length() 0) {
+properties.put(Context.PROVIDER_URL, url);
+} else {
+properties.put(Context.PROVIDER_URL, DEFAULT_URL);
+}
+
+try {
+return new InitialContext(properties);
+} catch (NamingException e) {
+throw new JMSException(Error creating InitialContext ,
e.toString());
+}
+}
+
+}
--
James
---
http://radio.weblogs.com/0112098/
Re: [RTC] - Fix top pom to reference right plugin
I think this is a bug fix and doesn't need a vote. I also thought I'd fixed this already, but see that it must be in some of the other trees I'm maintaining locally. In case anyone disagrees with my bug-fix theoty, +1. thanks david jencks On Jun 30, 2006, at 7:56 AM, Jeff Genender wrote: The packaging plugin is at 1.2-SNAPSHOT, and the pom references it as 1.2.0. I wan tto update it to 1.2-SNAPSHOT: Index: pom.xml === --- pom.xml (revision 418149) +++ pom.xml (working copy) @@ -136,7 +136,7 @@ | Geronimo plugin versions | -- - geronimoPackagingPluginVersion1.2.0/geronimoPackagingPluginVersion + geronimoPackagingPluginVersion1.2-SNAPSHOT/ geronimoPackagingPluginVersion !-- |
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Alan D. Cabrera wrote: Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? I've not checked geronimo smtp transport, Is there a feature list for current geronimo stmp implementation compared to sun smtp transport? Does it support the quitwait? bindaddress/port for sockets? does it support appending further strings at the end of the MAIL command and the RCPT command (ORCPT, NOTIFY). How does it compare in converting messages from 7bit to 8bit when sending to servers that supports 8bitmime, and from 8bit to 7bit when sending to servers that do not support 8bitmime? Stefano PS: About the 7bit-8bit mime conversion I wrote some mail to the javamail interest and seems that they are buggy in the sun-javamail transport.
Re: [RTC] - Fix top pom to reference right plugin
I think that this is a bug fix as well. But, just in case, +1. Regards, Alan David Jencks wrote: I think this is a bug fix and doesn't need a vote. I also thought I'd fixed this already, but see that it must be in some of the other trees I'm maintaining locally. In case anyone disagrees with my bug-fix theoty, +1. thanks david jencks On Jun 30, 2006, at 7:56 AM, Jeff Genender wrote: The packaging plugin is at 1.2-SNAPSHOT, and the pom references it as 1.2.0. I wan tto update it to 1.2-SNAPSHOT: Index: pom.xml === --- pom.xml (revision 418149) +++ pom.xml (working copy) @@ -136,7 +136,7 @@ | Geronimo plugin versions | -- - geronimoPackagingPluginVersion1.2.0/geronimoPackagingPluginVersion + geronimoPackagingPluginVersion1.2-SNAPSHOT/geronimoPackagingPluginVersion !-- |
Re: geronimo javamail and James (Was: [RTC] Removal of the javamail-transport code.)
Stefano Bagnara wrote: Alan D. Cabrera wrote: Stefano Bagnara wrote: Alan D. Cabrera wrote: Why would we need both? We don't need both at the same time. But: 1) I guess that geronimo-javamail is not as stable and feature complete as the sun-javamail. 2) We use javamail 1.4 apis (geronimo-javamail seems to be 1.3 compliant) So what I think we could do is adding the handling of geronimo specific stuff while keeping the default to sun. This way one could test it and find out the differences. 1) Maybe not as stable. What features do you think are missing? I've not checked geronimo smtp transport, Is there a feature list for current geronimo stmp implementation compared to sun smtp transport? All answers below are for the latest version. The one that shipped in Geronimo 1.0 did not support these. Does it support the quitwait? yes bindaddress/port for sockets? yes does it support appending further strings at the end of the MAIL command and the RCPT command (ORCPT, NOTIFY). yes How does it compare in converting messages from 7bit to 8bit when sending to servers that supports 8bitmime, and from 8bit to 7bit when sending to servers that do not support 8bitmime? I haven't implemented 8bitmime yet, as I've not really found a good description for what needs to be done to support that. I don't think it's a big issue, I just need to understand what it means to support it. Stefano PS: About the 7bit-8bit mime conversion I wrote some mail to the javamail interest and seems that they are buggy in the sun-javamail transport.
New c++ library
All, Tim Bish and I are just about ready with the new C++ library. It currently will only serve as a replacement for CMS (stomp C++ client), but it's architecture supports pluggable connectors, so merging in the openwire-cpp client code should be fairly easy. Some of the features include: 1) stomp protocol (requies AMQ 4.0.1 or later for the added request/response ids) 2) JMS 1.1-like API - consumers, producers, etc. - closely follows what was done in the .NET client. 3) support for topics and queues (so far as they are supported by stomp). 4) Connector architecture - facilitates having swappable protocols (can use openwire or stomp without changing code) 5) meta-url syntax similar to the other libraries to support passing in options on the url string. 6) complete suite of cpp-unit tests 7) integration-level tests (requires a broker) 8) Maven 2 build (uses Mojo native plugin) I'd like to call this library activemq-cpp, as it will support all the JMS-like transports. Of course, we'll want to merge in the openwire-cpp code base into it early on to consolidate the two projects. My idea was to post the code at people.apache.org/~nmittler (hopefully this weekend) and let everyone take a look. I'm open to other ideas. Regards, Nate
Re: [RTC] - Fix top pom to reference right plugin
It was my understanding that we do not use snapshots for plugins. This is from etc/project.properties - geronimo_packaging_plugin_version=1.2.0-4 geronimo_assembly_plugin_version=1.2.0-9 geronimo_deployment_plugin_version=1.2.0-2 geronimo_dependency_plugin_version=1.2.0-2 Thnaks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: The packaging plugin is at 1.2-SNAPSHOT, and the pom references it as 1.2.0. I wan tto update it to 1.2-SNAPSHOT: Index: pom.xml === --- pom.xml (revision 418149) +++ pom.xml (working copy) @@ -136,7 +136,7 @@ | Geronimo plugin versions | -- - geronimoPackagingPluginVersion1.2.0/geronimoPackagingPluginVersion + geronimoPackagingPluginVersion1.2-SNAPSHOT/geronimoPackagingPluginVersion !-- | __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: New c++ library
On 6/30/06, Mittler, Nathan [EMAIL PROTECTED] wrote: All, Tim Bish and I are just about ready with the new C++ library. It currently will only serve as a replacement for CMS (stomp C++ client), but it's architecture supports pluggable connectors, so merging in the openwire-cpp client code should be fairly easy. Some of the features include: 1) stomp protocol (requies AMQ 4.0.1 or later for the added request/response ids) 2) JMS 1.1-like API - consumers, producers, etc. - closely follows what was done in the .NET client. 3) support for topics and queues (so far as they are supported by stomp). 4) Connector architecture - facilitates having swappable protocols (can use openwire or stomp without changing code) 5) meta-url syntax similar to the other libraries to support passing in options on the url string. 6) complete suite of cpp-unit tests 7) integration-level tests (requires a broker) 8) Maven 2 build (uses Mojo native plugin) AWESOME! I'd like to call this library activemq-cpp, as it will support all the JMS-like transports. Of course, we'll want to merge in the openwire-cpp code base into it early on to consolidate the two projects. My idea was to post the code at people.apache.org/~nmittler (hopefully this weekend) and let everyone take a look. I'm open to other ideas. By all means import it into activemq-cpp if you like; trunk is a development branch (the branch-4.0 is for production releases). If you're a bit unsure by all means check it into the sandbox directory first and we can all noodle it there first. -- James --- http://radio.weblogs.com/0112098/
Re: [RTC] - Fix top pom to reference right plugin
On Jun 30, 2006, at 9:07 AM, anita kulshreshtha wrote: It was my understanding that we do not use snapshots for plugins. This is from etc/project.properties - geronimo_packaging_plugin_version=1.2.0-4 geronimo_assembly_plugin_version=1.2.0-9 geronimo_deployment_plugin_version=1.2.0-2 geronimo_dependency_plugin_version=1.2.0-2 That was due to maven 1 incompetence in plugin management. It's caused untold headaches. Although it appears m2 has a whole new set of things it cant do with plugins, handling snapshot plugins allegedly works fine. Due to the problems with the m1 versioning I'd like to give m2 snapshot plugins a chance. thanks david jencks Thnaks Anita --- Jeff Genender [EMAIL PROTECTED] wrote: The packaging plugin is at 1.2-SNAPSHOT, and the pom references it as 1.2.0. I wan tto update it to 1.2-SNAPSHOT: Index: pom.xml === --- pom.xml (revision 418149) +++ pom.xml (working copy) @@ -136,7 +136,7 @@ | Geronimo plugin versions | -- - geronimoPackagingPluginVersion1.2.0/geronimoPackagingPluginVersion + geronimoPackagingPluginVersion1.2-SNAPSHOT/ geronimoPackagingPluginVersion !-- | __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Created: (GERONIMO-2159) Corba Spec pom has inconsistent groupId
Corba Spec pom has inconsistent groupId --- Key: GERONIMO-2159 URL: http://issues.apache.org/jira/browse/GERONIMO-2159 Project: Geronimo Type: Improvement Security: public (Regular issues) Reporter: Bill Dudney Priority: Trivial Attachments: pom.patch The groupId is inconsistent with the rest of the specs jars which leave it out (and thus it defaults to the parent pom's group id). This is certainly a nit but consistency is a 'good thing'. -- 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
