Re: GShell
Yeah agreed, I discovered this one too. I've played a bit with pax-runner too this week while integrating GShell. Anyway, from a gshell perspective, i have been able to have a local console running. However, it is quite heavy as you need to bring plexus, xstream, classworlds and gshell itself.I really like the fact that GShell has a nice ansi console, a nice command line management and remoting. However, I'll try to have it delegate to the felix shell instead as it is much more OSGi friendly (commands are registered in the osgi registry). On Oct 3, 2007, at 6:57 AM, Kit Plummer wrote: Im using the pax-logging stuff on a project. Very nice. Kit On Oct 2, 2007, at 5:28 PM, "Guillaume Nodet" <[EMAIL PROTECTED]> wrote: Btw, the pax project has lots of interesting things. See http://wiki.ops4j.org/confluence/display/ops4j/Pax+RadMan and much more. On 10/3/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Forwarding to the dev list... FYI, Gshell is a subproject of Geronimo providing an extensible console (local and remote), kinda like bash. -- Forwarded Message From: Guillaume Nodet <[EMAIL PROTECTED]> Date: Wed, 03 Oct 2007 02:11:44 +0200 To: Bruce Snyder <[EMAIL PROTECTED]> Conversation: On duplicating effort Subject: Re: On duplicating effort On 3/10/07 2:02, "Bruce Snyder" <[EMAIL PROTECTED]> wrote: On 10/2/07 5:59 PM, "Guillaume Nodet" <[EMAIL PROTECTED]> wrote: https://issues.apache.org/activemq/secure/IssueNavigator.jspa? reset=true&mod e=hide&sorter/order=DESC&sorter/ field=priority&resolution=-1&pid=10950&fixfo r=11845 So are you using GShell for SM-1074? Not really. Imho, gshell is just an interface to access features provided by other mechanism. Lifecycle is really tied to OSGi lifecycle, but yeah, we need to create Gshell commands for OSGi related stuff (start / stop bundles, etc...), but we could also have a web console for that, or a JMX one... What I mean is that Gshell should remain a mean of accessing these features. We also need to add a JIRA issue for the 1.0 compatibility layer. Done, SM-1083. Btw, we should have this discussion on the dev list ;-) Guillaume -- End of Forwarded Message IONA Technologies SARL Identification: 415 295 930 R.C.S. Nanterre Siège: Immeuble Elysées La Défense, 7C place du Dôme, 92056 La Défense Cedex, France -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/
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: 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=12323536&framed=y&skin=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”;
ServiceMix 4.0 api
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
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 and type converters
On Aug 23, 2007, at 1:48 PM, James Strachan wrote: I thought I'd spin up another thread on this... On 8/23/07, Brian O'Neill <[EMAIL PROTECTED]> wrote: On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: 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. I haven't looked at Camel converters, but would you consider adding a contentType and contentEncoding mimicing the headers of HTTP & SIP. The endpoint can then use the type and encoding to determine how to handle the content. Incidentally thats come up recently in Camel too; the type converter stuff is so useful, folks wanna use it for many different things when the Java class/interface is not enough to specify a conversion. e.g. convert to Java Object using JAXB2 versus serialization versus SOAP encoding I guess this is no longer type conversion, but more content conversion - so maybe a separate API is required. But certainly folks wanna be able to do things like // specify the required Java type and content type InputStream in = message.getBody(InputStream.class, "application/ xml"); But am wondering if for things like content type / content encoding stuff we need a separate kind of mechanism than the Java type conversion stuff; or if we could just extend the model to include content type as well? I agree. The type converter api is not necessarily the best suited for our needs here and may be more suited for converting properties rather than the body. There are lots of different things here. We need to be able to send xml documents, binary streams and POJOs: this would cover most of the needs I guess. Then, some content type may be able to be converted from one format to another: a jaxb2 pojo may be transformed to xml, a JSON stream may be converted to xml too using http://jettison.codehaus.org/), but I'm not sure how far we should go as there may be lots of different ways to convert data between different formats. Complex transformations may need to be more tightly controlled by using an endpoint. Cheers, Guillaume Nodet -- James --- http://macstrac.blogspot.com/
Lifecycle and governance (was Re: ServiceMix 4.0)
Terry, I'm just starting a new thread here so that it will be easier to follow the discussions. Any ideas are welcome... Cheers, Guillaume Nodet On Aug 23, 2007, at 1:00 AM, Terry Cox wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry
ServiceMix 4.0 and federation (was Re: ServiceMix 4.0)
Hi Kit, I'm quite sure you would have a very valuable input there, given your experience on ServiceMix. So I'm starting this new thread. Would you mind throwing a few ideas there ? Cheers, Guillaume Nodet On Aug 23, 2007, at 5:39 AM, Kit Plummer wrote: On 8/22/07, Terry Cox <[EMAIL PROTECTED]> wrote: Interesting. We need to have a very serious chat about application lifecycles and governance... Terry And Federating...distribution of the NMR across n-platforms! -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
