Re: ServiceMix 4.0 api
Btw, I have uploaded the site for the whole project which is easier to manage. http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ Cheers, Guillaume Nodet On Aug 28, 2007, at 12:11 AM, Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Best regards, Piotr On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? Cheers, Guillaume Nodet On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Btw, if there is sufficient interest, we could organize irc meetings to discuss these topics and post the log to the dev list for archiving and later discussion. Cheers, Guillaume Nodet On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/ incubator/servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a component that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel component would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service name, interface name, wsdl location, etc..). These metadatas could be used to retrieve targets using the Registry. We could plug in different mechanisms to
Re: ServiceMix 4.0 api
I have committed a simple test showing how to expose an endpoint and how to communicate with it. See http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/core/src/test/java/org/apache/servicemix/core/ IntegrationTest.java How does it sounds ? Cheers, Guillaume Nodet On Aug 28, 2007, at 12:11 AM, Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet
Re: ServiceMix 4.0
Thanks Chris ! It seems like the experts have answered... So i guess we will switch to slf4j :-) Cheers, Guillaume Nodet On 8/28/07, Chris Custine [EMAIL PROTECTED] wrote: You are correct about OSGi having more control over classloaders, but in the case of JCL things are a little different. Below is a link to the mailing list thread where we went through all of this pain on the Spring-OSGi project and decided to replace JCL with the slf4j facade in order to eliminate the side effects caused by Spring using JCL. I think Spring-OSGi uses slf4j natively now because of this and I believe it has been a consideration for Spring itself to move to it, but I am not sure of the final outcome of that discussion. http://tinyurl.com/3axajc I think the thread was cross posted to Equinox as well and a discussion occured there... Just google commons logging madness :-) As you said about OSGi being flexible, one nice thing about using slf4j in OSGi is that you can have all implementation bundles (slf4j-log4j, slf4j-jdk14, etc.) available in the container, and it is up to each bundle to specify which one it imports, thereby adding it to the classloader wiring. I can't remember if that is built in functionality of slf4j or if it is something that I made work, but it is all done with manifest headers so it is easy to do if its not shipped like that. Good luck! Chris On 8/27/07, Nodet Guillaume [EMAIL PROTECTED] wrote: I would say the opposite. The OSGi classloaders are much more powerful and you can more easily control the visibility of classes. In addition, if JCL is required by a given bundle A, it does not mean that it will be visible by a bundle using bundle A. Obviously, this means to be tested (or maybe OSGi experts could help there...) Cheers, Guillaume Nodet On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: Also, moving toward an architecture based on OSGi almost guarantees that we will run into classloader issues with JCL. Bruce -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=12323536framed=yskin=12049 We will use the standard IRC channel: see http://incubator.apache.org/servicemix/irc.html I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Before switching to mac, I was using xchat. See http://www.xchat.org/ Cheers, Guillaume Nodet Best regards, Piotr On 8/24/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Any other people interested ? Cheers, Guillaume Nodet On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: I'd be up for a few chat sessions! On 8/23/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Btw, if there is sufficient interest, we could organize irc meetings to discuss these topics and post the log to the dev list for archiving and later discussion. Cheers, Guillaume Nodet On Aug 22, 2007, at 4:59 PM, Nodet Guillaume wrote: As I explained in the other thread, I've been working on a new API for ServiceMix 4.0. Hopefully this will serve as an input for JBI 2.0. This API is available at https://svn.apache.org/repos/asf/ incubator/servicemix/branches/servicemix-4.0/api So here a few key changes: * clean integration with OSGi * the NormalizedMessage can contain not only XML * no more components * no more JBI packaging (just use OSGi bundles) * move the Channel to the Endpoint * use push delivery instead of pulling exchanges * introduce a single interface for identifying the Target of an Exchange As we remove components, everything goes down to the endpoint which become a key feature. The endpoint must implement the Endpoint interface. In OSGi, the NMR would listen to endpoints registered in the OSGi registry and call the registry to register / unregister the endpoints. As part of the endpoint registration, the NMR would inject a Channel into them, thus actually activating the endpoint. I guess I could write a sequence diagram for that (anybody knows a good tool for uml ?). In a non OSGI environment, the Endpoint will be registered in the Registry by calling the register method somehow. The Endpoint receives Exchange to be processed on the process method. I think we should keep the JBI 1.0 semantics and the endpoint use the same process as for JBI 1.0, which is send the exchange back using the Channel (with the response / fault / error / done). This will put the threading, transactions and security burden on the container itself. Which means it is easier to write JBI apps :-) Exchanges can be created using the Channel#createExchange method. The only change I'd like to integrate in the messaging API is to allow for non xml payloads and maybe untyped attachments. The body could be converted automatically to a given type if supported (I think Camel does it nicely, so I'm thinking of shamelessly copying the converter layer). I have added a few helper methods on the exchanges and messages (copy, copyFrom, ensureReReadable, display) to ease message management. For the deployment part, there is no packaging anymore. One would deploy an OSGi bundle that would register the needed endpoints in the OSGi registry. For certain types of endpoints, we may need an external activation process (such as creating a server socket for listening to HTTP requests) that may need to be shared across endpoints of a given type. In such a case, you would deploy a component that listens to new endpoints implementing HttpEndpoint for example. When a new endpoint is registered, the listener would activate a server socket that could be shared across all http endpoints. In a different way, if we have a BPEL engine, the bpel component would listen for new bundles and look for a specific file containing deployment information. The component would register new endpoints in the OSGi registry as needed (we could do that for jaxws pojos using cxf for example). So I said there is no more components, because this feature is not in the api anymore, but we will certainly need these components for some use cases. For simple endpoints, you would not need any component at all. Another benefit is that you can easily deploy a whole application inside a single OSGi bundle. Using spring-osgi, the bundle would just consist in a spring configuration file containing the endpoints declaration and expose them as OSGi services. Of course, we need to write a JBI 1.0 compatibility layer, and we could have an intermediate layer where SAs and JBI components could be OSGi bundles directly, thus leveraging the OSGi classloading mechanism. The thing I'm not completely sure about if the Target interface which aims to identify the target of an exchange. I'm thinking that some metadata are associated with endpoints (like service
Re: ServiceMix 4.0 api
Hello Guillaume, I am getting a page not found with the javadoc site. Regards, Gordon Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet .
Re: ServiceMix 4.0 api
Yeah, i moved it. Try http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ The direct link to the api is: http://people.apache.org/~gnodet/servicemix-4.0-SNAPSHOT/ org.apache.servicemix.api/apidocs/index.html Cheers, Guillaume Nodet On Aug 28, 2007, at 3:02 PM, Gordon Dickens wrote: Hello Guillaume, I am getting a page not found with the javadoc site. Regards, Gordon Nodet Guillaume wrote: I've refactored a few things in the api and introduced back the listeners and flows. For those who prefer to read javadoc, take a look at: http://people.apache.org/~gnodet/servicemix-4.0/site/apidocs/ The javadoc is quite low on comments right now, so if any area appears to be unclear, ask for comments and I will improve the doc asap. Although any ideas, feedback, patches are always welcome. To test the API, I have started a really dumb implementation of it in the branch, but don't expect much at this point ;-) http://svn.apache.org/repos/asf/incubator/servicemix/branches/ servicemix-4.0/ Cheers, Guillaume Nodet .
Re: IRC session
+3 ok. On 8/28/07, Kit Plummer [EMAIL PROTECTED] wrote: On 8/28/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ +2 ; } -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: New GShell-based Geronimo Server launcher now in server/trunk
On Aug 27, 2007, at 8:28 PM, Prasad Kashyap wrote: I wanted to see how much Jason really really luvs Windows. So I began trying GShell on that OS :-) First, I was surprised it even had batch files to support Windows users. Thanx Jason. You really have gone out of your way :-)... Just kidding ! gsh.bat had a small typo. svn commit: r570296 fixes that. Next, in the interactive mode, I tried start-server help. It threw the following error start-server help 23:02:42,030 ERROR [InteractiveConsole] Error java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:124) I'll try to debug this tomorrow morning. However, I believe GShell will be of great use/help when we want to build a stackable server starting from a bare-bones framework that won't even have a console. For this we'll need plugin install capabilities in the GShell. Go Jason, Go ! Whether you like it or not, there's a sizeable number of our users who will be on Windows. And whether I like it or not, I or somebody will have to try our popular features on that hated OS :-( Ya, I am aware of the very, very, very sad and unfortunate fact... those poor users. Anyways, GShell should help us build more portable fluff for them, since we can code the platform specifics directly in Java. I'm not sure what the above exception is from, I'll fire up a build on my windows system and see what it pukes up. --jason
Re: New GShell-based Geronimo Server launcher now in server/trunk
Well, I'm not sure why you are seeing that evil NCDFE still... though I did find a wee bug in the --help/-h processing for the start-server command. Basically what you tried is not a valid option to the command, ie start-server help is a syntax error. Instead you probably wanted to say start-server --help. --jason On Aug 27, 2007, at 8:28 PM, Prasad Kashyap wrote: I wanted to see how much Jason really really luvs Windows. So I began trying GShell on that OS :-) First, I was surprised it even had batch files to support Windows users. Thanx Jason. You really have gone out of your way :-)... Just kidding ! gsh.bat had a small typo. svn commit: r570296 fixes that. Next, in the interactive mode, I tried start-server help. It threw the following error start-server help 23:02:42,030 ERROR [InteractiveConsole] Error java.lang.NoClassDefFoundError: groovy/lang/GroovyObject at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:124) I'll try to debug this tomorrow morning. However, I believe GShell will be of great use/help when we want to build a stackable server starting from a bare-bones framework that won't even have a console. For this we'll need plugin install capabilities in the GShell. Go Jason, Go ! Whether you like it or not, there's a sizeable number of our users who will be on Windows. And whether I like it or not, I or somebody will have to try our popular features on that hated OS :-( Cheers Prasad On 8/21/07, Jason Dillon [EMAIL PROTECTED] wrote: Hiya folks, I finally got around to finishing up my POC of using GShell to launch the Geronimo Server and I have committed the bits that make it work to server/trunk. The new module which contains the GShell command implementation (and support) classes is: modules/geronimo-commands And a new assembly which has the GShell bits all in place for folks to test with is: assemblies/geronimo-jetty6-javaee5-gshell The assembly is not hooked up by default, but the code module is. So, to test it out, you need to do something like: svn co https://svn.apache.org/repos/asf/geronimo/server/trunk server cd server mvn assemblies/geronimo-jetty6-javaee5-gshell mvn Then unzip the assembly: unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip And then finally try it out. First lets get the basic GShell command- line help: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help This should spit out something like: snip _ _ _ / ___/ ___|| |__ ___| | | | | _\___ \| '_ \ / _ \ | | | |_| |___) | | | | __/ | | \|/|_| |_|\___|_|_| GShell -- Geronimo command-line shell usage: gsh [options] command [args] -n,--non-interactiveRun in non-interactive mode -D,--define name=valueDefine a system property -V,--versionDisplay GShell version -c,--commands string Read commands from string -debug,--debug Enable DEBUG logging output -h,--help Display this help message -i,--interactiveRun in interactive mode -quiet,--quiet Limit logging output to ERROR -verbose,--verbose Enable INFO logging output /snip Then lets run the interactive-shell: ./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh This should leave you at a very plain prompt at the moment: snip _ /snip At this point you can type something like this to list all of the known commands: snip help commands /snip Which should spit back: snip Available commands (and aliases): start-server ( start ) set exit ( quit, bye ) unset source help /snip The command that I added is called 'start-server', with an alias of 'start'. This is basically an augmented and enhanced version of what the geronimo:start-server goal does in the geronimo-maven-plugin. To see its options run this: snip start-server --help /snip And it says: snip start-server -- Starts a new Geronimo server instance usage: start-server [options] -A,--javaagent jar Use a specific Java Agent, set to 'none' to disable -D,--property name=valueSet a system property -H,--home dir Use a specific Geronimo home directory -J,--javaopt option Set a JVM flag -b,--background Run the server process in the background. -h,--help Display this help message -j,--jvm dirUse a specific Java Virtual Machine for server process -l,--logfile file Capture console output to file -m,--module nameStart up a specific module by name. -q,--quietSuppress informative and warning messages
Re: Adding j2g to site
Matt, Feature-wise, I think it'd be ready to take on the 1.0 nomenclature but I'd rather wait until when/if it gets moved out of sandbox. -- Jason Warner On 8/27/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Erik, Jason and Viet. This is really good. Since we're making a SNAPSHOT available is there some point where we should declare a 1.0 ? On Aug 23, 2007, at 4:30 PM, Erik B. Craig wrote: All, After the recent round of changes and improvements around j2g (usable from within the Eclipse IDE UI, Annotations support, improved logging/information output, support for EJB 3), as well as a bit of interest out in the general open source community in moving applications from Jboss to Geronimo (such as today's inquiry on theserverside.com), I feel as though it would be of some benefit to have j2g, at least the content in our confluence wiki (http://cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked somewhere on the actual geronimo homepage. I was thinking either as it's own link under 'Subprojects', much as Development Tools, GBuild, or XBean are situated, or as an addition inside the Development Tools page, much as the current Eclipse Plug-in section rests within there. I am willing to commit to doing a bit of additional writing (beyond what is on the wiki) if it were to be under it's own section, or a subsection of development tools if necessary, but I think it would be good to get it up and out there sooner rather than later, especially to coincide with the recent release of 2.0.1 to perhaps show those out there remotely interested in migrating, there are tools available to assist and perhaps 'hold their hand' a bit. Thoughts? Comments? Objections? Thanks -- Erik B. Craig
Re: Adding j2g to site
Seconding Jason's take on this. On 8/28/07, Jason Warner [EMAIL PROTECTED] wrote: Matt, Feature-wise, I think it'd be ready to take on the 1.0 nomenclature but I'd rather wait until when/if it gets moved out of sandbox. -- Jason Warner On 8/27/07, Matt Hogstrom [EMAIL PROTECTED] wrote: Erik, Jason and Viet. This is really good. Since we're making a SNAPSHOT available is there some point where we should declare a 1.0 ? On Aug 23, 2007, at 4:30 PM, Erik B. Craig wrote: All, After the recent round of changes and improvements around j2g (usable from within the Eclipse IDE UI, Annotations support, improved logging/information output, support for EJB 3), as well as a bit of interest out in the general open source community in moving applications from Jboss to Geronimo (such as today's inquiry on theserverside.com), I feel as though it would be of some benefit to have j2g, at least the content in our confluence wiki ( http://cwiki.apache.org/GMOxDOC20/j2g-migration-tool.html) linked somewhere on the actual geronimo homepage. I was thinking either as it's own link under 'Subprojects', much as Development Tools, GBuild, or XBean are situated, or as an addition inside the Development Tools page, much as the current Eclipse Plug-in section rests within there. I am willing to commit to doing a bit of additional writing (beyond what is on the wiki) if it were to be under it's own section, or a subsection of development tools if necessary, but I think it would be good to get it up and out there sooner rather than later, especially to coincide with the recent release of 2.0.1 to perhaps show those out there remotely interested in migrating, there are tools available to assist and perhaps 'hold their hand' a bit. Thoughts? Comments? Objections? Thanks -- Erik B. Craig -- Erik B. Craig
Too easy to kill the server using the web console
GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
Re: Too easy to kill the server using the web console
Joe, I did actually not-so-gracefully stumble into this previously, so I do know the pain it can cause. I think perhaps the best behavior in this situation might be to not only prevent removal of components that would cripple the console, but also display a prompt when it is attempted saying something along the lines of This component must be removed manually from command line, as doing so will render the admin console useless. On 8/28/07, Joe Bohn [EMAIL PROTECTED] wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe -- Erik B. Craig
Re: Adding j2g to site
let's move it to dev tools first, +1
[jira] Created: (GERONIMODEVTOOLS-188) devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set
devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set Key: GERONIMODEVTOOLS-188 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-188 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Ted Kirby Priority: Minor the $Rev$ tag is not being set and updated via svn The file was added in August, but the $Rev$ tag is from April. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-188) devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-188: --- Assignee: Tim McConnell devtools\eclipse-plugin\assembly\src\main\assembly\site.xml does not look like it has svn keyword properties set Key: GERONIMODEVTOOLS-188 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-188 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Ted Kirby Assignee: Tim McConnell Priority: Minor the $Rev$ tag is not being set and updated via svn The file was added in August, but the $Rev$ tag is from April. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ServiceMix 4.0
Guillaume, No problem... I think you will be happy with this choice. Also to clarify something important, I really encourage you to replace commons-logging-1.x.jar with jcl14-over-slf4j which implements the commons-logging interfaces and maps them to slf4j static binding. This will solve the problem with other projects like Spring that still use commons-logging and provide consistency for your projects. Cheers... Chris On 8/28/07, Guillaume Nodet [EMAIL PROTECTED] wrote: Thanks Chris ! It seems like the experts have answered... So i guess we will switch to slf4j :-) Cheers, Guillaume Nodet On 8/28/07, Chris Custine [EMAIL PROTECTED] wrote: You are correct about OSGi having more control over classloaders, but in the case of JCL things are a little different. Below is a link to the mailing list thread where we went through all of this pain on the Spring-OSGi project and decided to replace JCL with the slf4j facade in order to eliminate the side effects caused by Spring using JCL. I think Spring-OSGi uses slf4j natively now because of this and I believe it has been a consideration for Spring itself to move to it, but I am not sure of the final outcome of that discussion. http://tinyurl.com/3axajc I think the thread was cross posted to Equinox as well and a discussion occured there... Just google commons logging madness :-) As you said about OSGi being flexible, one nice thing about using slf4j in OSGi is that you can have all implementation bundles (slf4j-log4j, slf4j-jdk14, etc.) available in the container, and it is up to each bundle to specify which one it imports, thereby adding it to the classloader wiring. I can't remember if that is built in functionality of slf4j or if it is something that I made work, but it is all done with manifest headers so it is easy to do if its not shipped like that. Good luck! Chris On 8/27/07, Nodet Guillaume [EMAIL PROTECTED] wrote: I would say the opposite. The OSGi classloaders are much more powerful and you can more easily control the visibility of classes. In addition, if JCL is required by a given bundle A, it does not mean that it will be visible by a bundle using bundle A. Obviously, this means to be tested (or maybe OSGi experts could help there...) Cheers, Guillaume Nodet On Aug 27, 2007, at 9:29 PM, Bruce Snyder wrote: Also, moving toward an architecture based on OSGi almost guarantees that we will run into classloader issues with JCL. Bruce -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
Re: New GShell-based Geronimo Server launcher now in server/trunk
Oh man,
Gshell is looking to be pretty sweet, awesome work Jason.
One thing that would definitely be cool is implementing SSH into it, and I
did notice there's already a Jira for that, I'm sure I can brainstorm up a
few other additions given time... want a little help on the side? =)
On 8/21/07, Jason Dillon [EMAIL PROTECTED] wrote:
Hiya folks, I finally got around to finishing up my POC of using
GShell to launch the Geronimo Server and I have committed the bits
that make it work to server/trunk. The new module which contains the
GShell command implementation (and support) classes is:
modules/geronimo-commands
And a new assembly which has the GShell bits all in place for folks
to test with is:
assemblies/geronimo-jetty6-javaee5-gshell
The assembly is not hooked up by default, but the code module is.
So, to test it out, you need to do something like:
svn co https://svn.apache.org/repos/asf/geronimo/server/trunk
server
cd server
mvn
assemblies/geronimo-jetty6-javaee5-gshell
mvn
Then unzip the assembly:
unzip target/geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT-bin.zip
And then finally try it out. First lets get the basic GShell command-
line help:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh --help
This should spit out something like:
snip
_ _ _
/ ___/ ___|| |__ ___| | |
| | _\___ \| '_ \ / _ \ | |
| |_| |___) | | | | __/ | |
\|/|_| |_|\___|_|_|
GShell -- Geronimo command-line shell
usage: gsh [options] command [args]
-n,--non-interactiveRun in non-interactive mode
-D,--define name=valueDefine a system property
-V,--versionDisplay GShell version
-c,--commands string Read commands from string
-debug,--debug Enable DEBUG logging output
-h,--help Display this help message
-i,--interactiveRun in interactive mode
-quiet,--quiet Limit logging output to ERROR
-verbose,--verbose Enable INFO logging output
/snip
Then lets run the interactive-shell:
./geronimo-jetty6-javaee5-gshell-2.1-SNAPSHOT/bin/gsh
This should leave you at a very plain prompt at the moment:
snip
_
/snip
At this point you can type something like this to list all of the
known commands:
snip
help commands
/snip
Which should spit back:
snip
Available commands (and aliases):
start-server ( start )
set
exit ( quit, bye )
unset
source
help
/snip
The command that I added is called 'start-server', with an alias of
'start'. This is basically an augmented and enhanced version of what
the geronimo:start-server goal does in the geronimo-maven-plugin. To
see its options run this:
snip
start-server --help
/snip
And it says:
snip
start-server -- Starts a new Geronimo server instance
usage: start-server [options]
-A,--javaagent jar Use a specific Java Agent, set to
'none' to
disable
-D,--property name=valueSet a system property
-H,--home dir Use a specific Geronimo home
directory
-J,--javaopt option Set a JVM flag
-b,--background Run the server process in the
background.
-h,--help Display this help message
-j,--jvm dirUse a specific Java Virtual
Machine for server
process
-l,--logfile file Capture console output to file
-m,--module nameStart up a specific module by name.
-q,--quietSuppress informative and warning
messages
-t,--timeout secondsSpecify the timeout for the server
process in
seconds
-v,--verbose Enable verbose output; specify
multipule times
to increase verbosity.
/snip
NOTE: Use -vv for --veryverbose ;-)
And then give it a whirl and try to start the server up from the shell:
snip
start-server
/snip
or if you prefer more output:
snip
start-server -v
/snip
And so on...
This will actually create a newly forked JVM to run the server in,
and will eventually have a robust node manager thingy, but I've not
done that yet ;-)
The platform scripts are now super simple!!! All of the logic is now
in the command implementation. And eventually we can probably have
the geronimo-maven-plugin just invoke the command so that
*everything* uses the exact same method for launching the server
process.
* * *
As requested by Jeff, I added support to read in some scripts to
augment the launching of the server... so that plugins can add
properties and such easily. Right now this is the directory which is
inspected for scripts:
etc/rc.d
And currently the scripts need to be named like this:
[jira] Created: (GERONIMO-3446) Improperly configured JRE_HOME or JAVA_HOME environment variables can cause server failure
Improperly configured JRE_HOME or JAVA_HOME environment variables can cause server failure -- Key: GERONIMO-3446 URL: https://issues.apache.org/jira/browse/GERONIMO-3446 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Kevan Miller Fix For: 2.0.x If JAVA_HOME or JRE_HOME environment variables are not set properly, the Geronimo server may fail during startup. For example, on Mac OS X, if you export JRE_HOME=/usr. You get the following: Caused by: java.lang.NullPointerException at org.apache.geronimo.security.SubjectId.hashCode(SubjectId.java:79) at java.util.HashMap.hash(HashMap.java:264) at java.util.HashMap.put(HashMap.java:382) at java.util.Collections$SynchronizedMap.put(Collections.java:1983) at org.apache.geronimo.security.ContextManager.registerSubject(ContextManager.java:299) at org.apache.geronimo.security.ContextManager.clinit(ContextManager.java:71) ... 37 more The problem is that the java.ext.dirs property is being set to an improper value. This means the JRE is not able to load jar files from $JRE_HOME/lib/ext. At a minimum, our scripts should detect an invalid JRE_HOME or JAVA_HOME setting. Better yet, we could try to set it automatically... In addition, it looks like we don't need to explicitly configure the java.ext.dirs property any longer, anyway (we no longer package ext jars). Removing the setting of the property (e.g. -Djava.ext.dirs=$EXT_DIRS ) from our scripts would also fix this specific problem... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Too easy to kill the server using the web console
I don't like prohibiting people from doing stuff because we think we know better. I think there are valid reasons to stop and uninstall most of these modules, although you may need to be an expert to be able to start the server afterwards. How about if for both stop and uninstall we show a list of the modules that will be stopped or rendered inoperable as a result? This would be the transitive closure of the child view in the modules pages. thanks david jencks On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/ GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
Re: Too easy to kill the server using the web console
I guess we could also disable stop and undeploy for the system modules and have an expert mode checkbox or something on the screen to enable them again. That ought to be clue enough. :) Thanks, Aaron On 8/28/07, Aaron Mulder [EMAIL PROTECTED] wrote: It probably would still be good to have some text like WARNING: only expert users will be able to restart the server after this is done. Just seeing a list of components to be stopped won't necessarily clue in the average user to the potential impact... But of course we'd only want to display that if it was really the case, so perhaps we can just detect whether the really important startup-fails-without-this modules are in the dependency list. Thanks, Aaron On 8/28/07, David Jencks [EMAIL PROTECTED] wrote: I don't like prohibiting people from doing stuff because we think we know better. I think there are valid reasons to stop and uninstall most of these modules, although you may need to be an expert to be able to start the server afterwards. How about if for both stop and uninstall we show a list of the modules that will be stopped or rendered inoperable as a result? This would be the transitive closure of the child view in the modules pages. thanks david jencks On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/ GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
Re: Too easy to kill the server using the web console
It probably would still be good to have some text like WARNING: only expert users will be able to restart the server after this is done. Just seeing a list of components to be stopped won't necessarily clue in the average user to the potential impact... But of course we'd only want to display that if it was really the case, so perhaps we can just detect whether the really important startup-fails-without-this modules are in the dependency list. Thanks, Aaron On 8/28/07, David Jencks [EMAIL PROTECTED] wrote: I don't like prohibiting people from doing stuff because we think we know better. I think there are valid reasons to stop and uninstall most of these modules, although you may need to be an expert to be able to start the server afterwards. How about if for both stop and uninstall we show a list of the modules that will be stopped or rendered inoperable as a result? This would be the transitive closure of the child view in the modules pages. thanks david jencks On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/ GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
[jira] Created: (GERONIMO-3447) Tuscany plugin for Geronimo
Tuscany plugin for Geronimo --- Key: GERONIMO-3447 URL: https://issues.apache.org/jira/browse/GERONIMO-3447 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Environment: G 2.0.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy This JIRA is created to track moving of Tuscany plugin for geronimo into geronimo\plugins. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3447) Tuscany plugin for Geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523327 ] Vamsavardhana Reddy commented on GERONIMO-3447: --- Initial code drop from work in sandbox in Revision: 570534. Tuscany plugin for Geronimo --- Key: GERONIMO-3447 URL: https://issues.apache.org/jira/browse/GERONIMO-3447 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Environment: G 2.0.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy This JIRA is created to track moving of Tuscany plugin for geronimo into geronimo\plugins. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Too easy to kill the server using the web console
David Jencks wrote: I don't like prohibiting people from doing stuff because we think we know better. I think there are valid reasons to stop and uninstall most of these modules, although you may need to be an expert to be able to start the server afterwards. Yes, I see your point ... and it does get tricky trying to decide when to permit an action and when to prevent it. How about if for both stop and uninstall we show a list of the modules that will be stopped or rendered inoperable as a result? This would be the transitive closure of the child view in the modules pages. We already show the immediate children (as you point out) and I think the user kind of glazes over at that list. The transitive list would be even larger and possibly more likely to be ignored. Still ... it's worth exploring. For a quick fix for now I think I will just go with a sternly worded challenge if the module to be stopped/uninstalled is a SERVICE or starts with org.apache.geronimo.* Thanks, Joe thanks david jencks On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
Re: Too easy to kill the server using the web console
Both good suggestions. Thanks! Joe Aaron Mulder wrote: I guess we could also disable stop and undeploy for the system modules and have an expert mode checkbox or something on the screen to enable them again. That ought to be clue enough. :) Thanks, Aaron On 8/28/07, Aaron Mulder [EMAIL PROTECTED] wrote: It probably would still be good to have some text like WARNING: only expert users will be able to restart the server after this is done. Just seeing a list of components to be stopped won't necessarily clue in the average user to the potential impact... But of course we'd only want to display that if it was really the case, so perhaps we can just detect whether the really important startup-fails-without-this modules are in the dependency list. Thanks, Aaron On 8/28/07, David Jencks [EMAIL PROTECTED] wrote: I don't like prohibiting people from doing stuff because we think we know better. I think there are valid reasons to stop and uninstall most of these modules, although you may need to be an expert to be able to start the server afterwards. How about if for both stop and uninstall we show a list of the modules that will be stopped or rendered inoperable as a result? This would be the transitive closure of the child view in the modules pages. thanks david jencks On Aug 28, 2007, at 7:41 AM, Joe Bohn wrote: GERONIMO-3401 ( https://issues.apache.org/jira/browse/ GERONIMO-3401 ) records a problem where it is possible for the user to cripple the web console, the server or both with 1 or 2 mouse clicks. When stopping some system-modules such as the following from the web console, the web console itself is also stopped due to direct and transitive dependencies: - activemq-broker - connector-deployer - geronimo-gbean-deployer - j2ee-corba-yoko - j2ee-deployer - j2ee-security - j2ee-server - j2ee-system - jasper - jee-specs - openejb - openjpa - rmi-naming - server-security-config - tomcat6 - tomcat6-deployer - jetty6 - jetty6-deployer - transaction - webservices-common - xmlbeans The result is an error in the browser, and exception in the server, and the web console disabled. One cheap way to help prevent this problem is to add a challenge when any system module is stopped to ensure the user is aware that stopping a system module might result in rendering the web console unusable. The situation can be recovered via the CLI by subsequently starting the web console but this might not be obvious to the user and often a server restart is necessary before the CLI itself can function again. However, there is another problem that is much more serious. If the user selects uninstall on any of the modules listed above, in addition to the web console being disabled, the server itself is corrupted. In fact, in most cases the server cannot start once it is shutdown. AFAIK, there is no easy recovery from this. There is a challenge already provided to he user when uninstall is selected but it doesn't hint at the potential severity of the consequences. I'm thinking we should remove the uninstall capability from the system module view in the web console until we have more pluggable components that can be installed/uninstalled without crippling the entire server. A challenge (even if worded more strongly) just doesn't seem sufficient. Of course we have this same exposure with the CLI but it isn't quite as easy to shoot yourself in the foot there with just 2 mouse clicks. Thoughts? Joe
Re: Too easy to kill the server using the web console
I like that idea. Keep people safe but let them blaze on if they so desire. On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote: I guess we could also disable stop and undeploy for the system modules and have an expert mode checkbox or something on the screen to enable them again. That ought to be clue enough. :)
Re: Too easy to kill the server using the web console
One other thought...perhaps we could play an audio clip of a shotgun or other firearm action being moved to suggest the consequences of hitting enter :) On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote: I guess we could also disable stop and undeploy for the system modules and have an expert mode checkbox or something on the screen to enable them again. That ought to be clue enough. :)
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote: On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=12323536framed=yskin=12049 We will use the standard IRC channel: see http://incubator.apache.org/servicemix/irc.html I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Before switching to mac, I was using xchat. See http://www.xchat.org/ So, now that you are on mac, what do you use? ;) (Another IRC newbie) Cheers, Guillaume Nodet -- Daryl Email *my = [ daryl at: @eddl dot: @us ]; Weblog *blog = @”http://itsallsemantics.com”;
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
I'm using Colloquy (http://colloquy.info/) Cheers, Guillaume Nodet On Aug 28, 2007, at 11:57 PM, Daryl Richter wrote: On Aug 28, 2007, at 8:53 AM, Nodet Guillaume wrote: On Aug 28, 2007, at 2:48 PM, Piotr Bzdyl wrote: Hi, I would also like to participate in this session. When are you going to send data about the location of the IRC session? See http://www.nabble.com/forum/ViewPost.jtp? post=12323536framed=yskin=12049 We will use the standard IRC channel: see http://incubator.apache.org/servicemix/irc.html I have also another question: could you recommend any easy in use IRC client (for Windows preferably)? I haven't been using IRC (except one or two times). Before switching to mac, I was using xchat. See http://www.xchat.org/ So, now that you are on mac, what do you use? ;) (Another IRC newbie) Cheers, Guillaume Nodet -- Daryl Email *my = [ daryl at: @eddl dot: @us ]; Weblog *blog = @”http://itsallsemantics.com”;
Re: IRC sessions on ServiceMix 4.0 design (was Re: ServiceMix 4.0)
On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: I'm using Colloquy (http://colloquy.info/) Yeah, I've used it for the last few years. It's not as comprehensive in functionality as some of the hard-core IRC clients for Linux (e.g., BitchX, etc.) but it's pretty nice and perfect for MacOS. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
IRC session
Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... Cheers, Guillaume Nodet
Re: Too easy to kill the server using the web console
Or simulate some burning smell by maxing on the CPU and burning some hardware if possible :o) On 8/29/07, Matt Hogstrom [EMAIL PROTECTED] wrote: One other thought...perhaps we could play an audio clip of a shotgun or other firearm action being moved to suggest the consequences of hitting enter :) On Aug 28, 2007, at 12:02 PM, Aaron Mulder wrote: I guess we could also disable stop and undeploy for the system modules and have an expert mode checkbox or something on the screen to enable them again. That ought to be clue enough. :)
Re: IRC session
On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/
Re: IRC session
On 8/28/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/28/07, Nodet Guillaume [EMAIL PROTECTED] wrote: Unfortunately I will be traveling until Friday evening. What about moving it to Monday instead at the same hour ? 3 pm GMT, 11 am EST, 8 am PST Sorry about that... +1 Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache ActiveMQ - http://activemq.org/ Apache ServiceMix - http://servicemix.org/ Apache Geronimo - http://geronimo.apache.org/ Castor - http://castor.org/ +2 ; } -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
On Aug 27, 2007, at 4:25 PM, Karan Malhi wrote: How do the users of geronimo set log levels? Should be through the log4 files in the /var/log directory of the install. -David On 8/27/07, David Blevins (JIRA) [EMAIL PROTECTED] wrote: Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/ GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Karan Singh Malhi
Re: [jira] Created: (GERONIMO-3445) Verify log levels can be changed for openejb related log categories
I dont even think they can change log levels. We used the logic that - if conf is present - use logging.properties - if conf is present - logging.properties is absent- install logging.properties and use it - if conf is absent, assume embedded and use embedded.logging.properties which is available in the openejb-core.jar . - if embedded.logging.properties is not found in openejb-core.jar then rely on the log4j.configuration system property So, if openejb is embedded within GERONIMO, no matter what log levels they set in the var/logs directory, those settings should never take effect. I think what we can do though is that Geronimo can set the log4j.configuration system property in the o.a.g.openejb.OpenEjbSystemGBean and we can then do the following: - if conf is absent, assume embedded, look for log4j.configuration system property. if log4j.configuration property is set, then use it, if it is absent then use embedded.logging.properties Do you think I am on the right track and does the above makes any sense? On 8/28/07, David Blevins [EMAIL PROTECTED] wrote: On Aug 27, 2007, at 4:25 PM, Karan Malhi wrote: How do the users of geronimo set log levels? Should be through the log4 files in the /var/log directory of the install. -David On 8/27/07, David Blevins (JIRA) [EMAIL PROTECTED] wrote: Verify log levels can be changed for openejb related log categories --- Key: GERONIMO-3445 URL: https://issues.apache.org/jira/browse/ GERONIMO-3445 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: David Blevins Some users have reported inability to change log levels for log categories pertaining to OpenEJB. This needs to be investigated, verified and fixed if found to be an issue or better documented if found not to be an issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Karan Singh Malhi -- Karan Singh Malhi
[jira] Created: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Latest August 23 build from unstable Reporter: Shane Blake Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244) at org.eclipse.jdt.internal.ui.navigator.OpenAndExpand.run(OpenAndExpand.java:50) at org.eclipse.ui.actions.RetargetAction.run(RetargetAction.java:220) at org.eclipse.ui.internal.navigator.CommonNavigatorManager$3.open(CommonNavigatorManager.java:181) at org.eclipse.jface.viewers.StructuredViewer$2.run(StructuredViewer.java:820) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:857) at
[jira] Updated: (GERONIMODEVTOOLS-189) Error opening geronimo-web.xml
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shane Blake updated GERONIMODEVTOOLS-189: - Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable was: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Latest August 23 build from unstable Error opening geronimo-web.xml -- Key: GERONIMODEVTOOLS-189 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-189 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Environment: Eclipse SDK Version: 3.3.0 Build id: I20070525-1350 Build id: I20070625-1500 Latest August 23 build from unstable Reporter: Shane Blake Opening geronimo-web.xml getting the following stack trace: java.lang.IllegalArgumentException at org.eclipse.wst.server.core.internal.facets.FacetUtil.getRuntime(FacetUtil.java:61) at org.eclipse.jst.server.core.FacetUtil.getRuntime(FacetUtil.java:47) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.getLoader(SharedDeploymentPlanEditor.java:97) at org.apache.geronimo.st.ui.editors.SharedDeploymentPlanEditor.loadDeploymentPlan(SharedDeploymentPlanEditor.java:86) at org.apache.geronimo.st.ui.editors.AbstractGeronimoDeploymentPlanEditor.init(AbstractGeronimoDeploymentPlanEditor.java:181) at org.eclipse.ui.internal.EditorManager.createSite(EditorManager.java:794) at org.eclipse.ui.internal.EditorReference.createPartHelper(EditorReference.java:643) at org.eclipse.ui.internal.EditorReference.createPart(EditorReference.java:426) at org.eclipse.ui.internal.WorkbenchPartReference.getPart(WorkbenchPartReference.java:592) at org.eclipse.ui.internal.PartPane.setVisible(PartPane.java:299) at org.eclipse.ui.internal.presentations.PresentablePart.setVisible(PresentablePart.java:179) at org.eclipse.ui.internal.presentations.util.PresentablePartFolder.select(PresentablePartFolder.java:268) at org.eclipse.ui.internal.presentations.util.LeftToRightTabOrder.select(LeftToRightTabOrder.java:65) at org.eclipse.ui.internal.presentations.util.TabbedStackPresentation.selectPart(TabbedStackPresentation.java:400) at org.eclipse.ui.internal.PartStack.refreshPresentationSelection(PartStack.java:1256) at org.eclipse.ui.internal.PartStack.setSelection(PartStack.java:1209) at org.eclipse.ui.internal.PartStack.showPart(PartStack.java:1604) at org.eclipse.ui.internal.PartStack.add(PartStack.java:499) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:103) at org.eclipse.ui.internal.PartStack.add(PartStack.java:485) at org.eclipse.ui.internal.EditorStack.add(EditorStack.java:112) at org.eclipse.ui.internal.EditorSashContainer.addEditor(EditorSashContainer.java:63) at org.eclipse.ui.internal.EditorAreaHelper.addToLayout(EditorAreaHelper.java:217) at org.eclipse.ui.internal.EditorAreaHelper.addEditor(EditorAreaHelper.java:207) at org.eclipse.ui.internal.EditorManager.createEditorTab(EditorManager.java:774) at org.eclipse.ui.internal.EditorManager.openEditorFromDescriptor(EditorManager.java:673) at org.eclipse.ui.internal.EditorManager.openEditor(EditorManager.java:634) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditorBatched(WorkbenchPage.java:2719) at org.eclipse.ui.internal.WorkbenchPage.busyOpenEditor(WorkbenchPage.java:2633) at org.eclipse.ui.internal.WorkbenchPage.access$12(WorkbenchPage.java:2625) at org.eclipse.ui.internal.WorkbenchPage$10.run(WorkbenchPage.java:2577) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:67) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2572) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2556) at org.eclipse.ui.internal.WorkbenchPage.openEditor(WorkbenchPage.java:2547) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:644) at org.eclipse.ui.ide.IDE.openEditor(IDE.java:603) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:285) at org.eclipse.jdt.internal.ui.javaeditor.EditorUtility.openInEditor(EditorUtility.java:138) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:194) at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:175) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:268) at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:244) at
