Re: Trifork CORBA
At 09:39 AM 10/28/2005, Kresten Krab Thorup wrote: The Trifork RMI/IIOP has a quite decent implementation of all of the javax.rmi.CORBA stuff that we can bring right in with little modification, so I was thinking that we should use that. However, if you know that those ValueHandlers are good, we can definitively make things less complicated by using them. I'm merely advocating walking before running ;). The only real reason for not using these pieces is performance, and even then the performance of the underlying streams is far more important. We don't even use our own ValueHandler for FVD serialization, just because its complicated, slow and not worth reinventing the wheel for. If you get run over by a bus, its going to be non-trivial for someone to figure out issues with a home-grown ValueHandler... andy
Re: Trifork CORBA
At 08:07 PM 10/27/2005, Matt Hogstrom wrote: I think for those platforms you mention below the IBM is the only JDK to choose from. Although, on Windows and Linux its a pretty good choice too :) Of course I would beg to differ ;) Have you fired G up on JRockit yet? I'd be curious to compare performance data. I know it works. I don't have any hard numbers that I can share. andy
Re: Trifork CORBA
On Oct 27, 2005, at 5:06 PM, Andy Piper wrote: The latest JRockit implements the appropriate parts of Unsafe - I know because I made them put it in so that I could implement the WebLogic ValueHandler on top of it. But why not just use the VM's ValueHandler? The Sun and IBM one's are both pretty reasonable now. The Trifork RMI/IIOP has a quite decent implementation of all of the javax.rmi.CORBA stuff that we can bring right in with little modification, so I was thinking that we should use that. However, if you know that those ValueHandlers are good, we can definitively make things less complicated by using them. Kresten
Re: Trifork CORBA
On 10/27/2005 5:39 AM, Kresten Krab Thorup wrote: There is no doubt in my mind that we should build a complete stand- alone and quality ORB. Once we're up and running, we might even see Sun chime in, and have them adopt this the same way we've seen with many other Apache Java projects. There - that would be a goal. +1 Regards, Alan
Re: Trifork CORBA
pache.org> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 I think for those platforms you mention below the IBM is the only JDK to choose from. Although, on Windows and Linux its a pretty good choice too :) Have you fired G up on JRockit yet? I'd be curious to compare performance data. Cheers. Andy Piper wrote: > Somehow my spam filter removed your original e-mail > > At 07:09 PM 10/26/2005, Rick McGuire wrote: > >>> Actually, then don't. The IBM JVM certainly doesn't, and I don't >>> believe JRocket does either. And it is > > > JRockit uses the Sun ORB. The IBM VM is the notable exception I referred > to. That's why I asked why it was critical. Seems its only critical if > you want to run on AIX or OS/390, but then I guess some do ... > > andy > > > > >
Re: Trifork CORBA
Somehow my spam filter removed your original e-mail At 07:09 PM 10/26/2005, Rick McGuire wrote: Actually, then don't. The IBM JVM certainly doesn't, and I don't believe JRocket does either. And it is JRockit uses the Sun ORB. The IBM VM is the notable exception I referred to. That's why I asked why it was critical. Seems its only critical if you want to run on AIX or OS/390, but then I guess some do ... andy
Re: Trifork CORBA
At 01:51 PM 10/27/2005, Kresten Krab Thorup wrote: One issue is that RMI needs to be able to write the value of a final instance field (to de-serialize an object) and this is something that cannot be done with reflection. So for this we are using com.sun.Unsafe (which is the internal Sun API to implement reflection). This is also there in the IBM VMs, but JRockit has another API to accomplish the same thing. The other thing is being able to call constructors in the particular way needed when de-serializing instances of classes that have no public no-arg constructor. For this, we generally need to call into VM-specific private static methods also. The latest JRockit implements the appropriate parts of Unsafe - I know because I made them put it in so that I could implement the WebLogic ValueHandler on top of it. But why not just use the VM's ValueHandler? The Sun and IBM one's are both pretty reasonable now. andy
Re: Trifork CORBA
You can have a J2EE 1.4 compatible product which soley supports J2SE 1.5 as long as your implementation passes CTS. The minimum requirement is J2SE 1.4. Jacek Laskowski wrote: John Sisson wrote: I think we should be supporting 1.4.2 (and 1.5) for a while, as many large enterprise systems are slow (like a year or two behind) to move to recent (1.5) versions of Java, for many reasons. J2EE 1.4 requires Java 1.4 whereas Java EE 1.5 does Java 5 (the acronyms used in these forms intentionally). So, we can't simply say 'we should', but it's a must to be J2EE 1.4-compliant *and* certified. John Jacek
Re: Trifork CORBA
On Oct 26, 2005, at 7:39 PM, Matt Hogstrom wrote: Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. There is a single thing in the RMI/IIOP which is difficult to do portably, and so the new orb needs to have this as a VM-specific plug in mechanism. One issue is that RMI needs to be able to write the value of a final instance field (to de-serialize an object) and this is something that cannot be done with reflection. So for this we are using com.sun.Unsafe (which is the internal Sun API to implement reflection). This is also there in the IBM VMs, but JRockit has another API to accomplish the same thing. The other thing is being able to call constructors in the particular way needed when de-serializing instances of classes that have no public no-arg constructor. For this, we generally need to call into VM-specific private static methods also. Both of the above is something that the given VM's RMI implementaion (specifically java.io.ObjectStreamClass) would need to realize. So to the extend that it is permissible to reverse engineer the implementaition of ObjectStreamClass, we can extract what's needed to do this. Apart from this, the ORB can be completely portable. /Kresten
Re: Trifork CORBA
I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. Sure, there is not an orb there yet; and so I understand your point of view. What's not there is a lot of stuff, including all the server-side handling (POA implementation), as well as local invocation semantics (i.e., avoiding serializing arguments for local calls). And also the character encoding stuff is not in there, since the original trifork orb only implemented the absolute minimum requirements to support isolatin-1 and 16-bit unicode. This is probably fine for most western countries, but will not do it in arabic or eastern asia. So there's a lot of stuff missing. Let me repeat what motivates me: I'm sick and tired of being the only one at Trifork that really knows the CORBA implementation, and this is my chance to get out of it. I'm willing to put a lot of effort into making a new free orb (that Trifork can also use), but I want to make sure that I'm not the only go-to guy for problems with it when we're up and running. So, Trifork needs an orb as much as Geronimo does, but at the same time we want to get out of the CORBA business. Also, I want to take this opportunity to avoid doing some of the same mistakes I did in the first implementation, and get many things right (as you like to say you do with Geronimo). So this is also a chance to do some things much better. For these reasons I want to be part of writing a new ORB. The integration between CORBA and OpenEJB as it is right now in G is quite standard; using standard POA interfaces and so forth, and so here I don't expect that there should be any serious issues once we get to that point. Integrating security and SSL is something where every orb is different because as far as I know this is not spec'd (or is it in CORBA 2.6?). But here, we can do whatever fits best with what is already there in the Geronimo code. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. There is no doubt in my mind that we should build a complete stand- alone and quality ORB. Once we're up and running, we might even see Sun chime in, and have them adopt this the same way we've seen with many other Apache Java projects. There - that would be a goal. What is your plan to get people involved? I think we need to spend some time talking here about goals and priorities, and then I would expect that the people that are interested and capable of helping out would come forward as part of such discussions. One interesting discussion that you brought up at EURO-OSCON is the relationship with ActiveIO. So. I'll post a separate mail on that issue. /Kresten -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side
Re: Trifork CORBA
As far as I remember, with the 1.3 CTS there was signature tests that would allow testing "J2EE 1.3 Compatible" on a 1.4 VM. I have not seen the equivalent J2EE 1.4 tests, but there may be (or perhaps coming) a similar set of tests that allow a J2EE 1.4 compatibility test to complete on a Java 5 VM. BTW, Java EE marketing has been pushing to use the term Java EE Compatible Not certified, not compliant or other terms, but "compatible". I think it is fair to support this phrasing as we are part of this marketing effort of the Java EE brand. Kresten Krab Thorup [EMAIL PROTECTED] "We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery On Oct 27, 2005, at 12:43 PM, Jacek Laskowski wrote: John Sisson wrote: I think we should be supporting 1.4.2 (and 1.5) for a while, as many large enterprise systems are slow (like a year or two behind) to move to recent (1.5) versions of Java, for many reasons. J2EE 1.4 requires Java 1.4 whereas Java EE 1.5 does Java 5 (the acronyms used in these forms intentionally). So, we can't simply say 'we should', but it's a must to be J2EE 1.4-compliant *and* certified. John Jacek
Re: Trifork CORBA
One reason is that we may need something like this for harmony... On Oct 26, 2005, at 1:16 PM, Andy Piper wrote: At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. andy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Trifork CORBA
John Sisson wrote: I think we should be supporting 1.4.2 (and 1.5) for a while, as many large enterprise systems are slow (like a year or two behind) to move to recent (1.5) versions of Java, for many reasons. J2EE 1.4 requires Java 1.4 whereas Java EE 1.5 does Java 5 (the acronyms used in these forms intentionally). So, we can't simply say 'we should', but it's a must to be J2EE 1.4-compliant *and* certified. John Jacek
Re: Trifork CORBA
Lars Kühne wrote: Alan D. Cabrera wrote: I want to extend an invitation out to all the OpenORB developers who might be interested in helping out. Lots of great work out here! I'm one of them, but I don't use Geronimo and I haven't looked at G's architecture. Some of these points have already been made in this thread: 1. The code really should be in cvs/svn so it's easy to send in patches. 2. The code needs to be buildable, and preferably have tests, so it's easy to try out changes. 3. A high level description of the core code and the module structure above core would be great. It seems that the directory layout is designed to host other modules as well. What would these other modules be? Top level components like an IDL compiler and a NamingService implemenation? That would be cool, because I'm currently working on a Apache licensed IDL compiler. Once #1 is in place, I think I can start working on #2, although I can't promise more than maybe a few hours per week, and the ORB kernel is not my primary area of expertise within OpenORB. There certainly is demand for a complete Apache licensed ORB implementation outside Geronimo. Personally I would need that to replace OpenORB in our code (we use plain CORBA, without a container), but other projects like Apache Harmony would benfit as well. This means that there should be no dependency from the ORB core to Geronimo. Is support for Java 1.4 a requirement in Geronimo, and if yes then for how long? In Java 5 many infrastructure classes like j.u.concurrent and JMX are available without introducing any external dependencies, and support for SSL seems to be much better (no personal experience). Would it be OK for the ORB to require Java 5? I think we should be supporting 1.4.2 (and 1.5) for a while, as many large enterprise systems are slow (like a year or two behind) to move to recent (1.5) versions of Java, for many reasons. Could relying upon external dependencies be a positive.. e.g. a more supportable/patchable system, rather than having to wait for a fix in a later JDK release? Eventually we should drop support for 1.4.2, but hopefully not for a while. How do others feel about this? John Last but not least I'd like to thank Trifork for starting this initiative and donating their code. Regards, Lars
Re: Trifork CORBA
Alan D. Cabrera wrote: I want to extend an invitation out to all the OpenORB developers who might be interested in helping out. Lots of great work out here! I'm one of them, but I don't use Geronimo and I haven't looked at G's architecture. Some of these points have already been made in this thread: 1. The code really should be in cvs/svn so it's easy to send in patches. 2. The code needs to be buildable, and preferably have tests, so it's easy to try out changes. 3. A high level description of the core code and the module structure above core would be great. It seems that the directory layout is designed to host other modules as well. What would these other modules be? Top level components like an IDL compiler and a NamingService implemenation? That would be cool, because I'm currently working on a Apache licensed IDL compiler. Once #1 is in place, I think I can start working on #2, although I can't promise more than maybe a few hours per week, and the ORB kernel is not my primary area of expertise within OpenORB. There certainly is demand for a complete Apache licensed ORB implementation outside Geronimo. Personally I would need that to replace OpenORB in our code (we use plain CORBA, without a container), but other projects like Apache Harmony would benfit as well. This means that there should be no dependency from the ORB core to Geronimo. Is support for Java 1.4 a requirement in Geronimo, and if yes then for how long? In Java 5 many infrastructure classes like j.u.concurrent and JMX are available without introducing any external dependencies, and support for SSL seems to be much better (no personal experience). Would it be OK for the ORB to require Java 5? Last but not least I'd like to thank Trifork for starting this initiative and donating their code. Regards, Lars
Re: Trifork CORBA
Kresten Krab Thorup wrote, On 10/26/2005 7:51 AM: As Alan suggests, I think we should try to find the people that are interested in participating in this project, and start working on some adding stuff to the Wiki in relations to this. I think we need to find a smaller forum where we can discuss the architecture of the ORB itself. How do you normally launch new development efforts? As others have mentioned, discussions should take place here. One discussion which would be worthy here on the general dev list is how the ORB will be used. In the Trifork server we do all RMI via IIOP using CORBA, and all local RMI invocations go via the CORBA implementation. We do clustering, transactions and security via the CORBA implementation, and so this puts another pressure on the quality of the ORB. CORBA/IIOP, as backwards and complicated as it may seem, still has many nice properties that facilitate low resource consumption and good stability for networked applications. If, in Geronimo, the ORB is "just" there to satisfy interoperability needs, and not something that is crucial to the successful deployment of Geronimo servers and used as the backbone of the EJB container for instance; then this effort needs to be prioritized for such needs. That means, for instance, that performance is not a critical issue for the ORB. And we can definitively simplify many things if CORBA performance is deemed non-important. I would like to have a full blown CORBA server for Geronimo. How it would interact in terms of using it exclusively for EJB would be tough to say since I do not have the code in front of me. Regards, Alan
Re: Trifork CORBA
Calvin Austin wrote: Rick McGuire wrote: Andy Piper wrote: At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. Actually, then don't. The IBM JVM certainly doesn't, and I don't believe JRocket does either. And it is not particularly easy to write code code that supports both 1.4 and 5.0 Sun ORBs because of difficulties hooking in the SSL support. You also run into issues trying to build the code, since for any given JVM, only one of the versions of the ORB adaptors will compile correctly. Technically the J2SE 5.0 reference ORB was supposed to be portable and interoperable and pluggable as Sun uses a modified version of that ORB for its own products. I've tried to forget the headaches we had with CORBA experience with JDK 5.0 but if there is anything I can do to make the Geronimo completely work with JDK 5.0 I'm all ears The real challenge with Geronimo was enabling the ORB to use an SSL transport. With the 1.4.2 version, this could only be done by using/referencing Sun implementation classes. Most of those classes have been renamed to other packages (many with the word "legacy" in the package name), and some don't exist in any form. If the 5.0 ORB has portable interfaces for hooking in SSL, writing the appropriate adaptors would be an interesting exercise. I've got a pretty good understanding of how the 1.4.2 ORB is hooked in, if you need assistance understanding what it's doing. regards calvin andy
Re: Trifork CORBA
Rick McGuire wrote: Andy Piper wrote: At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. Actually, then don't. The IBM JVM certainly doesn't, and I don't believe JRocket does either. And it is not particularly easy to write code code that supports both 1.4 and 5.0 Sun ORBs because of difficulties hooking in the SSL support. You also run into issues trying to build the code, since for any given JVM, only one of the versions of the ORB adaptors will compile correctly. Technically the J2SE 5.0 reference ORB was supposed to be portable and interoperable and pluggable as Sun uses a modified version of that ORB for its own products. I've tried to forget the headaches we had with CORBA experience with JDK 5.0 but if there is anything I can do to make the Geronimo completely work with JDK 5.0 I'm all ears regards calvin andy
Re: Trifork CORBA
Andy Piper wrote: At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. Actually, then don't. The IBM JVM certainly doesn't, and I don't believe JRocket does either. And it is not particularly easy to write code code that supports both 1.4 and 5.0 Sun ORBs because of difficulties hooking in the SSL support. You also run into issues trying to build the code, since for any given JVM, only one of the versions of the ORB adaptors will compile correctly. andy
Re: Trifork CORBA
pache.org> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> In-Reply-To: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MMS-Smtp-Program: Macallan-Mail-Solution; Version 4.6.0.1 X-MMS-Smtp-Auth: Authenticated As [EMAIL PROTECTED] X-MMS-Smtp-Mailer-Program: Macallan-Mail-Solution; Version 4.6.0.1 Andy, does JRockit use the Sun ORB? I know IBM's doesn't. Matt Andy Piper wrote: > At 04:26 PM 10/26/2005, Rick McGuire wrote: > >> The most critical need right now is to have a replacement to the Sun >> ORB that would allow portability to other JVM impelementations. The >> lack of a full-function compliant ORB is the main factor locking >> Geronimo in to the Sun 1.4.2 JVM. >> I think the general view of the CORBA support is that of a "necessary >> evil". It is required for J2EE certifcation, but is not generally >> seen as critical to most Geronimo deployments. My personal view of >> the priorities is "get it working, get it portable". Issues such as >> additional uses or higher peformance are things to consider after the >> primary requirements are fullfilled. > > > Can I ask why portability is critical? Most VM's (with one notable > exception) use the Sun ORB so depending on it doesn't seem such a big > deal to me, especially if its a necessary evil. I agree support for J2SE > 5.0 is essential, but its pretty easy to write code that supports both > 1.4 and 5.0 ORBs. > > andy > > >
Re: Trifork CORBA
At 04:26 PM 10/26/2005, Rick McGuire wrote: The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Can I ask why portability is critical? Most VM's (with one notable exception) use the Sun ORB so depending on it doesn't seem such a big deal to me, especially if its a necessary evil. I agree support for J2SE 5.0 is essential, but its pretty easy to write code that supports both 1.4 and 5.0 ORBs. andy
Re: Trifork CORBA
Kresten Krab Thorup wrote: As Alan suggests, I think we should try to find the people that are interested in participating in this project, and start working on some adding stuff to the Wiki in relations to this. I think we need to find a smaller forum where we can discuss the architecture of the ORB itself. How do you normally launch new development efforts? I agree with Geir that the project discussions should be done primarily on the dev list. One discussion which would be worthy here on the general dev list is how the ORB will be used. In the Trifork server we do all RMI via IIOP using CORBA, and all local RMI invocations go via the CORBA implementation. We do clustering, transactions and security via the CORBA implementation, and so this puts another pressure on the quality of the ORB. CORBA/IIOP, as backwards and complicated as it may seem, still has many nice properties that facilitate low resource consumption and good stability for networked applications. If, in Geronimo, the ORB is "just" there to satisfy interoperability needs, and not something that is crucial to the successful deployment of Geronimo servers and used as the backbone of the EJB container for instance; then this effort needs to be prioritized for such needs. That means, for instance, that performance is not a critical issue for the ORB. And we can definitively simplify many things if CORBA performance is deemed non-important. The most critical need right now is to have a replacement to the Sun ORB that would allow portability to other JVM impelementations. The lack of a full-function compliant ORB is the main factor locking Geronimo in to the Sun 1.4.2 JVM. I think the general view of the CORBA support is that of a "necessary evil". It is required for J2EE certifcation, but is not generally seen as critical to most Geronimo deployments. My personal view of the priorities is "get it working, get it portable". Issues such as additional uses or higher peformance are things to consider after the primary requirements are fullfilled. Let me know what you think. What should be the priorities here? Kresten On Oct 25, 2005, at 5:35 PM, Geir Magnusson Jr. wrote: I think that the intention here is pretty clear. How do you think we should get started? geir On Oct 25, 2005, at 11:31 AM, Dain Sundstrom wrote: I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. What is your plan to get people involved? -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code
Re: Trifork CORBA
On Oct 26, 2005, at 10:51 AM, Kresten Krab Thorup wrote: As Alan suggests, I think we should try to find the people that are interested in participating in this project, and start working on some adding stuff to the Wiki in relations to this. I think we need to find a smaller forum where we can discuss the architecture of the ORB itself. How do you normally launch new development efforts? You should do the discussion here for maximum visibility and participation, and use the wiki for summarization. There is a tendency to (IMO) overuse IRC because it limits participation. (The flip side is that it's great for quick discussions...) So ultimately, I think you are on the right track starting here. Question - is the code that was submitted to JIRA buildable? Are there any test cases yet? I looked at the code and couldn't find anythign geir One discussion which would be worthy here on the general dev list is how the ORB will be used. In the Trifork server we do all RMI via IIOP using CORBA, and all local RMI invocations go via the CORBA implementation. We do clustering, transactions and security via the CORBA implementation, and so this puts another pressure on the quality of the ORB. CORBA/IIOP, as backwards and complicated as it may seem, still has many nice properties that facilitate low resource consumption and good stability for networked applications. If, in Geronimo, the ORB is "just" there to satisfy interoperability needs, and not something that is crucial to the successful deployment of Geronimo servers and used as the backbone of the EJB container for instance; then this effort needs to be prioritized for such needs. That means, for instance, that performance is not a critical issue for the ORB. And we can definitively simplify many things if CORBA performance is deemed non-important. Let me know what you think. What should be the priorities here? Kresten On Oct 25, 2005, at 5:35 PM, Geir Magnusson Jr. wrote: I think that the intention here is pretty clear. How do you think we should get started? geir On Oct 25, 2005, at 11:31 AM, Dain Sundstrom wrote: I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. What is your plan to get people involved? -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side
Re: Trifork CORBA
As Alan suggests, I think we should try to find the people that are interested in participating in this project, and start working on some adding stuff to the Wiki in relations to this. I think we need to find a smaller forum where we can discuss the architecture of the ORB itself. How do you normally launch new development efforts? One discussion which would be worthy here on the general dev list is how the ORB will be used. In the Trifork server we do all RMI via IIOP using CORBA, and all local RMI invocations go via the CORBA implementation. We do clustering, transactions and security via the CORBA implementation, and so this puts another pressure on the quality of the ORB. CORBA/IIOP, as backwards and complicated as it may seem, still has many nice properties that facilitate low resource consumption and good stability for networked applications. If, in Geronimo, the ORB is "just" there to satisfy interoperability needs, and not something that is crucial to the successful deployment of Geronimo servers and used as the backbone of the EJB container for instance; then this effort needs to be prioritized for such needs. That means, for instance, that performance is not a critical issue for the ORB. And we can definitively simplify many things if CORBA performance is deemed non-important. Let me know what you think. What should be the priorities here? Kresten On Oct 25, 2005, at 5:35 PM, Geir Magnusson Jr. wrote: I think that the intention here is pretty clear. How do you think we should get started? geir On Oct 25, 2005, at 11:31 AM, Dain Sundstrom wrote: I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. What is your plan to get people involved? -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. On Oct 25, 2005, at 7:40 AM, Geir Magnusson Jr. wrote: Kresten, Can you take the main comment of the JIRA and post here on the list? Having a threaded discus
Re: Trifork CORBA
I want to extend an invitation out to all the OpenORB developers who might be interested in helping out. Lots of great work out here! Regards, Alan Dain Sundstrom wrote, On 10/25/2005 8:19 AM: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. On Oct 25, 2005, at 7:40 AM, Geir Magnusson Jr. wrote: Kresten, Can you take the main comment of the JIRA and post here on the list? Having a threaded discussion in JIRA is awful. Welcome, thanks for the contribution, and I look forward for more discussion here. geir On Oct 25, 2005, at 10:29 AM, Kresten Krab Thorup (JIRA) wrote: Use Trifork CORBA (freeorb -- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Trifork CORBA
I think that the intention here is pretty clear. How do you think we should get started? geir On Oct 25, 2005, at 11:31 AM, Dain Sundstrom wrote: I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. What is your plan to get people involved? -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. On Oct 25, 2005, at 7:40 AM, Geir Magnusson Jr. wrote: Kresten, Can you take the main comment of the JIRA and post here on the list? Having a threaded discussion in JIRA is awful. Welcome, thanks for the contribution, and I look forward for more discussion here. geir On Oct 25, 2005, at 10:29 AM, Kresten Krab Thorup (JIRA) wrote: Use Trifork CORBA (freeorb -- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Trifork CORBA
That's what I asked Kresten to forward to the list :) geir On Oct 25, 2005, at 11:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. On Oct 25, 2005, at 7:40 AM, Geir Magnusson Jr. wrote: Kresten, Can you take the main comment of the JIRA and post here on the list? Having a threaded discussion in JIRA is awful. Welcome, thanks for the contribution, and I look forward for more discussion here. geir On Oct 25, 2005, at 10:29 AM, Kresten Krab Thorup (JIRA) wrote: Use Trifork CORBA (freeorb -- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: Trifork CORBA
I pulled down the code an it looks like a lot of IIOP stuff is there, what is missing for a full ORB? I'm not sure how I can help with this without the full orb code. If we had that, I could try integrating it into OpenEJB, but I am completely lost. I had this same problem with the last IIOP donation, which was also just IO code, and I hope to not repeat the experience. What is your plan to get people involved? -dain On Oct 25, 2005, at 8:19 AM, Dain Sundstrom wrote: For those of you that missed it Kresten wrote in the JIRA entry: As has been discussed previously, Trifork wants to donate a CORBA implementation. This message is to get things really started in context of Geronimo. Along with this message is a tar ball of the initial contribution, and I want to take this opportunity to describe what we are donating and how we would like to do this. To set things straight, will not be donating a full CORBA implementation up front. What we are proposing is to donate the resources (read: developers) that it takes to do a full CORBA implementation in context of Apache Geronimo. Our concern with donating the full code is that we want to ensure that this is built as a community effort, so when we're done we are not the "single point of failure" for this to succeed as we go forward. We would like to avoid being the only ones to know the code, so that the CORBA implementation that comes out of this is something that can have a life without us pushing it forward. This is really the principal value that we see in contributing to this project. We want to have a free and independent CORBA implementation too, but we would like to avoid being stuck on it as we go forward. Having said all that, we do have a CORBA implementation; and in our effort to bring this forward we will definitively use bits, pieces or even large chunks of this to make the Apache Geronimo CORBA implementation be complete and successful. We know that there is eagerness in the Geronimo community to get things started in building a CORBA solution, and so hopefully this first contribution will be accepted as a starting point from which we will build a world-class CORBA system. What is in this package is the foundation of a new I/O subsystem that I have previously talked about, and some of the code to hook that up with the client-side of the CORBA stack. As such, thins chunk of code is not in even self-contained nor complete. It's just the state of the code in our lab right now, and we want to move this into Geronimo space before we get too far along. The mile stones that I imagine moving forward from here would be something like this: 1. Client-side stream-based invocation. 2. Value semantics (object serialization) 3. Server-side stream-based invocation handling, including POA implementation. 4. Dynamic stubs. 5. Local invocations. There are a ton of sub-projects that I would love to see someone starting on; some of which already have place holders or stubs in the code that is part of the tar ball attached to this. On Oct 25, 2005, at 7:40 AM, Geir Magnusson Jr. wrote: Kresten, Can you take the main comment of the JIRA and post here on the list? Having a threaded discussion in JIRA is awful. Welcome, thanks for the contribution, and I look forward for more discussion here. geir On Oct 25, 2005, at 10:29 AM, Kresten Krab Thorup (JIRA) wrote: Use Trifork CORBA (freeorb -- Key: GERONIMO- URL: http://issues.apache.org/jira/browse/GERONIMO- Project: Geronimo Type: New Feature Components: CORBA Versions: 1.1 Reporter: Kresten Krab Thorup -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: TriFork CORBA donation
How are things going? Do you think that it's possible to get the code
in our repo and you work from there?
Regards,
Alan
Kresten Krab Thorup wrote, On 9/16/2005 9:04 AM:
Hi there, ...
It has been up to a slow start, but I have finally gotten something
rolling now.
As I have mentioned earlier, I wanted to redo the I/O subsystem, and
this is going quite well. The first milestone I am targeting is to
be able to do client side stream-based invocations; i.e. be able to
do invocations using a generated stub. This is a sufficiently small
thing that it is doable relatively quick (sigh), and also gets around
to do most of the hairy parts of I/O.
This part I am writing from scratch, since the new I/O transcends
most of this code. This part is quite close to completion, and if
someone wants to see the code I'd be happy to share it. Here, I have
some notes on the I/O system; ...
The I/O system is designed with the following properties:
- it eliminates copying (double buffering)
- i/o can be off-loaded to a separate selector thread
- nio/select is used to avoid having an active thread listening for
incoming messages
- transport buffers are allocated only once, and have fixed size.
- facilitate multiplexing requests and bidirectional invocations.
In this terminology, a transport (which may be a socket or an in-
memory pipe, for instance) has the following API:
interface Transport {
InputChannel getInputChannel();
OutputChannel getOutputChannel();
void setInputHandler(InputHandler handler);
void close();
void start();
void signalCondition(Object conditionKey, Object user_data);
Object waitForCondition(Object conditionKey);
}
Only one thread can have the input channel at one time, and only one
thread can have the output channel. Calls to getInputChannel(), and
getOutputChannel() will block until the channel is available. If
someone else has "taken" the channel, then the requestor will block
until the other party relinquishes it. This semantics is used to
handle multiplexing multiple client threads using the same transport
to do invocation, and similarily on the server side to handle
multiple threads sending responses.
interface Channel {
void close();
void relinquish();
}
Closing a channel semantically puts an end-of-stream marker into the
channel's data. For an OutputChannel, once the EOS reaches the
underlying transport layer (i.e. the data ahead of it has been
written), it is effectuated as a half-close. For an InputChannel,
the half-close is effectuated right away, and the client of the input
stream will read and end-of-file when there is no more buffered data
available.
When input becomes available in the underlying transport, and there
is no current thread that owns the input channel, then control is
passed to the input handler in a new thread taken from some worker pool.
The transport also has a built-in signaling mechanism, that allows
the InputHandler to parse a message header (including e.g. a
request_id) and then pass control to someone waiting for a given
reply. Such waiters can also participate in the processing of
available input.
An output channel allows you to put data into the transport, and
provides a mechanism to set markers. Markers are used to handle
fragmentation and other things where a size needs to be written into
some place in the stream.
interface OutputChannel extends Channel {
putByte(byte value);
put(byte[] data, int off, int len);
// ... other put methods ...
void flush();
OutputChannelMark setMark(OutputChannelMarkHandler handler);
}
Now, if the output channel's buffer runs full, then the mark handler
is called, so that the
interface OutputChannelMarkHandler {
void willFlush(OutputChannelMark mark);
}
OutputChannelMark provides a ByteBuffer-like view of the stream,
where index 0 is the position of the marker. You cannot put data
beyond the mark's limit, which is equal to the amount of bytes
written to the channel since the mark.
interface OutputChannelMark {
void putByte(int idx, byte value);
void putInt(int idx, int value);
int limit();
void release();
OutputChannel getOutputChannel();
}
Calling release() on an OutputChannelMark will release underlying
buffer space up to this mark (unless of cause there is a non-released
marker that was set earlier in the stream).
The OutputChannelMark can also give you the channel that i came from,
and so inside the handler you can do stuff like this to handle GIOP
fragmentation dynamically based on when the underlying buffer runs full.
class FragmentHandler implements OutputChannelMarkHandler {
void willFlush( OutputChannelMark mark) {
int message_size = mark.limit();
if (!logical_stream_has_ended) {
mark.putByte(7, 2); // write "hasMoreFragments" bit
}
mark.putInt (8, messag
Re: TriFork CORBA donation
Kresten Krab Thorup wrote: Hi there, ... Hi Kresten, I'm not prepared to comment on the details, but have a general question. - nio/select is used to avoid having an active thread listening for incoming messages It sounds like Java 5. Will it require this Java version? Geronimo is 1.4-based. Kresten Krab Thorup Jacek
Re: TriFork CORBA donation
Hi there, ...
It has been up to a slow start, but I have finally gotten something
rolling now.
As I have mentioned earlier, I wanted to redo the I/O subsystem, and
this is going quite well. The first milestone I am targeting is to
be able to do client side stream-based invocations; i.e. be able to
do invocations using a generated stub. This is a sufficiently small
thing that it is doable relatively quick (sigh), and also gets around
to do most of the hairy parts of I/O.
This part I am writing from scratch, since the new I/O transcends
most of this code. This part is quite close to completion, and if
someone wants to see the code I'd be happy to share it. Here, I have
some notes on the I/O system; ...
The I/O system is designed with the following properties:
- it eliminates copying (double buffering)
- i/o can be off-loaded to a separate selector thread
- nio/select is used to avoid having an active thread listening for
incoming messages
- transport buffers are allocated only once, and have fixed size.
- facilitate multiplexing requests and bidirectional invocations.
In this terminology, a transport (which may be a socket or an in-
memory pipe, for instance) has the following API:
interface Transport {
InputChannel getInputChannel();
OutputChannel getOutputChannel();
void setInputHandler(InputHandler handler);
void close();
void start();
void signalCondition(Object conditionKey, Object user_data);
Object waitForCondition(Object conditionKey);
}
Only one thread can have the input channel at one time, and only one
thread can have the output channel. Calls to getInputChannel(), and
getOutputChannel() will block until the channel is available. If
someone else has "taken" the channel, then the requestor will block
until the other party relinquishes it. This semantics is used to
handle multiplexing multiple client threads using the same transport
to do invocation, and similarily on the server side to handle
multiple threads sending responses.
interface Channel {
void close();
void relinquish();
}
Closing a channel semantically puts an end-of-stream marker into the
channel's data. For an OutputChannel, once the EOS reaches the
underlying transport layer (i.e. the data ahead of it has been
written), it is effectuated as a half-close. For an InputChannel,
the half-close is effectuated right away, and the client of the input
stream will read and end-of-file when there is no more buffered data
available.
When input becomes available in the underlying transport, and there
is no current thread that owns the input channel, then control is
passed to the input handler in a new thread taken from some worker pool.
The transport also has a built-in signaling mechanism, that allows
the InputHandler to parse a message header (including e.g. a
request_id) and then pass control to someone waiting for a given
reply. Such waiters can also participate in the processing of
available input.
An output channel allows you to put data into the transport, and
provides a mechanism to set markers. Markers are used to handle
fragmentation and other things where a size needs to be written into
some place in the stream.
interface OutputChannel extends Channel {
putByte(byte value);
put(byte[] data, int off, int len);
// ... other put methods ...
void flush();
OutputChannelMark setMark(OutputChannelMarkHandler handler);
}
Now, if the output channel's buffer runs full, then the mark handler
is called, so that the
interface OutputChannelMarkHandler {
void willFlush(OutputChannelMark mark);
}
OutputChannelMark provides a ByteBuffer-like view of the stream,
where index 0 is the position of the marker. You cannot put data
beyond the mark's limit, which is equal to the amount of bytes
written to the channel since the mark.
interface OutputChannelMark {
void putByte(int idx, byte value);
void putInt(int idx, int value);
int limit();
void release();
OutputChannel getOutputChannel();
}
Calling release() on an OutputChannelMark will release underlying
buffer space up to this mark (unless of cause there is a non-released
marker that was set earlier in the stream).
The OutputChannelMark can also give you the channel that i came from,
and so inside the handler you can do stuff like this to handle GIOP
fragmentation dynamically based on when the underlying buffer runs full.
class FragmentHandler implements OutputChannelMarkHandler {
void willFlush( OutputChannelMark mark) {
int message_size = mark.limit();
if (!logical_stream_has_ended) {
mark.putByte(7, 2); // write "hasMoreFragments" bit
}
mark.putInt (8, message_size); // write message size
into GIOP header
mark.release();
if (!logical_stream_has_ended) {
mark.getOutputChannel().setMark(thi
Re: TriFork/CORBA meeting minutes
I know that a few people are interested in solving this using ActiveIO. Hiram? Regards, Alan Matt Hogstrom wrote, On 7/8/2005 5:49 PM: Is someone actively working on the generic interfaces for wrapping the SSL code? IBM is also interested in supporting this effort as it would make the IBM JDK a valid option as well as jRockit I'd suspect. We'd like to make sure we don't go off in the weeds to solve the same problem. Thoughts? - Matt - Original Message - From: "Alan D. Cabrera" <[EMAIL PROTECTED]> To: Sent: Friday, July 08, 2005 3:54 PM Subject: TriFork/CORBA meeting minutes A kickoff phone call meeting occured between TriFork and a few PMC members. July 8th 2005, 4:00pm GMT Attending: Kresten Krab Thorup - TriFork David Blevins Alan Cabrera Jeff Genender David Jenks Jacek Laskowski - had to leave early Geir Magnusson Aaron Mulder Dain Sundstrom Kresten explained some of the architectural bits of the TriFork CORBA server. There is a CORBA core and on top of it is the RMI/IIOP bridge. They use CORBA interceptors and some interesting code for sockets. The sockets code is like Tomcat's connectors. TriFork currently uses JacORB to compile IDL. Integration work w/ OpenEJB would use existing standard OMG CORBA interfaces with the exception of the SSL code, where the OMG spec is deficient. In this case a generic interface will be provided to make the code portable across different CORBA implementations. There was a discussion on how OpenEJB and Trifork handles the TX aspect of interop. David Jenks mentioned that we don't currently support TX interop nor do we have a JTS TM, and that we would like to support interop but not necessarily JTS. Kresten mentioned that JTS isn't quite adapted to support j2ca 1.5 TX inflow and that it would probably be plausible to wrap JTS around JTA although they currently do the reverse. The stages of work that were discussed were: stage 1: Extricate the CORBA server from the TriFork server. This is what will be submitted for Geronimo incubation. Kresten will be on vacation but he thinks that this will be ready in August. stage 2: Spruce up the code, e.g. - integrate OpenEJB code - add javadoc comments - add documentation - put in a keystore server - spruce up I/O code (maybe use ActiveIO) stage 3: get ready to graduate! The idea of stage 2 is to have raw code put into the incubator where Kresten and the community can work together. The group recommended that the CORBA project be incubated in Geronimo with the goal that it become a sub-project of Geronimo. I'm sure I left out some interesting bits. Please feel free to fill in the gaps. Regards, Alan
Re: TriFork/CORBA meeting minutes
Is someone actively working on the generic interfaces for wrapping the SSL code? IBM is also interested in supporting this effort as it would make the IBM JDK a valid option as well as jRockit I'd suspect. We'd like to make sure we don't go off in the weeds to solve the same problem. Thoughts? - Matt - Original Message - From: "Alan D. Cabrera" <[EMAIL PROTECTED]> To: Sent: Friday, July 08, 2005 3:54 PM Subject: TriFork/CORBA meeting minutes > A kickoff phone call meeting occured between TriFork and a few PMC > members. > > July 8th 2005, 4:00pm GMT > > Attending: > > Kresten Krab Thorup - TriFork > David Blevins > Alan Cabrera > Jeff Genender > David Jenks > Jacek Laskowski - had to leave early > Geir Magnusson > Aaron Mulder > Dain Sundstrom > > Kresten explained some of the architectural bits of the TriFork CORBA > server. There is a CORBA core and on top of it is the RMI/IIOP bridge. > They use CORBA interceptors and some interesting code for sockets. The > sockets code is like Tomcat's connectors. TriFork currently uses JacORB > to compile IDL. > > Integration work w/ OpenEJB would use existing standard OMG CORBA > interfaces with the exception of the SSL code, where the OMG spec is > deficient. In this case a generic interface will be provided to make > the code portable across different CORBA implementations. > > There was a discussion on how OpenEJB and Trifork handles the TX aspect > of interop. David Jenks mentioned that we don't currently support TX > interop nor do we have a JTS TM, and that we would like to support > interop but not necessarily JTS. Kresten mentioned that JTS isn't quite > adapted to support j2ca 1.5 TX inflow and that it would probably be > plausible to wrap JTS around JTA although they currently do the reverse. > > The stages of work that were discussed were: > > stage 1: Extricate the CORBA server from the TriFork server. This is > what will be submitted for Geronimo incubation. Kresten will be on > vacation but he thinks that this will be ready in August. > > stage 2: Spruce up the code, e.g. > > - integrate OpenEJB code > - add javadoc comments > - add documentation > - put in a keystore server > - spruce up I/O code (maybe use ActiveIO) > > stage 3: get ready to graduate! > > The idea of stage 2 is to have raw code put into the incubator where > Kresten and the community can work together. > > The group recommended that the CORBA project be incubated in Geronimo > with the goal that it become a sub-project of Geronimo. > > I'm sure I left out some interesting bits. Please feel free to fill in > the gaps. > > Regards, > Alan > > > > >
Re: TriFork/CORBA meeting minutes
Alan D. Cabrera wrote: A kickoff phone call meeting occured between TriFork and a few PMC members. July 8th 2005, 4:00pm GMT Thanks Alan for the minutes. I wish I had been longer, but had to leave. It was my pleasure to hear you all. What a fun to hear you after so much time working together offline. My wife would have killed me if I had been longer - the dinner was fabolous! I remember I left when Aaron called in. I wonder how long I should have stayed to have a chance to talk to others. They were late, weren't they? ;) Anyway, I'd propose that we need to get in habit to make CCs often. It's such a fun to hear instead of read! ;) Alan Jacek
