Re: ConcurrentModificationException while starting AG1.1
Thanks David. Can I take this jar (http://people.apache.org/~djencks/maven/commons-modeler/jars/commons-modeler-1.2-GERONIMO-SNAPSHOT.jar ) and replace the one in a previous version of G say 1.0? Will it be fine? Or do I have to do a rebuild? Regards ManuOn 5/9/06, David Jencks [EMAIL PROTECTED] wrote: I've put a private build of commons-modeler on my apache page and modified the g. build to use it. Could you rebuild g (you will need a clean build after dain's changes) and see if this CME is fixed?thanksdavid jencks On May 8, 2006, at 2:30 PM, David Jencks wrote:I've opened http://issues.apache.org/bugzilla/show_bug.cgi?id=39521for this and I wrote a patch to possibly fix it. I'm going to push a private jar for this and set up the g. build to use it.I also opened http://issues.apache.org/jira/browse/GERONIMO-1999 for us to track this problemthanksdavid jencksOn May 8, 2006, at 3:33 AM, Phani Madgula wrote: Hi,I am getting the following exception, quite unfrequently, may be once in 25 times, while starting AG1.1jvm 1 | 08:24:25,762 ERROR [Registry] Error registering Geronimo:type=Request Processor,worker=http-localhost%2F127.0.0.1-8453,name=HttpRequest0jvm 1 | java.util.ConcurrentModificationException: concurrent access to HashM ap attempted by Thread[http-localhost%2F127.0.0.1-8453-Processor25,5,main]jvm 1 | at java.util.HashMap.onEntry(HashMap.java :205)jvm 1 | at java.util.HashMap.transfer(HashMap.java:510)jvm 1 | at java.util.HashMap.resize (HashMap.java:500)jvm 1 | at java.util.HashMap.addEntry(HashMap.java:800)jvm 1 | at java.util.HashMap.put (HashMap.java:441)jvm 1 | at org.apache.commons.modeler.Registry.addManagedBean(Registry.java:457) jvm 1 | at org.apache.commons.modeler.Registry.loadDescriptors(Registry.java:938)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean(Registry.java:719)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean (Registry.java:1047)jvm 1 | at org.apache.commons.modeler.Registry.registerComponent(Registr y.java:859)jvm 1 | at org.apache.coyote.http11.Http11Protocol$JmxHttp11ConnectionHandler.init(Http11Protocol.java:175) jvm 1 | at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48) jvm 1 | at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686)jvm 1 | at java.lang.Thread.run(Thread.java:797)jvm 1 | 08:24:25,762 ERROR [Registry] Error loading jar:file:/D:/ccviews/d_sjc_tk4s_f5887_pathfinder_wasce_only/v3tools/thirdparty/was_ce/test/was- ce-1.1.0/repository/tomcat/tomcat-ajp/5.5.15/tomcat-ajp-5.5.15.jar!/org/apache/jk/mbeans-descriptors.xmljvm 1 | 08:24:25,762 WARN [Http11BaseProtocol] Error registering requestI saw that the Registry class is not thread-safe. In the method, Http11Protocol:JmxHttp11ConnectionHandler:init()there is a call to Registry.getRegistry(null, null).registerComponent(rp, rpName, null) Should this be synchronized to resolve the problem? Can we synchronize it? Any suggestions?Regardsphani
[jira] Commented: (GERONIMO-594) Begin on TransactionManager always fails when thread is associated with a Tx
[ http://issues.apache.org/jira/browse/GERONIMO-594?page=comments#action_12378573 ] Ludovic Orban commented on GERONIMO-594: I disagree with your comment David. In the JTA 1.0.1 spec, page 10 paragraph 3.2.2 'Completing a Transaction' one can read: 'After the commit method returns, the calling thread is not associated with a transaction'. The same also applies to rollback. Begin on TransactionManager always fails when thread is associated with a Tx Key: GERONIMO-594 URL: http://issues.apache.org/jira/browse/GERONIMO-594 Project: Geronimo Type: Bug Components: transaction manager Versions: 1.0-M3 Reporter: Dain Sundstrom Assignee: David Jencks The TransactionManager.begin() always throws an exception it thread is already associated with a transaction. This means the following code will fail: txManager.getTransaction().commit(); txManager.begin(); Also, I'm not sure if transaction.commit() should remove any thread association with the transaction. -- 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: ConcurrentModificationException while starting AG1.1
Hi David, I just compared the file on your page with the file in one of my builds of G. It seems to be missing two files mbeans-descriptors.dtd and ant.properties. Was these files removed on purpose? Regards Manu On 5/9/06, Manu George [EMAIL PROTECTED] wrote: Thanks David. Can I take this jar (http://people.apache.org/~djencks/maven/commons-modeler/jars/commons-modeler-1.2-GERONIMO-SNAPSHOT.jar ) and replace the one in a previous version of G say 1.0? Will it be fine? Or do I have to do a rebuild? Regards ManuOn 5/9/06, David Jencks [EMAIL PROTECTED] wrote: I've put a private build of commons-modeler on my apache page and modified the g. build to use it. Could you rebuild g (you will need a clean build after dain's changes) and see if this CME is fixed?thanksdavid jencks On May 8, 2006, at 2:30 PM, David Jencks wrote:I've opened http://issues.apache.org/bugzilla/show_bug.cgi?id=39521for this and I wrote a patch to possibly fix it. I'm going to push a private jar for this and set up the g. build to use it.I also opened http://issues.apache.org/jira/browse/GERONIMO-1999 for us to track this problemthanksdavid jencksOn May 8, 2006, at 3:33 AM, Phani Madgula wrote: Hi,I am getting the following exception, quite unfrequently, may be once in 25 times, while starting AG1.1jvm 1 | 08:24:25,762 ERROR [Registry] Error registering Geronimo:type=Request Processor,worker=http-localhost%2F127.0.0.1-8453,name=HttpRequest0jvm 1 | java.util.ConcurrentModificationException: concurrent access to HashM ap attempted by Thread[http-localhost%2F127.0.0.1-8453-Processor25,5,main]jvm 1 | at java.util.HashMap.onEntry(HashMap.java :205)jvm 1 | at java.util.HashMap.transfer(HashMap.java:510)jvm 1 | at java.util.HashMap.resize (HashMap.java:500)jvm 1 | at java.util.HashMap.addEntry(HashMap.java:800)jvm 1 | at java.util.HashMap.put (HashMap.java:441)jvm 1 | at org.apache.commons.modeler.Registry.addManagedBean(Registry.java:457) jvm 1 | at org.apache.commons.modeler.Registry.loadDescriptors(Registry.java:938)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean(Registry.java:719)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean (Registry.java:1047)jvm 1 | at org.apache.commons.modeler.Registry.registerComponent(Registr y.java:859)jvm 1 | at org.apache.coyote.http11.Http11Protocol$JmxHttp11ConnectionHandler.init(Http11Protocol.java:175) jvm 1 | at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48) jvm 1 | at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686)jvm 1 | at java.lang.Thread.run(Thread.java:797)jvm 1 | 08:24:25,762 ERROR [Registry] Error loading jar:file:/D:/ccviews/d_sjc_tk4s_f5887_pathfinder_wasce_only/v3tools/thirdparty/was_ce/test/was- ce-1.1.0/repository/tomcat/tomcat-ajp/5.5.15/tomcat-ajp-5.5.15.jar!/org/apache/jk/mbeans-descriptors.xmljvm 1 | 08:24:25,762 WARN [Http11BaseProtocol] Error registering request I saw that the Registry class is not thread-safe. In the method, Http11Protocol:JmxHttp11ConnectionHandler:init()there is a call to Registry.getRegistry(null, null).registerComponent(rp, rpName, null) Should this be synchronized to resolve the problem? Can we synchronize it? Any suggestions?Regardsphani
[RT] blue-sky container
Hi all! My day-job company is in the process of refactoring our in-house-built middleware into something better(tm). That middleware is currently using plain Tomcat as a container and Spring for component configuration/wiring, publishing its services over SOAP. Due to increased requirements (uptime, clustering, monitoring, ease-of-maintenance, etc), we are looking into a major architecture redesign. Functionally, the middleware is a /telco-grade/ piece of software that is used to build services that interface with the (mobile) operator systems (billing, SMSC, positioning information, etc) and provide a user interface over a variety of channels (wap, web, SMS, MMS, etc). As an apache contributor, I would love to use (read: push ;-)) Geronimo as the base-container for this work. However, I'm not too familiar with the internals of Geronimo - so I would like to ask you to give me some feedback about the feasibility of this plan. I've written up my own blue sky vision/ideas for that future container (see attachment). It is lacking in details, but I guess you get some sort of fuzzy feeling about the thing I'm trying to get at :-) The aim could be summarized as: build a container that would be * simple for developer (no EJBs, stick to POJO's as much as possible) * simple for deployer/upgrader (container support for configuration management) * simple for OperationsMaintenance people (container support for monitoring, alarms) * easy to cluster (HA and load-balancing, no state in middle tier) in a reliable way (we have been throwing around the idea of routing all method calls over JMS) I know that everything is possible in the world of software development (given enough time and money :-)) so I would narrow my questions a bit: * is this thing a good fit, to be built on top of Geronimo? I guess yes. * maybe you can also give some arguments as to why Geronimo is a good fit for this? * and, going one step further, could you give some pointers as to how/where to start. And, a final question: would you be interested in at least some of these features? As far as I can see, most of the stuff outlined in my blue-sky vision is not really specific to our company/industry, it is applicable to java development/deployment in general. So, there could be interest also from the broader community in implementing this beast and our company might be interested in contributing back the generic parts of our work. What do you think? ;-) Rgds, Neeme Title: MO/RefactoringProducts/PinPoint50Ideas/BlueSkyFeatures - Regio Wiki MO/RefactoringProducts/PinPoint50Ideas/BlueSkyFeatures an artifact Piece of functionality packaged in a way that is ready for deployment. Consists of: version, unique identifier and type (maven2 metadata) compiled java classes - in the future this can be optional, as we have sources anyway. But initially it is more convenient to just use pre-compiled classes. java sources - used primarily for documentation and bug hunting, but can also be used for compiling JavaDoc documentation - can be generated from sources any metadata about the code that cannot be derived from the java classes and sources dependency declarations Proper artifact versioning is very important - it should be possible to determine the level of compatibility between any two versions by just comparing the version numbers. The whole concept is built on top of Maven2 project descriptors. CORE The function of CORE Publish a set of components (interfaces) to: the external world - (remote) clients can use services by including: a client library - publishes the component types (interfaces) that are publicly available a transport library - implements the details of accessing the (possibly remote) implementations over JMS/RMI/choose-your-own-transport. The simplest transport would be "no transport" - all services would be available inside the same JVM. the internal world - other components living inside the same container CORE can also be viewed as a "cloud" of middleware nodes in a cluster. Web applications and WSG would be examples of external clients that run outside the CORE. SMS handlers could be an example of internal clients that run inside the CORE (in their own "SMS-processor" component). In addition to hosting and publishing the components themselves, the container also manages a set of shared libraries that components can use to provide their services. a component Component consists of: a component type - a public interface (stored in artifact) through witch the internal functionality can be accessed one or more component implementations When a component implementation is deployed, the deployer can override any of the component runtime parameters. component implementation + runtime parameters = component deployment When component deployment is instantiated by the container (loaded into memory) it becomes a component instance. If allowed by the component implementation, the container
Re: ConcurrentModificationException while starting AG1.1
On May 8, 2006, at 11:25 PM, Manu George wrote:Hi David, I just compared the file on your page with the file in one of my builds of G. It seems to be missing two files mbeans-descriptors.dtd and ant.properties. Was these files removed on purpose?I just ran maven -o jar:install -Dmaven.test.skip=trueI have no idea how the 1.1 release was built. I can't see how ant.properties could be useful :-) and apparently mbeans-descriptors.dtd isn't actually needed?? Regards Manu On 5/9/06, Manu George [EMAIL PROTECTED] wrote: Thanks David. Can I take this jar (http://people.apache.org/~djencks/maven/commons-modeler/jars/commons-modeler-1.2-GERONIMO-SNAPSHOT.jar ) and replace the one in a previous version of G say 1.0? Will it be fine? Or do I have to do a rebuild?I think it will work in G 1.0 if you rename it to have version 1.1. It should work in any recent build of 1.1 just by adding it to the geronimo repository without renaming. Since it is used only by tomcat which I have not rebuilt I think its safe to say there are no interface changes since commons-modeler 1.1 :-)thanksdavid jencks Regards ManuOn 5/9/06, David Jencks [EMAIL PROTECTED] wrote: I've put a private build of commons-modeler on my apache page and modified the g. build to use it. Could you rebuild g (you will need a clean build after dain's changes) and see if this CME is fixed?thanksdavid jencks On May 8, 2006, at 2:30 PM, David Jencks wrote:I've opened http://issues.apache.org/bugzilla/show_bug.cgi?id=39521for this and I wrote a patch to possibly fix it. I'm going to push a private jar for this and set up the g. build to use it. I also opened http://issues.apache.org/jira/browse/GERONIMO-1999 for us to track this problemthanksdavid jencksOn May 8, 2006, at 3:33 AM, Phani Madgula wrote: Hi,I am getting the following exception, quite unfrequently, may be once in 25 times, while starting AG1.1jvm 1 | 08:24:25,762 ERROR [Registry] Error registering Geronimo:type=Request Processor,worker=http-localhost%2F127.0.0.1-8453,name=HttpRequest0jvm 1 | java.util.ConcurrentModificationException: concurrent access to HashM ap attempted by Thread[http-localhost%2F127.0.0.1-8453-Processor25,5,main]jvm 1 | at java.util.HashMap.onEntry(HashMap.java :205)jvm 1 | at java.util.HashMap.transfer(HashMap.java:510)jvm 1 | at java.util.HashMap.resize (HashMap.java:500)jvm 1 | at java.util.HashMap.addEntry(HashMap.java:800)jvm 1 | at java.util.HashMap.put (HashMap.java:441)jvm 1 | at org.apache.commons.modeler.Registry.addManagedBean(Registry.java:457) jvm 1 | at org.apache.commons.modeler.Registry.loadDescriptors(Registry.java:938)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean(Registry.java:719)jvm 1 | at org.apache.commons.modeler.Registry.findManagedBean (Registry.java:1047)jvm 1 | at org.apache.commons.modeler.Registry.registerComponent(Registr y.java:859)jvm 1 | at org.apache.coyote.http11.Http11Protocol$JmxHttp11ConnectionHandler.init(Http11Protocol.java:175) jvm 1 | at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.getInitData(LeaderFollowerWorkerThread.java:48) jvm 1 | at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:686)jvm 1 | at java.lang.Thread.run(Thread.java:797)jvm 1 | 08:24:25,762 ERROR [Registry] Error loading jar:file:/D:/ccviews/d_sjc_tk4s_f5887_pathfinder_wasce_only/v3tools/thirdparty/was_ce/test/was- ce-1.1.0/repository/tomcat/tomcat-ajp/5.5.15/tomcat-ajp-5.5.15.jar!/org/apache/jk/mbeans-descriptors.xmljvm 1 | 08:24:25,762 WARN [Http11BaseProtocol] Error registering request I saw that the Registry class is not thread-safe. In the method, Http11Protocol:JmxHttp11ConnectionHandler:init()there is a call to Registry.getRegistry(null, null).registerComponent(rp, rpName, null) Should this be synchronized to resolve the problem? Can we synchronize it? Any suggestions?Regardsphani
Re: [RT] blue-sky container
Hi NeemeOn 5/9/06, Neeme Praks [EMAIL PROTECTED] wrote: Hi all!My day-job company is in the process of refactoring our in-house-builtmiddleware into something better(tm). That middleware is currently using plain Tomcat as a container and Spring for componentconfiguration/wiring, publishing its services over SOAP. Due toincreased requirements (uptime, clustering, monitoring,ease-of-maintenance, etc), we are looking into a major architecture redesign.Functionally, the middleware is a /telco-grade/ piece of software thatis used to build services that interface with the (mobile) operatorsystems (billing, SMSC, positioning information, etc) and provide a user interface over a variety of channels (wap, web, SMS, MMS, etc).As an apache contributor, I would love to use (read: push ;-)) Geronimoas the base-container for this work. However, I'm not too familiar with the internals of Geronimo - so I would like to ask you to give me somefeedback about the feasibility of this plan.I've written up my own blue sky vision/ideas for that future container(see attachment). It is lacking in details, but I guess you get some sort of fuzzy feeling about the thing I'm trying to get at :-)The aim could be summarized as: build a container that would be * simple for developer (no EJBs, stick to POJO's as much as possible) FWIW the XBean kernel is a pure POJO kernel capable of wiring and deploying anything at all; we're deploying right now ActiveMQ, Jetty, OpenEJB, ServiceMix and XFire with it today - all using different kinds of deployment models and features - but the underlying core is the same - POJOs all the way up * simple for deployer/upgrader (container support for configuration management)We still need to do some work on XBean in this area but already we have a really super simple deployer/undeployer available. e.g. ServiceMix implements the full JBI based deployment model using JMX Ant tasks using XBean - though we can improve this * simple for OperationsMaintenance people (container support for monitoring, alarms)Yah. It also needs to be distributed too. One option is this...http://lingo.codehaus.org/JMX+over+JMS i.e. JMX over JMS so we can publish/subscribe to events etc * easy to cluster (HA and load-balancing, no state in middle tier) ina reliable way (we have been throwing around the idea of routing allmethod calls over JMS)If you want to take any POJO and cluster it over JMS to make a simple powerful computing grid, just a little bit of Spring.xml and this library does the trick nicely...http://lingo.codehaus.org/Clusteringcreating a distributed WorkManager or implementation of some POJO service is really trivial (it looks and feels just like Spring Remoting) I know that everything is possible in the world of software development (given enough time and money :-)) so I would narrow my questions a bit: * is this thing a good fit, to be built on top of Geronimo? I guess yes.Yes! :) * maybe you can also give some arguments as to why Geronimo is a goodfit for this?There's a community of like minded developers building using this stuff to do similar kinds of things in different areas so there's lots of reuse going on * and, going one step further, could you give some pointers as to how/where to start.A good start is maybe surfing XBean and Lingo And, a final question: would you be interested in at least some of thesefeatures? As far as I can see, most of the stuff outlined in my blue-skyvision is not really specific to our company/industry, it is applicable to java development/deployment in general. So, there could be interestalso from the broader community in implementing this beast and ourcompany might be interested in contributing back the generic parts of our work.What do you think? ;-)Sounds good to me :). A few more observations below (with much snipping of interesting stuff along the way...) an artifact Piece of functionality packaged in a way that is ready for deployment. Consists of: version, unique identifier and type (maven2 metadata) FWIW XBean has some support for putting the classpath or maven metadata in the XML configuration file itself, then allowing the kernel to boot up a classpath (downloading the necessary maven jars first) then applying the configuration in the right class loader. The classloader integration is there; the maven 2 integration needs a little bit of work but its really close compiled java classes - in the future this can be optional, as we have sources anyway. But initially it is more convenient to just use pre-compiled classes. java sources - used primarily for documentation and bug hunting, but can also be used for compiling JavaDoc documentation - can be generated from sources any metadata about the code that cannot be derived from the java classes and sources dependency declarations Agreed. FWIW I'm hoping we can all adopt this kinda annotation based metadata for dependency injection and lifecycle support to avoid us having compile time dependency on lifecycle APIs
[jira] Created: (GERONIMO-2000) PluginInstallerGBean generates invalid geronimo-plugin.xml files
PluginInstallerGBean generates invalid geronimo-plugin.xml files Key: GERONIMO-2000 URL: http://issues.apache.org/jira/browse/GERONIMO-2000 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Plugins Versions: 1.1 Reporter: Kristian Koehler When exporting a plugin via the console the PluginInstallerGBean generates an invalid geronimo-plugin.xml file. The GBean generates a config-id element which is not valid according to the plugins-1.1.xsd schema. Generated: geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name config-idgeronimo/activemq/1.1-SNAPSHOT/car/config-id categoryPlease provide a description/category ... Should be geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name module-idgeronimo/activemq/1.1-SNAPSHOT/car/module-id categoryPlease provide a description/category ... Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2000) PluginInstallerGBean generates invalid geronimo-plugin.xml files
[ http://issues.apache.org/jira/browse/GERONIMO-2000?page=all ] Kristian Koehler updated GERONIMO-2000: --- Attachment: PluginInstallerGBean.java.patch the patch PluginInstallerGBean generates invalid geronimo-plugin.xml files Key: GERONIMO-2000 URL: http://issues.apache.org/jira/browse/GERONIMO-2000 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Kristian Koehler Attachments: PluginInstallerGBean.java.patch When exporting a plugin via the console the PluginInstallerGBean generates an invalid geronimo-plugin.xml file. The GBean generates a config-id element which is not valid according to the plugins-1.1.xsd schema. Generated: geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name config-idgeronimo/activemq/1.1-SNAPSHOT/car/config-id categoryPlease provide a description/category ... Should be geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name module-idgeronimo/activemq/1.1-SNAPSHOT/car/module-id categoryPlease provide a description/category ... Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] blue-sky container
Hi Neeme, Your use case is perfect for Geronimo. You could start with little-g, or just Tomcat sitting in Geronimo and leverage some of the application services. You could also use the Web/ActiveMQ(JMS) in Geronimo and leverage that facility as well. You can build on and componentize your other needs by adding in plugins. Feel free to ask questions and bounce ideas as we would all be happy to help you leverage Geronimo and its services. Jeff Neeme Praks wrote: Hi all! My day-job company is in the process of refactoring our in-house-built middleware into something better(tm). That middleware is currently using plain Tomcat as a container and Spring for component configuration/wiring, publishing its services over SOAP. Due to increased requirements (uptime, clustering, monitoring, ease-of-maintenance, etc), we are looking into a major architecture redesign. Functionally, the middleware is a /telco-grade/ piece of software that is used to build services that interface with the (mobile) operator systems (billing, SMSC, positioning information, etc) and provide a user interface over a variety of channels (wap, web, SMS, MMS, etc). As an apache contributor, I would love to use (read: push ;-)) Geronimo as the base-container for this work. However, I'm not too familiar with the internals of Geronimo - so I would like to ask you to give me some feedback about the feasibility of this plan. I've written up my own blue sky vision/ideas for that future container (see attachment). It is lacking in details, but I guess you get some sort of fuzzy feeling about the thing I'm trying to get at :-) The aim could be summarized as: build a container that would be * simple for developer (no EJBs, stick to POJO's as much as possible) * simple for deployer/upgrader (container support for configuration management) * simple for OperationsMaintenance people (container support for monitoring, alarms) * easy to cluster (HA and load-balancing, no state in middle tier) in a reliable way (we have been throwing around the idea of routing all method calls over JMS) I know that everything is possible in the world of software development (given enough time and money :-)) so I would narrow my questions a bit: * is this thing a good fit, to be built on top of Geronimo? I guess yes. * maybe you can also give some arguments as to why Geronimo is a good fit for this? * and, going one step further, could you give some pointers as to how/where to start. And, a final question: would you be interested in at least some of these features? As far as I can see, most of the stuff outlined in my blue-sky vision is not really specific to our company/industry, it is applicable to java development/deployment in general. So, there could be interest also from the broader community in implementing this beast and our company might be interested in contributing back the generic parts of our work. What do you think? ;-) Rgds, Neeme * MO/RefactoringProducts/PinPoint50Ideas/BlueSkyFeatures an artifact Piece of functionality packaged in a way that is ready for deployment. Consists of: * version, unique identifier and type (maven2 metadata) * compiled java classes - in the future this can be optional, as we have sources anyway. But initially it is more convenient to just use pre-compiled classes. * java sources - used primarily for documentation and bug hunting, but can also be used for compiling * JavaDoc /wiki/JavaDoc documentation - can be generated from sources * any metadata about the code that cannot be derived from the java classes and sources * dependency declarations Proper artifact versioning is very important - it should be possible to determine the level of compatibility between any two versions by just comparing the version numbers. The whole concept is built on top of Maven2 project descriptors. CORE The function of CORE Publish a set of components (interfaces) to: * the external world - (remote) clients can use services by including: o a client library - publishes the component types (interfaces) that are publicly available o a transport library - implements the details of accessing the (possibly remote) implementations over JMS/RMI/choose-your-own-transport. The simplest transport would be no transport - all services would be available inside the same JVM. * the internal world - other components living inside the same container CORE can also be viewed as a cloud of middleware nodes in a cluster. * Web applications and WSG would be examples of external clients that run outside the CORE. * SMS handlers could be an example of internal clients that run
1.1 Package Upgrade List
Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
Re: 1.1 Package Upgrade List
Chime! TC - 5.5.15 Matt Hogstrom wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167to 1.4 jasper from 5.5.9to5.5.15 Jetty from5.1.9to5.1.10 stax from1.1.1-devto1.1.2 tranqlfrom1.2.1to1.3-SNAPSHOT tranql-connector from1.1to1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
Re: 1.1 Package Upgrade List
That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
Re: 1.1 Package Upgrade List
Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
[jira] Reopened: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1782?page=all ]
Paul McMahan reopened GERONIMO-1782:
I was able to reproduce the error using the provided instructions.
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: security
Versions: 1.0, 1.2, 1.1
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.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.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
at
org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432)
at
[jira] Updated: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1782?page=all ]
Paul McMahan updated GERONIMO-1782:
---
Attachment: GERONIMO-1782.patch
The problem is that when the updated LoginModuleSettings options are serialized
to config.xml the o.a.g.common.propertyeditor.PropertiesEditor inherits its
getAsText() method from PropertyEditorSupport, which simply returns the String
value of the Properties object. That inherited method does not provide a
string version of the properties object that is suitable for loading into a new
Properties object when the server restarts.
The attached patch overrides the getAsText() method, using Properites#store to
create the text value of the Properties object.
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: common
Versions: 1.0, 1.2, 1.1
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1
Attachments: GERONIMO-1782.patch
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.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.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
[jira] Updated: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1782?page=all ]
Paul McMahan updated GERONIMO-1782:
---
Patch Info: [Patch Available]
Component: common
(was: security)
changing component to common since problem is in o.a.g.common
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: common
Versions: 1.0, 1.2, 1.1
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1
Attachments: GERONIMO-1782.patch
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.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.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
at
org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
at
Re: 1.1 Package Upgrade List
On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload 1.1-dev to 1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9 to 5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). I'll start testing these versions once we clean up a few problems. --kevan Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1- dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
[jira] Assigned: (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 ] Prasad Kashyap reassigned GERONIMO-1641: Assign To: Prasad Kashyap 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.0 Reporter: Hernan Cunico Assignee: Prasad Kashyap Fix For: 1.1 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
Re: 1.1 Package Upgrade List
You are correct Kevan. Thanks Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). I'll start testing these versions once we clean up a few problems. --kevan Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1-dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
[jira] Created: (GERONIMO-2001) Eliminate unnecessary CRs in deployment and other messages
Eliminate unnecessary CRs in deployment and other messages -- Key: GERONIMO-2001 URL: http://issues.apache.org/jira/browse/GERONIMO-2001 Project: Geronimo Type: Bug Security: public (Regular issues) Components: deployment Versions: 1.1 Environment: windows XP Reporter: Joe Bohn Assigned to: Joe Bohn Priority: Minor Fix For: 1.1 There are a number of places (particularly in messages in response to deployments) where extra carriage returns are inserted into the output. This appears to be accidental. The DeployUtil.resolve() method already adds a CR to the end of every formatted line. However, when this is invoked from various places it appears to be 50/50 as to whether println or print is used. Of course println results in an extra CR being inserted into the message. For multi-line messages (such as when deploying an EAR that contains multiple modules) this can be annoying and at least one user has complained that this interfers with scripts that they are using to wrap the commands. This simply changes any printlns to prints for any messages that are printed using DeployUtil.format(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1532) NullPointerException when a badly named jar is put into repository directory
[ http://issues.apache.org/jira/browse/GERONIMO-1532?page=comments#action_12378678 ] Paul McMahan commented on GERONIMO-1532: verified that: 1.) manually placing a jar with a properly formatted name into the repo makes it appear in the db wizard's list of available drivers 2.) manually placing a jar with an improperly formatted name into the repo (at any location) does not cause an error in db wizard. The jar file is ignored. This JIRA can be closed unless further verification is desired. NullPointerException when a badly named jar is put into repository directory Key: GERONIMO-1532 URL: http://issues.apache.org/jira/browse/GERONIMO-1532 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Heikki Linnakangas Assignee: Aaron Mulder Priority: Critical Fix For: 1.1 Attachments: listURIs.diff I copied a JDBC driver jar to geronimo/repository-directory, thinking that geronimo would pick it up from there. What I didn't know, is that jars in the repository need to be named in a particular way. I then tried to add a Database pool using the wizard. I filled the name and type in step 1, and clicked next. Instead of step 2, I got a blank screen, and this stack trace in the log: 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) ... The culprit seems to be the FileSystemRepository.listURIs-method, that doesn't handle invalid filenames properly, but returns nulls in the array it returns instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1756) Move from 1.1-dev version of commons-fileupload to version 1.1
[ http://issues.apache.org/jira/browse/GERONIMO-1756?page=all ] Matt Hogstrom reassigned GERONIMO-1756: --- Assign To: Matt Hogstrom Move from 1.1-dev version of commons-fileupload to version 1.1 -- Key: GERONIMO-1756 URL: http://issues.apache.org/jira/browse/GERONIMO-1756 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: John Sisson Assignee: Matt Hogstrom Fix For: 1.1, 1.2 Now that a formal release is available we should move it it as we are currently using a 1.1-dev build and I have no idea what revision that was built from, which makes it hard to debug! Version 1.1 of commons-fileupload was released on 22 Dec 2005 - http://jakarta.apache.org/commons/fileupload/ The dependency commons-io will also need to be upgraded to 1.1 according to the commons-fileupload release notes http://jakarta.apache.org/commons/fileupload/changes-report.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-2001) Eliminate unnecessary CRs in deployment and other messages
[ http://issues.apache.org/jira/browse/GERONIMO-2001?page=all ] Joe Bohn updated GERONIMO-2001: --- Attachment: 2001_FormatMessages.patch patch was created on windows xp from geronimo root Eliminate unnecessary CRs in deployment and other messages -- Key: GERONIMO-2001 URL: http://issues.apache.org/jira/browse/GERONIMO-2001 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: windows XP Reporter: Joe Bohn Assignee: Joe Bohn Priority: Minor Fix For: 1.1 Attachments: 2001_FormatMessages.patch There are a number of places (particularly in messages in response to deployments) where extra carriage returns are inserted into the output. This appears to be accidental. The DeployUtil.resolve() method already adds a CR to the end of every formatted line. However, when this is invoked from various places it appears to be 50/50 as to whether println or print is used. Of course println results in an extra CR being inserted into the message. For multi-line messages (such as when deploying an EAR that contains multiple modules) this can be annoying and at least one user has complained that this interfers with scripts that they are using to wrap the commands. This simply changes any printlns to prints for any messages that are printed using DeployUtil.format(). -- 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 ] Prasad Kashyap updated GERONIMO-1641: - Attachment: G-1641.patch Please review and commit. 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.0 Reporter: Hernan Cunico Assignee: Prasad Kashyap Fix For: 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] Assigned: (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 ] Prasad Kashyap reassigned GERONIMO-1641: Assign To: Aaron Mulder (was: Prasad Kashyap) Please review patch and commit. 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.0 Reporter: Hernan Cunico Assignee: Aaron Mulder Fix For: 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-1900) Sample app links on welcome app are broken by default
[ http://issues.apache.org/jira/browse/GERONIMO-1900?page=all ] Prasad Kashyap updated GERONIMO-1900: - Attachment: welcome-7.patch Sample app links on welcome app are broken by default - Key: GERONIMO-1900 URL: http://issues.apache.org/jira/browse/GERONIMO-1900 Project: Geronimo Type: Bug Security: public(Regular issues) Components: usability, sample apps Versions: 1.1 Reporter: Aaron Mulder Assignee: Aaron Mulder Priority: Blocker Fix For: 1.1 Attachments: logo_head_570x86.gif, welcome-2.patch, welcome-3.patch, welcome-4.patch, welcome-6.patch, welcome-7.patch, welcome-images.jar, welcome.patch It would be nice to take users to a page that would prompt them to install the sample if they click a link to it and it's not present. However, automating this would require us to be able to construct a link into a portlet, which does not seem easy. For now, the welcome app can include pages at the locations where the sample apps will be bound, with text to the effect of: This sample has not yet been installed. To install it, visit the (URL)console(/URL) and select the Plugins page, click the Search for Plugins button, and select the (NAME HERE) sample to install. Then visit this same URL again to view the (NAME HERE) example. -- 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
undeploy, redeploy and hot-deploy
This refers to - http://issues.apache.org/jira/browse/GERONIMO-1945 and http://issues.apache.org/jira/browse/GERONIMO-1971 If a webapp with named myapp is deployed, It gets deployed as default/myapp//war. it is not possible to undeploy it with - java -jar bin\deployer.jar undeploy myapp It must be undeployed using : java -jar bin\deployer.jar undeploy default/myapp/explicit-version/war Here are my observations - 1. o.a.g.k.Repository.Artifact.create(id) does not allow id of the form myapp and throws exception. 2. A method almostMatch(Artifact a) (or a better name..) is needed that will match default/myapp//.. with default/myapp/explicit-version/war. This will allow us to undeploy using just myapp. This will also solve the problem with the hot-deployment in G-1947. 3. o.a.g.deployment.plugin.ConfigIdExtractor.identifyTargetModuleIDs(..) needs to call exactMatch in the 'second pass' so that default/myapp/explicit-version/war is returned in the list. Is this the correct approach? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Fwd: Re: Please change Open JPA to OpenJPA]
ROTFL Original Message Subject: Re: Please change Open JPA to OpenJPA Date: Tue, 9 May 2006 11:32:53 -0700 From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On May 9, 2006, at 2:14 AM, Leo Simons wrote: Riddle: What would Mr. SVN say if he was written in java? /me *ducks* and runs around the corner LSD I think he would say Gee what should I work on now, since I totally finished writing SVN like 2 years ago ;) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: undeploy, redeploy and hot-deploy
Please test again since Dain committed the patch yesterday. In my testing, this did allow undeploy myapp. If it doesn't work for you, can you give specific steps to reproduce the problem using the welcome sample application (applications/welcome/target/*.war and if needed, configs/welcome-jetty/target/plan/plan.xml). Thanks, Aaron On 5/9/06, anita kulshreshtha [EMAIL PROTECTED] wrote: This refers to - http://issues.apache.org/jira/browse/GERONIMO-1945 and http://issues.apache.org/jira/browse/GERONIMO-1971 If a webapp with named myapp is deployed, It gets deployed as default/myapp//war. it is not possible to undeploy it with - java -jar bin\deployer.jar undeploy myapp It must be undeployed using : java -jar bin\deployer.jar undeploy default/myapp/explicit-version/war Here are my observations - 1. o.a.g.k.Repository.Artifact.create(id) does not allow id of the form myapp and throws exception. 2. A method almostMatch(Artifact a) (or a better name..) is needed that will match default/myapp//.. with default/myapp/explicit-version/war. This will allow us to undeploy using just myapp. This will also solve the problem with the hot-deployment in G-1947. 3. o.a.g.deployment.plugin.ConfigIdExtractor.identifyTargetModuleIDs(..) needs to call exactMatch in the 'second pass' so that default/myapp/explicit-version/war is returned in the list. Is this the correct approach? Thanks Anita __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Updated: (GERONIMO-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Paul McMahan updated GERONIMO-1703: --- Attachment: ServerInfoWebApp_g1.1.war I'm attaching a new version of the WAR file that demonstrates the behavior, updated for the API and schema changes that have occurred in G1.1. My reading of the current ServerInfo javadoc implies that the API in question *should* return null unless the setting is specified in config.xml. /** * A config.xml setting for the base directory. This is normally * left null, which means the ServerInfo will use the Geronimo * install directory. */ public String getBaseDirectory(); However, I have a patch ready if there's consensus that the API should return the current base directory instead of null. This would make it redundant with the getCurrentBaseDirectory() API. If you want the patch then just let me know. 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: console Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Critical Fix For: 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-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Paul McMahan updated GERONIMO-1703: --- Component: startup/shutdown (was: console) Changing the component to startup/shutdown since the console's KernelManagementHelper method used to demonstrate the behavior in question has been removed from G1.1. The method for getting ServerInfo is now provided directly on the J2EEServer API. 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 Assignee: Aaron Mulder Priority: Critical Fix For: 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] Assigned: (GERONIMO-2001) Eliminate unnecessary CRs in deployment and other messages
[ http://issues.apache.org/jira/browse/GERONIMO-2001?page=all ] Matt Hogstrom reassigned GERONIMO-2001: --- Assign To: Matt Hogstrom (was: Joe Bohn) Eliminate unnecessary CRs in deployment and other messages -- Key: GERONIMO-2001 URL: http://issues.apache.org/jira/browse/GERONIMO-2001 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1 Environment: windows XP Reporter: Joe Bohn Assignee: Matt Hogstrom Priority: Minor Fix For: 1.1 Attachments: 2001_FormatMessages.patch There are a number of places (particularly in messages in response to deployments) where extra carriage returns are inserted into the output. This appears to be accidental. The DeployUtil.resolve() method already adds a CR to the end of every formatted line. However, when this is invoked from various places it appears to be 50/50 as to whether println or print is used. Of course println results in an extra CR being inserted into the message. For multi-line messages (such as when deploying an EAR that contains multiple modules) this can be annoying and at least one user has complained that this interfers with scripts that they are using to wrap the commands. This simply changes any printlns to prints for any messages that are printed using DeployUtil.format(). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-630) After broker has shutdown, cannot shutdown a client application
[ https://issues.apache.org/activemq/browse/AMQ-630?page=comments#action_36154 ] Kieran Murphy commented on AMQ-630: --- Is it possible to get this into the 4.0 release? After broker has shutdown, cannot shutdown a client application --- Key: AMQ-630 URL: https://issues.apache.org/activemq/browse/AMQ-630 Project: ActiveMQ Type: Bug Versions: 4.0 M4 Reporter: Kieran Murphy Fix For: 4.1 1. Bring up a broker 2. Bring up a client application which connects to the broker 3. Stop the broker. 4. Now try to stop the client app -- it will not shutdown until the broker is restarted. Using failover:tcp to connect to broker. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMODEVTOOLS-73) Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get to the server's publish directory
[
http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73?page=comments#action_12378753
]
Kathy Chan commented on GERONIMODEVTOOLS-73:
As discussed, Geronimo dev tools would implement:
public IPath getPublishDirectory(IModule[] module)
The input IModule[] would either contains one entry, which is the Web module or
two entries, where the first entry is the EAR module and the second entry is
the Web module.
Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get
to the server's publish directory
-
Key: GERONIMODEVTOOLS-73
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73
Project: Geronimo-Devtools
Type: Bug
Components: eclipse-plugin
Versions: 1.0.0
Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
Reporter: Kathy Chan
Assignee: Sachin Patel
After creating a Web service using the Web service wizard on a Web project
targetting Geronimo server, the file server-config.wsdd is generated in the
server installation config-store directory under WAR name/WEB-INF.
However, if I change something in the EAR and republish, the
server-config.wsdd file is gone. Note that the server-config.wsdd file is
not in the workspace.
I am relying on the IModulePublishHelper.getPublishDirectory() API in the
org.eclipse.wst.server.core plugin to get the server's publish directory in
order to copy the server-config.wsdd file into the workspace so that next
time the WAR/EAR is re-published, the information of what was deployed to the
Axis servlet is persisted.
Tomcat is currently implementing that and Geronimo needs to implement
IModulePublishHelper.getPublishDirectory() as well.
Here's the current implementation in TomcatBehaviour.getPublishDirectory():
/**
* Returns the path that the module is
* published to when in test environment mode.
*
* @param module a module on the server
* @return the path that the module is published to when in test
environment mode,
*or null if not running as a test environment or the module is not
a web module
*/
public IPath getPublishDirectory(IModule[] module) {
if (!getTomcatServer().isTestEnvironment() || module == null ||
module.length != 1)
return null;
return
getTempDirectory().append(webapps).append(module[0].getName());
}
This solution would solve the problem for getting to server-config.wsdd for
Axis Web service but there is still a bigger general problem with files
created in the config-store directory not mirrored in the workspace.
Hopefully this will be addressed in the next release of the Geronimo plugin.
--
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] Reopened: (GERONIMODEVTOOLS-73) Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get to the server's publish directory
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73?page=all ]
Sachin Patel reopened GERONIMODEVTOOLS-73:
--
Re-opening based on previous comment.
Geronimo needs to support IModulePublishHelper.getPublishDirectory() to get
to the server's publish directory
-
Key: GERONIMODEVTOOLS-73
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-73
Project: Geronimo-Devtools
Type: Bug
Components: eclipse-plugin
Versions: 1.0.0
Environment: WTP 1.0.1 + Geronimo 1.0 plugin + Geronimo 1.0 server
Reporter: Kathy Chan
Assignee: Sachin Patel
After creating a Web service using the Web service wizard on a Web project
targetting Geronimo server, the file server-config.wsdd is generated in the
server installation config-store directory under WAR name/WEB-INF.
However, if I change something in the EAR and republish, the
server-config.wsdd file is gone. Note that the server-config.wsdd file is
not in the workspace.
I am relying on the IModulePublishHelper.getPublishDirectory() API in the
org.eclipse.wst.server.core plugin to get the server's publish directory in
order to copy the server-config.wsdd file into the workspace so that next
time the WAR/EAR is re-published, the information of what was deployed to the
Axis servlet is persisted.
Tomcat is currently implementing that and Geronimo needs to implement
IModulePublishHelper.getPublishDirectory() as well.
Here's the current implementation in TomcatBehaviour.getPublishDirectory():
/**
* Returns the path that the module is
* published to when in test environment mode.
*
* @param module a module on the server
* @return the path that the module is published to when in test
environment mode,
*or null if not running as a test environment or the module is not
a web module
*/
public IPath getPublishDirectory(IModule[] module) {
if (!getTomcatServer().isTestEnvironment() || module == null ||
module.length != 1)
return null;
return
getTempDirectory().append(webapps).append(module[0].getName());
}
This solution would solve the problem for getting to server-config.wsdd for
Axis Web service but there is still a bigger general problem with files
created in the config-store directory not mirrored in the workspace.
Hopefully this will be addressed in the next release of the Geronimo plugin.
--
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
Corba tss and css examples
i'm going to comment out all the tss and css bean examples in j2ee- corba and client-corba. Including them was my idea in the first place and I think that it was a bad one: all these bean configurations are really specific to your security setup, so it is extremely unlikely any actual installation would use any of the provided beans. So, my plan is that the modules/configurations will contain only the name server, one or two orbs, and system properties to configure the orb. thanks david jencks
Re: Corba tss and css examples
+1 -dain On May 9, 2006, at 2:29 PM, David Jencks wrote: i'm going to comment out all the tss and css bean examples in j2ee- corba and client-corba. Including them was my idea in the first place and I think that it was a bad one: all these bean configurations are really specific to your security setup, so it is extremely unlikely any actual installation would use any of the provided beans. So, my plan is that the modules/configurations will contain only the name server, one or two orbs, and system properties to configure the orb. thanks david jencks
Re: Corba tss and css examples
Sounds good to me. I'm highly in favor of dropping things that end up being more like examples than actual useful services. Thanks, Aaron On 5/9/06, David Jencks [EMAIL PROTECTED] wrote: i'm going to comment out all the tss and css bean examples in j2ee- corba and client-corba. Including them was my idea in the first place and I think that it was a bad one: all these bean configurations are really specific to your security setup, so it is extremely unlikely any actual installation would use any of the provided beans. So, my plan is that the modules/configurations will contain only the name server, one or two orbs, and system properties to configure the orb. thanks david jencks
Startup messages with URLs
During Geronimo startup we print out all of the URLs for the web applications that are started. For example: Web Applications: http://127.0.0.1:8080/ http://127.0.0.1:8080/admin http://127.0.0.1:8080/none I'm working with the customer that is creating multiple connectors. They are questioning why the URLs only display for one of the connectors (and it appears to be random which connector is used). Is there a reason that we don't show the context path listed under each possible connector? StartupMonitorUtil currently queries each web module GBean for a URLFor attribute which is implemented in either TomcatWebAppContext or JettyWebAppContext depending upon the container. In that code we currently prefer to return the first connector that supports the HTTP protocol. If none are present we then prefer the HTTPS and finally AJP. However, we only return one URL for this query. Would it be helpful if I add a new collection attribute (URLsFor?) and query this attribute during startup so that we can print all possible URLs for the application or do you think this would be confusing? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Startup messages with URLs
I don't think it's all that useful to print 3+ URLs for each web app. Plus, we don't have the space in the startup output. Are you saying the customer has multiple HTTP connectors and it's random which one of those is selected? Is there any suggested logic for picking one? We could, for example, always pick the lowest port -- it would beat random if only by a little. Thanks, Aaron On 5/9/06, Joe Bohn [EMAIL PROTECTED] wrote: During Geronimo startup we print out all of the URLs for the web applications that are started. For example: Web Applications: http://127.0.0.1:8080/ http://127.0.0.1:8080/admin http://127.0.0.1:8080/none I'm working with the customer that is creating multiple connectors. They are questioning why the URLs only display for one of the connectors (and it appears to be random which connector is used). Is there a reason that we don't show the context path listed under each possible connector? StartupMonitorUtil currently queries each web module GBean for a URLFor attribute which is implemented in either TomcatWebAppContext or JettyWebAppContext depending upon the container. In that code we currently prefer to return the first connector that supports the HTTP protocol. If none are present we then prefer the HTTPS and finally AJP. However, we only return one URL for this query. Would it be helpful if I add a new collection attribute (URLsFor?) and query this attribute during startup so that we can print all possible URLs for the application or do you think this would be confusing? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
Re: Startup messages with URLs
Yes, the customer has multiple HTTP connectors. By random I mean that the customers gets different results than I get. When I run the scenario I always see the first connector that was deployed listed for the applications. When the customer runs the scenario they see the port for the last connector that was deployed in the URL. However, I believe that once a connector for a particular protocol is selected it is consistent for all applications listed at startup. In other words, if there are two HTTP connectors defined (say 8080 and 8090) then all applications are listed under just one of the connectors and not a mixture between the two (or at least that has been my experience and the code seems to back this up). I think it would be good if we could make this predictable in some way. Using the numeric value is certainly one. Using the deployment order of the connectors is another that I think is just as valid. Joe Aaron Mulder wrote: I don't think it's all that useful to print 3+ URLs for each web app. Plus, we don't have the space in the startup output. Are you saying the customer has multiple HTTP connectors and it's random which one of those is selected? Is there any suggested logic for picking one? We could, for example, always pick the lowest port -- it would beat random if only by a little. Thanks, Aaron On 5/9/06, Joe Bohn [EMAIL PROTECTED] wrote: During Geronimo startup we print out all of the URLs for the web applications that are started. For example: Web Applications: http://127.0.0.1:8080/ http://127.0.0.1:8080/admin http://127.0.0.1:8080/none I'm working with the customer that is creating multiple connectors. They are questioning why the URLs only display for one of the connectors (and it appears to be random which connector is used). Is there a reason that we don't show the context path listed under each possible connector? StartupMonitorUtil currently queries each web module GBean for a URLFor attribute which is implemented in either TomcatWebAppContext or JettyWebAppContext depending upon the container. In that code we currently prefer to return the first connector that supports the HTTP protocol. If none are present we then prefer the HTTPS and finally AJP. However, we only return one URL for this query. Would it be helpful if I add a new collection attribute (URLsFor?) and query this attribute during startup so that we can print all possible URLs for the application or do you think this would be confusing? Joe -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot -- Joe Bohn joe.bohn at earthlink.net He is no fool who gives what he cannot keep, to gain what he cannot lose. -- Jim Elliot
[jira] Closed: (GERONIMO-1893) Corba failures on startup
[ http://issues.apache.org/jira/browse/GERONIMO-1893?page=all ] David Jencks closed GERONIMO-1893: -- Resolution: Fixed The system properties for the keystore were missing: supplied in a SystemProperties gbean in the corba config. We should figure out how to use a keystore gbean instead. Also cleaned up configs by using dependencies instead of references to assure start order and commented out the sample css and tss beans. g. rev 405556 openejb rev 2651 Corba failures on startup - Key: GERONIMO-1893 URL: http://issues.apache.org/jira/browse/GERONIMO-1893 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.1 Environment: 1.1 Reporter: Kevan Miller Assignee: David Jencks Priority: Critical Fix For: 1.1 If you enable Corba in an out-of-the-box config -- you'll receive the following exceptions: 23:07:59,456 ERROR [SunORBConfigAdapter] org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 209 completed: No 23:07:59,624 WARN [CORBABean] Failed CORBABean 23:07:59,628 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=geronimo/j2ee-corba/1.1-SNAPSHOT/car?ServiceModule=geronimo/j2ee-corba/1.1-SNAPSHOT/car,j2eeType=CORBABean,name=Server org.openejb.corba.security.config.ConfigException: org.omg.CORBA.INTERNAL: vmcid: SUN minor code: 209 completed: No at org.openejb.corba.sunorb.SunORBConfigAdapter.postProcess(SunORBConfigAdapter.java:211) at org.openejb.corba.CORBABean.doStart(CORBABean.java:160) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:980) 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.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) 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.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) at org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) at org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) at org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:539) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:389) at org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:350) at org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:168) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:483) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:464) at org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
Re: [Fwd: Re: Please change Open JPA to OpenJPA]
ooh - sorry - I didn't mean to crosspost that was just meant for dain... I need ot fix Thunderbird's auto completion db... Geir Magnusson Jr wrote: ROTFL Original Message Subject: Re: Please change Open JPA to OpenJPA Date: Tue, 9 May 2006 11:32:53 -0700 From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: general@incubator.apache.org To: general@incubator.apache.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On May 9, 2006, at 2:14 AM, Leo Simons wrote: Riddle: What would Mr. SVN say if he was written in java? /me *ducks* and runs around the corner LSD I think he would say Gee what should I work on now, since I totally finished writing SVN like 2 years ago ;) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.1 Package Upgrade List
I've built locally using HOWL 1.0.1 and it seems to work fine with no geronimo changes. I think the main problem will be getting it onto a suitable maven repo: I haven't found it to be released anywhere. Is pushing it into a m2 repo sufficient, are jars auto-backported into m1? thanks david jencks On May 9, 2006, at 10:22 AM, Matt Hogstrom wrote: You are correct Kevan. Thanks Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). I'll start testing these versions once we clean up a few problems. --kevan Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1- dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this
Re: 1.1 Package Upgrade List
Moving to Commons-Fileupload 1.1 also requires upgrading to commons-io 1.2. Also, why are we upgrading to STAX 1.1.1, when all we need is just the STAX API? -Donald David Jencks wrote: I've built locally using HOWL 1.0.1 and it seems to work fine with no geronimo changes. I think the main problem will be getting it onto a suitable maven repo: I haven't found it to be released anywhere. Is pushing it into a m2 repo sufficient, are jars auto-backported into m1? thanks david jencks On May 9, 2006, at 10:22 AM, Matt Hogstrom wrote: You are correct Kevan. Thanks Kevan Miller wrote: On May 9, 2006, at 12:42 PM, Matt Hogstrom wrote: Consolidated list so far is: Axis from 1.4-356167 to 1.4 commons-fileupload1.1-devto1.1 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 Tomcat 5.5.9to5.5.15 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT We're already on Tomcat 5.5.15, but fine to keep it on the list. I assume the final tranql and tranql-connector versions will be 1.3 and 1.2. We'll use the SNAPSHOT versions until a new tranql release is published (which will happen before we ship 1.1...). I'll start testing these versions once we clean up a few problems. --kevan Keep 'em coming. Matt Aaron Mulder wrote: That issue has a great list. We definitely need to try updating commons-fileupload (from 1.1- dev to 1.1). I think there may even be a separate Jira for that. But the old one occasionally hangs, so it's definitely worth trying the new one. Thanks, Aaron On 5/9/06, Matt Hogstrom [EMAIL PROTECTED] wrote: Here are the packages I'm recommending for 1.1. If I missed one please chime in. Axis from 1.4-356167 to 1.4 jasper from 5.5.9 to 5.5.15 Jetty from 5.1.9 to 5.1.10 stax from 1.1.1-dev to 1.1.2 tranql from1.2.1 to 1.3-SNAPSHOT tranql-connector from 1.1 to 1.2-SNAPSHOT This is the list so far...I've updated http://opensource.atlassian.com/confluence/oss/display/GERONIMO/ Geronimo+Package+Tracking with this information. Was mentioned on the list: Howl- Researching this smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1782?page=all ]
Paul McMahan updated GERONIMO-1782:
---
Attachment: AbstractMapEditorTest.java
PropertiesEditorTest.java
attaching new unit tests for PropertiesEditor
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: common
Versions: 1.0, 1.2, 1.1
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1
Attachments: AbstractMapEditorTest.java, GERONIMO-1782.patch,
PropertiesEditorTest.java
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.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.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
at
org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
at
[jira] Updated: (GERONIMO-2000) PluginInstallerGBean generates invalid geronimo-plugin.xml files
[ http://issues.apache.org/jira/browse/GERONIMO-2000?page=all ] Donald Woods updated GERONIMO-2000: --- Fix Version: 1.1 Priority: Critical (was: Major) Updating priority, as this needs to get into 1.1 PluginInstallerGBean generates invalid geronimo-plugin.xml files Key: GERONIMO-2000 URL: http://issues.apache.org/jira/browse/GERONIMO-2000 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Plugins Versions: 1.1 Reporter: Kristian Koehler Priority: Critical Fix For: 1.1 Attachments: PluginInstallerGBean.java.patch When exporting a plugin via the console the PluginInstallerGBean generates an invalid geronimo-plugin.xml file. The GBean generates a config-id element which is not valid according to the plugins-1.1.xsd schema. Generated: geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name config-idgeronimo/activemq/1.1-SNAPSHOT/car/config-id categoryPlease provide a description/category ... Should be geronimo-plugin xmlns=http://geronimo.apache.org/xml/ns/plugins-1.1; namegeronimo/activemq/1.1-SNAPSHOT/car/name module-idgeronimo/activemq/1.1-SNAPSHOT/car/module-id categoryPlease provide a description/category ... Kristian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1971) Redeployment of webapp without geronimo plan fails
[ http://issues.apache.org/jira/browse/GERONIMO-1971?page=all ] Anita Kulshreshtha resolved GERONIMO-1971: -- Resolution: Fixed This has been fixed by Dain in rev. 405556. I have tested the following sequence using the same app- deploy, undeploy , deploy, redeploy, undeploy They are working fine Redeployment of webapp without geronimo plan fails -- Key: GERONIMO-1971 URL: http://issues.apache.org/jira/browse/GERONIMO-1971 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Reporter: Erin Mulder Priority: Blocker Fix For: 1.1 I deployed an exploded web app (with no geronimo-web.xml) using the command-line deployer. A few minutes later, I tried to redeploy it and got an error. See below. [EMAIL PROTECTED]:~/dev/examples java -jar ~/dev/geronimo-1.1/jetty/bin/deployer.jar deploy simple_web_app Deployed default/simple_web_app/1146631722307/war @ http://wildfire:8080/simple_web_app [EMAIL PROTECTED]:~/dev/examples java -jar ~/dev/geronimo-1.1/jetty/bin/deployer.jar redeploy simple_web_app No ModuleID or TargetModuleID provided. Attempting to guess based on the content of the archive. Unable to locate Geronimo deployment plan in archive. Calculating default ModuleID from archive name. Attempting to use ModuleID 'simple_web_app' Exception in thread main java.lang.IllegalArgumentException: Invalid id: simple_web_app at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:168) at org.apache.geronimo.deployment.cli.AbstractCommand.identifyTargetModuleIDs(AbstractCommand.java:149) at org.apache.geronimo.deployment.cli.CommandRedeploy.execute(CommandRedeploy.java:128) at org.apache.geronimo.deployment.cli.DeployTool.execute(DeployTool.java:158) at org.apache.geronimo.deployment.cli.DeployTool.main(DeployTool.java:312) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2002) OpenEJB CORBA SSL should use Keystore GBean
OpenEJB CORBA SSL should use Keystore GBean --- Key: GERONIMO-2002 URL: http://issues.apache.org/jira/browse/GERONIMO-2002 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: security, CORBA Versions: 1.1 Reporter: Aaron Mulder Fix For: 1.1 OpenEJB initializes CORBA using a plain SSL socket factory and therefore only sees SSL keystore/trust store settings configured as system properties. We should change this to use the KeystoreManager API instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1947) Repeat hot deployment of WARs with no Geronimo plan
[ http://issues.apache.org/jira/browse/GERONIMO-1947?page=all ] Anita Kulshreshtha resolved GERONIMO-1947: -- Resolution: Fixed This has been fixed by Dain in rev. 405570. I have tested using no-geronimo-plan.war - . hot deploy, . stop the server and . restart the server. Repeat hot deployment of WARs with no Geronimo plan --- Key: GERONIMO-1947 URL: http://issues.apache.org/jira/browse/GERONIMO-1947 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.0 Environment: Linux, Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode) Reporter: Erin Mulder Priority: Critical Fix For: 1.1 Attachments: no-geronimo-plan.war I created a WAR with no deployment plan (see attached no-geronimo-plan.war) and copied it to the hot deployment directory. Now, every time I start the server, it tries to deploy it again with a different version number. It does get an error at that point, but the console is showing N copies and the startup sequence is showing N-1, where N is the number of server restarts since I originally deployed it. Here's a snippet from the console: Component NameURL State Commands default/no-geronimo-plan/1146368518972/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368650976/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146368847429/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146369719473/war/no-geronimo-plan running Stop Uninstall default/no-geronimo-plan/1146370013515/war/no-geronimo-plan running Stop Uninstall Here's what it looks like at startup: Booting Geronimo Kernel (in Java 1.4.2_11)... Starting Geronimo Application Server v.1.1-SNAPSHOT [**] 100% 22s Startup complete Listening on Ports: 1099 0.0.0.0 RMI Naming 1527 0.0.0.0 Derby Connector 4201 0.0.0.0 ActiveIO Connector EJB 4242 127.0.0.1 Remote Login Listener 8019 127.0.0.1 Jetty Connector AJP13 8080 0.0.0.0 Jetty Connector HTTP 8443 0.0.0.0 Jetty Connector HTTPS 0.0.0.0 JMX Remoting Connector 61616 0.0.0.0 ActiveMQ Message Broker Connector Started Application Modules: EAR: geronimo/webconsole-jetty/1.1-SNAPSHOT/car RAR: geronimo/activemq/1.1-SNAPSHOT/car RAR: geronimo/system-database/1.1-SNAPSHOT/car WAR: default/no-geronimo-plan/1146368518972/war WAR: default/no-geronimo-plan/1146368650976/war WAR: default/no-geronimo-plan/1146368847429/war WAR: default/no-geronimo-plan/1146369719473/war WAR: geronimo/remote-deploy-jetty/1.1-SNAPSHOT/car WAR: geronimo/welcome-jetty/1.1-SNAPSHOT/car Web Applications: http://wildfire:8080/ http://wildfire:8080/console http://wildfire:8080/console-standard http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/no-geronimo-plan http://wildfire:8080/remote-deploy Geronimo Application Server started 00:06:49,487 ERROR [DirectoryMonitor] Unable to scan file /files/dev/geronimo-1.1/assemblies/j2ee-jetty-server/target/geronimo-1.1-SNAPSHOT/deploy/no-geronimo-plan.war during initialization java.lang.IllegalArgumentException: Invalid id: no-geronimo-plan at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.plugin.ConfigIDExtractor.identifyTargetModuleIDs(ConfigIDExtractor.java:168) at org.apache.geronimo.deployment.hot.DirectoryHotDeployer.isFileDeployed(DirectoryHotDeployer.java:166) at org.apache.geronimo.deployment.hot.DirectoryMonitor.initialize(DirectoryMonitor.java:191) at org.apache.geronimo.deployment.hot.DirectoryMonitor.run(DirectoryMonitor.java:169) at java.lang.Thread.run(Thread.java:534) 00:06:53,496 INFO [Hot Deployer] Deploying no-geronimo-plan.war 00:06:53,840 WARN [JettyModuleBuilder] Web application does not contain a WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, depending on whether you have things like resource references that need to be resolved. You can also give the deployer a separate deployment plan file on the command line. Deployed default/no-geronimo-plan/1146370013515/war @ http://wildfire:8080/no-geronimo-plan I'll clean out the server and try to reproduce from scratch. -- 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:
OpenWire - asynchronous consumption
On the page http://activemq.codehaus.org/OpenWire+dotNet, the asynchronous consumption examples aren't available (unable to download) - can we have a fix? Otherwise, could someone kindly post these examples or other. Thanks -- View this message in context: http://www.nabble.com/OpenWire---asynchronous-consumption-t1582866.html#a4295586 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Updated: (SM-403) The JMS spec mandates that all properties on JMS message are valid java identifiers
[ https://issues.apache.org/activemq/browse/SM-403?page=all ] Guillaume Nodet updated SM-403: --- Summary: The JMS spec mandates that all properties on JMS message are valid java identifiers (was: The JBI spec mandates that all properties on JMS message are valid java identifiers) The JMS spec mandates that all properties on JMS message are valid java identifiers Key: SM-403 URL: https://issues.apache.org/activemq/browse/SM-403 Project: ServiceMix Type: Bug Components: servicemix-jms Reporter: Guillaume Nodet -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-397) WSA:Action header should override default service/endpoint values from the http endpoint definition
[ https://issues.apache.org/activemq/browse/SM-397?page=all ] Guillaume Nodet resolved SM-397: Fix Version: 3.0-M2 Resolution: Fixed Assign To: Guillaume Nodet Found a simple way to do that while keeping backward compatibility Author: gnodet Date: Tue May 9 04:39:17 2006 New Revision: 405392 URL: http://svn.apache.org/viewcvs?rev=405392view=rev Log: SM-397: WSA:Action header should override default service/endpoint values from the http endpoint definition Modified: incubator/servicemix/trunk/servicemix-soap/src/main/java/org/apache/servicemix/soap/SoapHelper.java WSA:Action header should override default service/endpoint values from the http endpoint definition --- Key: SM-397 URL: https://issues.apache.org/activemq/browse/SM-397 Project: ServiceMix Type: Bug Components: servicemix-http Versions: 3.0-M2 Reporter: Ilya Kuleshov Assignee: Guillaume Nodet Fix For: 3.0-M2 Manual says that although service and endpoint attributes are required by the consumer endpoint definition of http-component, it is possible to use WS-Addressing to set custom target for the SOAP message. When I use the WSA:To header then value from this header overrides default service/endpoint correctly. On the other side, when I use the WSA:Action header then http-component sets destination interface/operation attributes of the message as expected but leaves service/endpoint attributes from the http endpoint definition. This results into routing problems because the JBI message now has interface, operation, service and endpoint attributes set altogether. -- 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
