You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org> on 2005/10/25 16:29:55 UTC
[jira] Created: (GERONIMO-1111) Use Trifork CORBA (freeorb
Use Trifork CORBA (freeorb
--------------------------
Key: GERONIMO-1111
URL: http://issues.apache.org/jira/browse/GERONIMO-1111
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
Re: Trifork CORBA
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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 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-1111
>>>>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>>>>> 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
>>>>> geirm@apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Trifork CORBA
Posted by Andy Piper <an...@bea.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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
Posted by Calvin Austin <ca...@spikesource.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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
geirm@apache.org
Re: Trifork CORBA
Posted by Andy Piper <an...@bea.com>.
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
Posted by Rick McGuire <ri...@gmail.com>.
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 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-1111
>>>>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>>>>> 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
>>>>> geirm@apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Geir Magnusson Jr +1-203-665-6437
>> geirm@apache.org
>>
>>
>>
>
>
Re: Trifork CORBA
Posted by Kresten Krab Thorup <kr...@trifork.com>.
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 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-1111
>>>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>>>> 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
>>>> geirm@apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> --
> Geir Magnusson Jr +1-203-665-6437
> geirm@apache.org
>
>
>
Re: Trifork CORBA
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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-1111
>>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>>> 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
>>> geirm@apache.org
>>>
>>>
>>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: Trifork CORBA
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Posted by Kresten Krab Thorup <kr...@trifork.com>.
> 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 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-1111
>>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>>> 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
>>> geirm@apache.org
>>>
>>>
>>>
>>
>>
>
>
Re: Trifork CORBA
Posted by Andy Piper <an...@bea.com>.
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
Posted by Kresten Krab Thorup <kr...@trifork.com>.
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
Posted by Andy Piper <an...@bea.com>.
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
Posted by Kresten Krab Thorup <kr...@trifork.com>.
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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
pache.org> <ED...@trifork.com> <43...@gmail.com> <6....@bea.com>
In-Reply-To: <6....@bea.com>
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 matt@hogstrom.org
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
Posted by Andy Piper <an...@bea.com>.
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
Posted by Matt Hogstrom <ma...@hogstrom.org>.
pache.org> <ED...@trifork.com> <43...@gmail.com> <6....@bea.com> <43...@gmail.com> <43...@spikesource.com> <6....@bea.com>
In-Reply-To: <6....@bea.com>
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 matt@hogstrom.org
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
Posted by Dain Sundstrom <da...@iq80.com>.
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-1111
>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>> 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
>> geirm@apache.org
>>
>>
>
Re: Trifork CORBA
Posted by "Lance J. Andersen" <La...@Sun.COM>.
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
Posted by Kresten Krab Thorup <kr...@trifork.com>.
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
krab@trifork.com
"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
Posted by Jacek Laskowski <jl...@apache.org>.
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
Posted by John Sisson <js...@apache.org>.
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
Posted by Lars Kühne <la...@t-online.de>.
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
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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-1111
>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>> 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
>> geirm@apache.org
>>
>>
Re: Trifork CORBA
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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-1111
>>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>>> 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
>> geirm@apache.org
>>
>>
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Trifork CORBA
Posted by Dain Sundstrom <da...@iq80.com>.
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-1111
>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>> 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
> geirm@apache.org
>
>
Re: [jira] Created: (GERONIMO-1111) Use Trifork CORBA (freeorb
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
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-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> 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
geirm@apache.org
[jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=comments#action_12355890 ]
Alan Cabrera commented on GERONIMO-1111:
----------------------------------------
This is great. Let's start fleshing out ideas in http://wiki.apache.org/geronimo/CORBA.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Kresten Krab Thorup updated GERONIMO-1111:
------------------------------------------
Attachment: freeorb-contrib.tgz
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Kresten Krab Thorup updated GERONIMO-1111:
------------------------------------------
Summary: Use Trifork CORBA (freeorb) (was: Use Trifork CORBA (freeorb)
Description:
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.
was:
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by David Jencks <da...@yahoo.com>.
On Oct 28, 2005, at 9:59 AM, Alan Cabrera (JIRA) wrote:
> [
> http://issues.apache.org/jira/browse/GERONIMO-1111?
> page=comments#action_12356222 ]
>
> Alan Cabrera commented on GERONIMO-1111:
> ----------------------------------------
>
> Maybe you could send the IDL files for us to compile. I think that we
> already have an IDL compiler from a previous donation.
hmm, I thought we were using the sun idl compiler. Anyway the IDL
should be sufficient. We should be able to add it to the corba spec
module.
> Packing up jar files from another project is not the way to go.
I definitely agree.
thanks
david jencks
>
>> Use Trifork CORBA (freeorb)
>> ---------------------------
>>
>> Key: GERONIMO-1111
>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>> Project: Geronimo
>> Type: New Feature
>> Components: CORBA
>> Versions: 1.1
>> Reporter: Kresten Krab Thorup
>> Assignee: Alan Cabrera
>> Attachments: freeorb-contrib.tgz
>>
>> 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.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
[jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=comments#action_12356222 ]
Alan Cabrera commented on GERONIMO-1111:
----------------------------------------
Maybe you could send the IDL files for us to compile. I think that we already have an IDL compiler from a previous donation. Packing up jar files from another project is not the way to go.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Alan Cabrera closed GERONIMO-1111:
----------------------------------
Resolution: Fixed
Patch applied.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: build.xml, corba-diff-krab-31oct05.diff, corbaidl.tgz, freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Alan Cabrera reassigned GERONIMO-1111:
--------------------------------------
Assign To: Alan Cabrera
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Dain Sundstrom updated GERONIMO-1111:
-------------------------------------
Geronimo Info: [Patch Available]
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: build.xml, corba-diff-krab-31oct05.diff, corbaidl.tgz, freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Kresten Krab Thorup updated GERONIMO-1111:
------------------------------------------
Attachment: corba-diff-krab-31oct05.diff
Here is a diff of today's work; this includes the IDL files needed to make it work. (so you should ignore the previous two attachments to this JIRA entry). Now we're down to one file that doesn't compile.
The patch includes diffs (including some new files) for spec/geronimo-spec-corba and sandbox/freeorb.
This also includes the geronimo-spec-corba as part of the spec top level build file.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: build.xml, corba-diff-krab-31oct05.diff, corbaidl.tgz, freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Kresten Krab Thorup (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Kresten Krab Thorup updated GERONIMO-1111:
------------------------------------------
Attachment: build.xml
corbaidl.tgz
Here's some IDL and a chunk of ANT script used to build the IDL files in our setup.
In my experience it can be a little tricky to get the IDL to compile correctly, because there are some pseudo IDL classes in there. As you can see in this script, for instance the generated ORB.java is deleted (since this one is hand-coded). Also, for most of these internal ORB interfaces, stubs and skeletons should not be generated; that is only for the "services".
Included in the tar file are also IDLs for CosNaming and CosTransactions (JTS) and CosSecurity. Those should maybe be compiled into separate modules because in principle they can evolve independently of the core ORB spec. Let me know what you think.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: build.xml, corbaidl.tgz, freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=comments#action_12356285 ]
Alan Cabrera commented on GERONIMO-1111:
----------------------------------------
FYI, Jason van Zyl is writing an IDL plugin for us.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by Kresten Krab Thorup <kr...@trifork.com>.
On Oct 28, 2005, at 3:37 AM, Alan Cabrera (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/GERONIMO-1111?
> page=comments#action_12356157 ]
>
> Alan Cabrera commented on GERONIMO-1111:
> ----------------------------------------
>
> Kresten, bits of this code doesn't compile.
> IOSemaphoreClosedException seems to be missing, as are the CSIv2/
> IIOP CORBA classes.
I wasn't sure how to package this for G project setup. What's
missing is a bunch of compiled standard IDL, like CSIv2. We need to
decide on how to organize that; as I said previously I have been
using the JacORB IDL compiler to generate these in the past.
For now, I can construct a jar file with all the generated classes in
it if you wish; but we need to choose a build strategy to have them
be generated from IDL.
Kresten Krab Thorup
krab@trifork.com
"We do not inherit the Earth from our parents, we borrow it from our
children." Saint Exupery
>
>
>> Use Trifork CORBA (freeorb)
>> ---------------------------
>>
>> Key: GERONIMO-1111
>> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
>> Project: Geronimo
>> Type: New Feature
>> Components: CORBA
>> Versions: 1.1
>> Reporter: Kresten Krab Thorup
>> Assignee: Alan Cabrera
>> Attachments: freeorb-contrib.tgz
>>
>> 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.
>>
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
>
[jira] Commented: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Alan Cabrera (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=comments#action_12356157 ]
Alan Cabrera commented on GERONIMO-1111:
----------------------------------------
Kresten, bits of this code doesn't compile. IOSemaphoreClosedException seems to be missing, as are the CSIv2/IIOP CORBA classes.
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: freeorb-contrib.tgz
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1111) Use Trifork CORBA (freeorb)
Posted by "Dain Sundstrom (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GERONIMO-1111?page=all ]
Dain Sundstrom updated GERONIMO-1111:
-------------------------------------
Geronimo Info: [Patch]
> Use Trifork CORBA (freeorb)
> ---------------------------
>
> Key: GERONIMO-1111
> URL: http://issues.apache.org/jira/browse/GERONIMO-1111
> Project: Geronimo
> Type: New Feature
> Components: CORBA
> Versions: 1.1
> Reporter: Kresten Krab Thorup
> Assignee: Alan Cabrera
> Attachments: build.xml, corba-diff-krab-31oct05.diff, corbaidl.tgz, freeorb-contrib.tgz
>
> 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.
--
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