[jira] Created: (GSHELL-156) Disable system bell by default
Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Custine updated GSHELL-156: - Attachment: nobell.patch This is a simple patch to disable the bell globally by default. An alternative would be to have a system prop so that someone could override this and enable it, although I am not sure why anyone would want to. Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668773#action_12668773 ] Chris Custine commented on GSHELL-156: -- I hear you, I'm a Mac. ;-) I was just trying to fix this in ServiceMix 4 kernel (https://issues.apache.org/activemq/browse/SMX4KNL-137) but now I looked closer and you are right about the terminals, some just have audible bell switched off by default. I'm fine with closing this as won't fix if you want to leave it as is. Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Heads up] SSH server in java
Wow... Just getting around to looking at this. Nice work. Chris -- Chris Custine My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Thu, Nov 6, 2008 at 2:22 PM, Guillaume Nodet [EMAIL PROTECTED] wrote: Over the past days, I've been working on a implementing a SSH server in java to replace to gshell remoting bits. The project is currently hosted at google code: http://code.google.com/p/sshd/ This project is based on Mina and the current status is that the ssh protocol is in a working state, but there are still a lots of things to iron. I've been able to connect using openssh 5.0 and 5.1 and also jsch (from which i borrowed from code btw) and launch an /bin/sh shell and issue a few commands. I'd be happy if any committer is interested to work on that to give him commits rights on the project. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: Running ServiceMix in an OSGi environment
On Nov 13, 2007 7:42 AM, Cristian Pascu [EMAIL PROTECTED] wrote: Hi! I would like to hear from you some advices on how start ServiceMix embedded inside an OSGi environment (in my case an Eclipse installation). I think I have at least two options: 1. Bundle servicemix with all it's dependencies inside an OSGi bundle. Has anyone already done this? This *might* work, but your OSGi bundle will be quite large to say the least. If you want to try this, I suggest trying the maven-bundle plugin from the Apache Felix project since it will evaluate the transitive dependencies in the Maven pom.xml and add the jars to the bundle automatically. 2. Use a distribution of servicemix that is already packaged as OSGi bundles. Is there something like this? ServiceMix 4.0 will be just that, but I am not sure if it is in a state that will be useful to you yet. Chris My use case would be to start an embedded JBI container, deploy dynamically service units to already installed components (I am playing now with Saxon component) and send messages to installed endpoints. Any ideas? Thank you very much! Cristian
Re: ServiceMix 4 as a distributed OSGi spring container....
On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: On 10/11/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/11/07, Guillaume Nodet [EMAIL PROTECTED] wrote: I was thinking that ldap may be handy for the registry, but hopefully Chris will join the discussion at this point... Though camel does not support ldap (yet). This was exactly the road I started going down in order to solve a couple of problems: 1) Distributing a consistent configuration across groups of nodes 2) Providing for a central registry that is replicated to other directory server instances What I am trying to get my head around, is if this configuration data can be abstracted up to the OSGi level or if it is specific to ServiceMix? I see the specific requirement for this data within ServiceMix itself, but with OSGi there is also the configuration admin service which is a standardized way to provide data to instances of services. I have been thinking about implementing a distributed version of these kinds of OSGi services for a long time so this could be another option. If nothing else, we could support a pluggable registry that could have different implementations depending on the deployment scenario. Just a thought. This would optionally require a master directory server with other backup or slave servers in order to replicate the registry data. The size of the network and the criticality of the data would determine if you need to run slave servers or not. The other thing I began thinking about was using the AMQ master/slave functionality and just embedding the directory server in the master and the slaves. This would mean less moving parts and we could make any LDAP replications take place via AMQ transports. Doesn't apacheds comes with a clustering / replication solution already ? Yes, and I can look into modifying this to use ActiveMQ to do the replication so that we can keep things consistent (current replication is direct TCP with Mina on each node). ApacheDS also allows replication without exposing the actual LDAP server... so it can be embedded and expose a direct JNDIContext without exposing a listener externally yet still achieve replication, which is a common use case for embedded users. So your snippet would actually solve the heartbeat problem. But I'm not sure we can send the whole data at each heartbeat. I guess it depends how bit this data is, but if we have lots of services in the OSGi registry, it may not be very scalable. So we would have to default to send only updates or find another mechanism to send the data (the heartbeat could just contain the url of our container, and the data would be retrieved by another mechanism). How about just sending the URL and a flag stating that there is an update? If one of the other servers wants the update, then they can poll that server's URL and a known topic for the actual data updates. Yeah. However, for performance reasons, it may be interesting to be able to only publish the delta in addition to provide an easy access to the whole data. I think ApacheDS does this now, but I am sure that it could be optimized to fit our needs if it doesn't already. We could also expose the registry as a REST interface, but it may not be the most efficient way. 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/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ I certainly think that ApacheDS could be of some use here, but I don't want to be pushy or biased ;-) There will certainly be some customizations for this use case, but ApacheDS is extensible via interceptors and other similar means. In addition, it might not be well known that ApacheDS is going to start moving to an OSGi container based deployment as well, so that might be useful too. I think these discussions are great and will help expose the requirements as we toss around these ideas and we can keep fine tuning the solution. Chris
Re: ServiceMix 4.0 modularity
On 10/4/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 10/4/07, Chris Custine [EMAIL PROTECTED] wrote: I agree that eventually you will have certain components that have their own release cycles seperate from the core components. I think it will take several releases of all components as an entire system before you will be comfortable splitting things into seperate sub-projects, but as the core components mature and stabilize I think it will be a natural desire to have more frequent releases of the optional components. Agreed. The dependency management issues mentioned by Bruce and Kit are valid, but don't forget that the bundles are able to specify required version information for their own dependencies. So the dependency management issue is more about shipping a properly working default configuration with the main ServiceMix distribution than about the seperate releases of components. That's a good point and something I forgot about. I guess we'll need to relax any static version requirements once the core stablizes so that we can allow a wider range of acceptable versions of various components. I like Guillaume's idea of offering a basic image that is capable of provisioning itself from a managed OBR repository. This could also allow a user to configure their own customized provisioning configuration similar to kickstart files for Linux distributions. I think you will also want to offer a fully loaded and self contained image that already has all of the components available, but the auto-provisioned basic image will be very useful for a lot of users I would think. I think this is a good paradigm as well. However, a question arose today about continuing to allow ServiceMix to be embedded in any old Java app. Some folks may want an OSGi container to be started when embedding ServiceMix, and some may not. All I'm saying is that we need to keep this in mind as a requirement because there are a fair amount of users who are embedding ServiceMix today. I have had to think about this same issue with Apache Directory Server. ApacheDS has many users that embed as well as many users of the standalone server and this will be an issue for us as we move the server to an OSGi container as well. It may be different for ServiceMix, but for ApacheDS I want to be able to offer the ability to embed without using OSGi or Spring at all. I haven't worked out all the details yet, but I am thinking about a component that contains all of the OSGi specific code and manages the server components which are just library bundles with OSGi Manifest headers so that they can also be used as simple jar files outside of OSGi. If you wanted to embed, then the OSGi component is not used, and instead you could have a facade that basically does what the standalone server does today (use Spring to load app context and wire components), or just wire the components up directly in the user's own code (ADS has people doing this as well). So this basically exposes 3 distinct use cases with progressively lower levels of integration. Now the trick is to accomplish this without introducing a maintenance nightmare. :-) Thanks, Chris
[jira] Commented: (SM-1066) Distributed registry
[ https://issues.apache.org/activemq/browse/SM-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_40157 ] Chris Custine commented on SM-1066: --- I think there are a couple of ways to achieve this. Similar to SM-1071, this might be achieved with Configuration Admin but I don't think there is any way currently to have distributed configurations in the spec. This is partly the reason for my idea to use ApacheDS as a centralized Configuration Admin system. Even if you did this outside of OSGi, it might make sense to embed a small ApacheDS LDAP server somewhere and have your cluster nodes configure themselves from that data. Just an idea... Distributed registry Key: SM-1066 URL: https://issues.apache.org/activemq/browse/SM-1066 Project: ServiceMix Issue Type: New Feature Reporter: Guillaume Nodet Fix For: 4.0 We need a way to implement a distributed NMR registry. Endpoints registered in the NMR should be available for other instances on the cluster. Or is this a purely distributed OSGi registry without being tied to ServiceMix ? -- 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: ServiceMix 4.0
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
Re: ServiceMix 4.0
I would highly recommend switching to slf4j for internal logging, and then use the slf4j over jcl facade to permanently get rid of commons-logging. If you are going to use OSGi in the future, you will have trouble with the dynamic classloading issue introduced by JCL. The slf4j facade will alleviate this because the linkage is static (based on which jar you choose to use). I blogged about this a while back here: http://blog.organicelement.com/2006/12/21/commons-logging-classloader-woes Also slf4j is fairly OSGi friendly in that it has OSGi manifest headers already built in so you can deploy with OSGi and make the logging package available to all bundles. Chris On 8/27/07, Bruce Snyder [EMAIL PROTECTED] wrote: On 8/27/07, James Strachan [EMAIL PROTECTED] wrote: 1. Use slf4j as the logging framework. (http://www.slf4j.org/) - btw, I'm not sure if its a better option, but I did hear some good stuff about it. Yes, SMX should switch to using the slf4j-api which will allow any logging framework to be plugged in at deployment time. how's that different from commons-logging (other than adding yet another dependency, since many things SMX depends on also depends on commons logging) There are a lot of reasons, including an extremely good writeup about JCL that Ceki did back in 2004 that is available here: http://www.qos.ch/logging/thinkAgain.jsp But the most important point of all is that the use of JCL is most oftentimes incorrect from an architecture standpoint. At least this is what the creator of JCL says: '...The purpose of Commons Logging is not to somehow take the logging world by storm. In fact, there are very limited circumstances in which Commons Logging is useful. If you're building a stand-alone application, don't use commons-logging. If you're building an application server, don't use commons-logging. If you're building a moderately large framework, don't use commons-logging. If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you...' See Rod's full blog entry here: http://radio.weblogs.com/0122027/2003/08/15.html 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: managed to get some hacking done on the plane ride to Austin...
For the Jabber server, you will obviously want to start with http://www.jivesoftware.org/wildfire/ Out of the box, it runs in a Jetty instance so it may be a little heavyweight On 10/8/06, James Strachan [EMAIL PROTECTED] wrote: On 10/8/06, James Strachan [EMAIL PROTECTED] wrote: ... despite being in economy :) Am still checking everythings still building and tests working etc, but have servicemix-file, servicemix-ftp and servicemix-jabber ported over from the old lwcomponent stuff to fully fledged service engines. I also wrote another called servicemix-bean which maps JBI messages to POJOs rather like Lingo does for JMS (but without any SOAP processing like servicemix-jsr181) - more on that later in a separate thread. Just a heads up in case anyone else was gonna start porting file/ftp/jabber to the new service-engine structure - have it just about working and it should be in SVN in an hour or so. OK its all there now - so by all means dive in and start hacking it :) Am gonna look to see if I can find a pure Java Jabber and FTP server we can use to do nice integration testing of these components -- James --- http://radio.weblogs.com/0112098/
