You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Anders Hessellund Jensen <ah...@trifork.com> on 2005/11/16 11:00:26 UTC
Geronimo ORB progress
Hi all,
This is to let you all in on the progress with the Geronimo ORB
implementation.
We have been working on writing a test framework, that would allow us to
coordinate and run ORBs in separate JVMs. The test framework is not
100% polished yet, but it works, and it facilitates very easy
implementation of multiple-VM unit tests.
We expect to contribute a patch within this week, which will contain a
basic, working "Hello World" corba test.
We have had some frustrations here at Trifork. It is very difficult to
for us to work together on the code without being able to commit the
code to a source repository, especially on a rapidly changing project
like the ORB. Of course we can submit patches, but these will, in the
optimal case, take at least a few hours and perhaps several days to get
committed to the repo.
Whats worse, this situation with the code in the repo is significantly
behind, makes it virtually impossible for people other than us in
Trifork to work on the orb.
I would like to hear some community response to this. Optimally, we
would like to gain commit access to the Geronimo repo. I understand that
you will not just hand out commit access to everyone, and that this has
to be deserved. I am confident that we at Trifork will contribute enough
code to become committer on Geronimo in the future, however, we need a
solution to this problem now.
Do you have any suggestions to what we should do? Should we setup a
separate source repository for example at Sourceforge? - We could then
regularly sync this repo with the Geronimo repo, and everyone would be
able to check out the very latest version of the code.
Any other ideas?
Best regards,
Anders
Re: Geronimo ORB progress
Posted by Jacek Laskowski <jl...@apache.org>.
Anders Hessellund Jensen wrote:
> Kresten currently works full time on the ORB implementation and a lot of
> progress is being made here.
Could we somehow help in the progress? It would be very beneficial if
the progress became more visible. That's how I have read your intents,
actually - the more developers chime in early stages of development, the
better to spread how it works.
> - Anders
Jacek
Jesper Pedersen
Posted by Kresten Krab Thorup <kr...@trifork.com>.
jep@worldleaguesports.com
Kresten
Re: Geronimo ORB progress
Posted by David Blevins <da...@visi.com>.
Ok either averaging 4 hours of sleep this week is getting to me or
Alan started speaking another language deceptively like English but
where you agree with people by disagreeing with them. My wife speaks
this language fluently.
On Nov 17, 2005, at 2:18 PM, Dain Sundstrom wrote:
> +1 Using JIRA for tracking progress of the ORB would be great.
>
> We already have a CORBA component, so I suggest you create an "Add
> an ORB implementation" issue that can be the parent of all the tasks.
On Nov 17, 2005, at 3:19 PM, Lars Kühne wrote:
>
> Done, GERONIMO-1198
On Nov 17, 2005, at 5:24 PM, Alan D. Cabrera wrote:
>
> Lars,
>
> I think that we should make focused jira issues rather than a
> single umbrella issue that tracks all work on the CORBA server.
> [blah blah blah] File sub-tasks for the patches that you are
> submitting.
On Nov 17, 2005, at 10:18 PM, Lars Kühne wrote:
>
> Alan,
>
> as Dain suggested this issue is meant to serve as a parent issue
> for individual subtasks (or rather "incorporates" links?).
On Nov 18, 2005, at 12:47 AM, Alan D. Cabrera wrote:
>
> [snip] I do not believe that there is a need to capture the
> hierarchy of the architecture in Jira. A flat list of Jira issues
> with sub-tasks that track individual patches for that issue should
> be fine..
The part that really gets me rolling on the ground... hierarchies are
ok just as long as you refer to them as being "flat" lists with sub-
lists. That's like saying, "We're not so much walking as we more
sort of moving our shoes from one place to another while they happen
to be on our feet." I guess the zen is in the spaces between the words.
Considering a Jira Task Issue contains all the same data as a Jira
Issue Sub-Task, I bet you $50 they are the same thing but with a
couple GUI screens cut out and defaults filled in for convenience.
Just couldn't bite my tongue on this one ... (assuming that
expression even works for text).
OK, I definitely need sleep.
-David
On Nov 18, 2005, at 12:47 AM, Alan D. Cabrera wrote:
> Lars Kühne wrote, On 11/17/2005 10:18 PM:
>
>> Alan D. Cabrera wrote:
>>> On Nov 17, 2005, at 3:19 PM, Lars Kühne wrote:
>>>>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com
>>>>> <ma...@iq80.com>> wrote:
>>>>> We already have a CORBA component, so I suggest you create
>>>>> an "Add an
>>>>> ORB implementation" issue that can be the parent of all the
>>>>> tasks.
>>>>>
>>>>
>>>> Done, GERONIMO-1198
>>>
>>> I think that we should make focused jira issues rather than a
>>> single umbrella issue that tracks all work on the CORBA server.
>>> Ideally, people would put their stake in the ground by writing
>>> about the architectural bit that they are going to implement in
>>> the wiki. Then follow up with a a single Jira issue that
>>> basically marks the bit that you are going to implement. File
>>> sub-tasks for the patches that you are submitting.
>>>
>>> WDYT?
>>
>>
>>
>> Alan,
>>
>> as Dain suggested this issue is meant to serve as a parent issue
>> for individual subtasks (or rather "incorporates" links?). This,
>> together with using the CORBA component, is meant to serve as a
>> simple method for filtering for individual work items that are
>> open. Inidividual sub-issues would be stuff like "implement
>> ORB.resolve_initial_reference", "allow JMX monitoring of property
>> xyz", "add unit tests for ValueType mashalling" or "document
>> configuration properties".
>
> The problem is that keeping track of the patches, and they will be
> more than one for any issue, becomes a problem because they are
> tossed in one bucket of attachments. I do not believe that there
> is a need to capture the hierarchy of the architecture in Jira. A
> flat list of Jira issues with sub-tasks that track individual
> patches for that issue should be fine..
>
>> I have never used a Wiki as a collaboration tool, so maybe I don't
>> know what I'm missing. Right now I wouldn't know what to write
>> about the above sub-issues, as most of it isn't really
>> "architectural" - it's described in the CORBA spec and somebody
>> just has to do it.
>
> That's ok. There's no point in excessive bureucracy, I would just
> file a Jira issue in this case. However, the reason that I wanted
> to use the wiki was to use that as an informal organization
> mechanism. I would hate for you and others to start working on the
> same thing at the same time.
>
>> For the trickier parts of an ORB a Wiki would certainly be a good
>> idea to achieve some high level implementation idea before actual
>> coding starts. However, I typically write an implementation
>> overview (responsibility of each package and how they work
>> together) in javadoc overview and package docs.
>>
>> Do you use javadoc in geronimo land or do you write everything in
>> the Wiki? What about end user docs, would they belong in src/
>> xdocs, so they are easy to distribute with releases, or would that
>> go into the Wiki, so they are easier to edit for non-committers?
>
> We haven't discussed that at any length, iirc. I personally would
> prefer everything to go into the wiki.
>
>
> Regards,
> Alan
>
>
>
Re: Geronimo ORB progress
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Lars Kühne wrote, On 11/17/2005 10:18 PM:
> Alan D. Cabrera wrote:
>
>> Lars Kühne wrote, On 11/17/2005 3:19 PM:
>>
>>>>
>>>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com
>>>> <ma...@iq80.com>> wrote:
>>>>
>>>> +1 Using JIRA for tracking progress of the ORB would be great.
>>>>
>>>> [...] I suggest you create an "Add an
>>>> ORB implementation" issue that can be the parent of all the tasks.
>>>>
>>>
>>> Done, GERONIMO-1198
>>
>>
>>
>> I think that we should make focused jira issues rather than a single
>> umbrella issue that tracks all work on the CORBA server. Ideally,
>> people would put their stake in the ground by writing about the
>> architectural bit that they are going to implement in the wiki. Then
>> follow up with a a single Jira issue that basically marks the bit
>> that you are going to implement. File sub-tasks for the patches
>> that you are submitting.
>>
>> WDYT?
>
>
>
> Alan,
>
> as Dain suggested this issue is meant to serve as a parent issue for
> individual subtasks (or rather "incorporates" links?). This, together
> with using the CORBA component, is meant to serve as a simple method
> for filtering for individual work items that are open. Inidividual
> sub-issues would be stuff like "implement
> ORB.resolve_initial_reference", "allow JMX monitoring of property
> xyz", "add unit tests for ValueType mashalling" or "document
> configuration properties".
The problem is that keeping track of the patches, and they will be more
than one for any issue, becomes a problem because they are tossed in one
bucket of attachments. I do not believe that there is a need to capture
the hierarchy of the architecture in Jira. A flat list of Jira issues
with sub-tasks that track individual patches for that issue should be fine..
> I have never used a Wiki as a collaboration tool, so maybe I don't
> know what I'm missing. Right now I wouldn't know what to write about
> the above sub-issues, as most of it isn't really "architectural" -
> it's described in the CORBA spec and somebody just has to do it.
That's ok. There's no point in excessive bureucracy, I would just file
a Jira issue in this case. However, the reason that I wanted to use the
wiki was to use that as an informal organization mechanism. I would
hate for you and others to start working on the same thing at the same time.
> For the trickier parts of an ORB a Wiki would certainly be a good idea
> to achieve some high level implementation idea before actual coding
> starts. However, I typically write an implementation overview
> (responsibility of each package and how they work together) in javadoc
> overview and package docs.
>
> Do you use javadoc in geronimo land or do you write everything in the
> Wiki? What about end user docs, would they belong in src/xdocs, so
> they are easy to distribute with releases, or would that go into the
> Wiki, so they are easier to edit for non-committers?
We haven't discussed that at any length, iirc. I personally would
prefer everything to go into the wiki.
Regards,
Alan
Re: Geronimo ORB progress
Posted by Lars Kühne <la...@t-online.de>.
Alan D. Cabrera wrote:
> Lars Kühne wrote, On 11/17/2005 3:19 PM:
>
>>>
>>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com <ma...@iq80.com>>
>>> wrote:
>>>
>>> +1 Using JIRA for tracking progress of the ORB would be great.
>>>
>>> [...] I suggest you create an "Add an
>>> ORB implementation" issue that can be the parent of all the tasks.
>>>
>>
>> Done, GERONIMO-1198
>
>
> I think that we should make focused jira issues rather than a single
> umbrella issue that tracks all work on the CORBA server. Ideally,
> people would put their stake in the ground by writing about the
> architectural bit that they are going to implement in the wiki. Then
> follow up with a a single Jira issue that basically marks the bit that
> you are going to implement. File sub-tasks for the patches that you
> are submitting.
>
> WDYT?
Alan,
as Dain suggested this issue is meant to serve as a parent issue for
individual subtasks (or rather "incorporates" links?). This, together
with using the CORBA component, is meant to serve as a simple method for
filtering for individual work items that are open. Inidividual
sub-issues would be stuff like "implement
ORB.resolve_initial_reference", "allow JMX monitoring of property xyz",
"add unit tests for ValueType mashalling" or "document configuration
properties".
I have never used a Wiki as a collaboration tool, so maybe I don't know
what I'm missing. Right now I wouldn't know what to write about the
above sub-issues, as most of it isn't really "architectural" - it's
described in the CORBA spec and somebody just has to do it.
For the trickier parts of an ORB a Wiki would certainly be a good idea
to achieve some high level implementation idea before actual coding
starts. However, I typically write an implementation overview
(responsibility of each package and how they work together) in javadoc
overview and package docs.
Do you use javadoc in geronimo land or do you write everything in the
Wiki? What about end user docs, would they belong in src/xdocs, so they
are easy to distribute with releases, or would that go into the Wiki, so
they are easier to edit for non-committers?
Regards,
Lars
Re: Geronimo ORB progress
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Lars Kühne wrote, On 11/17/2005 3:19 PM:
> Kevan Miller wrote:
>
>>
>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com <ma...@iq80.com>>
>> wrote:
>>
>> +1 Using JIRA for tracking progress of the ORB would be great.
>>
>> We already have a CORBA component, so I suggest you create an
>> "Add an
>> ORB implementation" issue that can be the parent of all the tasks.
>>
>
> Done, GERONIMO-1198
Lars,
I think that we should make focused jira issues rather than a single
umbrella issue that tracks all work on the CORBA server. Ideally,
people would put their stake in the ground by writing about the
architectural bit that they are going to implement in the wiki. Then
follow up with a a single Jira issue that basically marks the bit that
you are going to implement. File sub-tasks for the patches that you
are submitting.
WDYT?
Regards,
Alan
Re: Geronimo ORB progress
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 17, 2005, at 3:19 PM, Lars Kühne wrote:
> Kevan Miller wrote:
>
>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com
>> <ma...@iq80.com>> wrote:
>> Lars if you give me you jira id,
>
> lkuehne
>
>> I can add you as a geronimo
>> committer, so you can assign issues to yourself.
>>
>> Umm, that would be "contributor"? ;-)
>>
>
>
> I think Dain meant what he said ;-)
:)
I gave you geronimo-contributor rights.
-dain
Re: Geronimo ORB progress
Posted by Lars Kühne <la...@t-online.de>.
Kevan Miller wrote:
>
> On 11/17/05, *Dain Sundstrom* <dain@iq80.com <ma...@iq80.com>>
> wrote:
>
> +1 Using JIRA for tracking progress of the ORB would be great.
>
> We already have a CORBA component, so I suggest you create an "Add an
> ORB implementation" issue that can be the parent of all the tasks.
>
Done, GERONIMO-1198
> Also make sure that you assign it to at least version 1.1 (assuming
> the plan is to have the orb finished for 1.1).
>
I don't have the karma to set the Fix Version.
> Lars if you give me you jira id,
>
lkuehne
> I can add you as a geronimo
> committer, so you can assign issues to yourself.
>
>
> Umm, that would be "contributor"? ;-)
>
I think Dain meant what he said ;-)
Cheers,
Lars
Re: Geronimo ORB progress
Posted by Kevan Miller <ke...@gmail.com>.
On 11/17/05, Dain Sundstrom <da...@iq80.com> wrote:
>
> +1 Using JIRA for tracking progress of the ORB would be great.
>
> We already have a CORBA component, so I suggest you create an "Add an
> ORB implementation" issue that can be the parent of all the tasks.
> Also make sure that you assign it to at least version 1.1 (assuming
> the plan is to have the orb finished for 1.1).
>
> Lars if you give me you jira id, I can add you as a geronimo
> committer, so you can assign issues to yourself.
Umm, that would be "contributor"? ;-)
--kevan
-dain
>
> On Nov 17, 2005, at 2:06 PM, Lars Kühne wrote:
>
> > Anders Hessellund Jensen wrote:
> >
> >>> Just to give you some direct guidance, you probably should have
> >>> shot an email out to the group saying "what do you guys do for
> >>> testing when more than one VM is involved" or "we have this idea
> >>> for testing in more than one VM, what do you think?"
> >>
> >>
> >> You are right, and I apologise. Open source development is new to
> >> us, and we need to get used to communicating more verbosely by
> >> email so we don't reinvent the wheel, or work in different
> >> directions, and generally keeps everyone informed on the progress
> >> of the project.
> >>
> >> I will be busy elsewhere for the rest of the week, but I will have
> >> a close look at the itest plugin when I get back.
> >>
> >> Kresten currently works full time on the ORB implementation and a
> >> lot of progress is being made here.
> >
> >
> > Kresten, what exactly are you working on? I have some code locally
> > that implements simple things like ORB.list_initial_services,
> > string_to_object, etc. I plan to finish this up this weekend and
> > send a patch.
> >
> > Writing an ORB is not my day job, so I only have a few hours per
> > week and I'd like to avoid duplicate work. If you Trifork guys
> > could send short announcements like "we'll start working on xyz
> > now" that would be cool. Maybe this could also be done via JIRA,
> > create issues and assign them to yourself when you start working on
> > them - this will give external contributors like myself a better
> > view what's planned and where help is most useful.
> >
> > Lars
>
>
Re: Geronimo ORB progress
Posted by Dain Sundstrom <da...@iq80.com>.
+1 Using JIRA for tracking progress of the ORB would be great.
We already have a CORBA component, so I suggest you create an "Add an
ORB implementation" issue that can be the parent of all the tasks.
Also make sure that you assign it to at least version 1.1 (assuming
the plan is to have the orb finished for 1.1).
Lars if you give me you jira id, I can add you as a geronimo
committer, so you can assign issues to yourself.
-dain
On Nov 17, 2005, at 2:06 PM, Lars Kühne wrote:
> Anders Hessellund Jensen wrote:
>
>>> Just to give you some direct guidance, you probably should have
>>> shot an email out to the group saying "what do you guys do for
>>> testing when more than one VM is involved" or "we have this idea
>>> for testing in more than one VM, what do you think?"
>>
>>
>> You are right, and I apologise. Open source development is new to
>> us, and we need to get used to communicating more verbosely by
>> email so we don't reinvent the wheel, or work in different
>> directions, and generally keeps everyone informed on the progress
>> of the project.
>>
>> I will be busy elsewhere for the rest of the week, but I will have
>> a close look at the itest plugin when I get back.
>>
>> Kresten currently works full time on the ORB implementation and a
>> lot of progress is being made here.
>
>
> Kresten, what exactly are you working on? I have some code locally
> that implements simple things like ORB.list_initial_services,
> string_to_object, etc. I plan to finish this up this weekend and
> send a patch.
>
> Writing an ORB is not my day job, so I only have a few hours per
> week and I'd like to avoid duplicate work. If you Trifork guys
> could send short announcements like "we'll start working on xyz
> now" that would be cool. Maybe this could also be done via JIRA,
> create issues and assign them to yourself when you start working on
> them - this will give external contributors like myself a better
> view what's planned and where help is most useful.
>
> Lars
Re: Geronimo ORB progress
Posted by Kresten Krab Thorup <kr...@trifork.com>.
>
> Kresten, what exactly are you working on? I have some code locally
> that implements simple things like ORB.list_initial_services,
> string_to_object, etc. I plan to finish this up this weekend and
> send a patch.
>
I'm working on getting infrastructure in place that I can run the
client side of a hello world test. This involves object_to_string,
string_to_object, an implementation of the portable client Delegate.
So initial services management would be an excellent thing to work on.
Kresten
Re: Geronimo ORB progress
Posted by Lars Kühne <la...@t-online.de>.
Anders Hessellund Jensen wrote:
>> Just to give you some direct guidance, you probably should have shot
>> an email out to the group saying "what do you guys do for testing
>> when more than one VM is involved" or "we have this idea for testing
>> in more than one VM, what do you think?"
>
>
> You are right, and I apologise. Open source development is new to us,
> and we need to get used to communicating more verbosely by email so we
> don't reinvent the wheel, or work in different directions, and
> generally keeps everyone informed on the progress of the project.
>
> I will be busy elsewhere for the rest of the week, but I will have a
> close look at the itest plugin when I get back.
>
> Kresten currently works full time on the ORB implementation and a lot
> of progress is being made here.
Kresten, what exactly are you working on? I have some code locally that
implements simple things like ORB.list_initial_services,
string_to_object, etc. I plan to finish this up this weekend and send a
patch.
Writing an ORB is not my day job, so I only have a few hours per week
and I'd like to avoid duplicate work. If you Trifork guys could send
short announcements like "we'll start working on xyz now" that would be
cool. Maybe this could also be done via JIRA, create issues and assign
them to yourself when you start working on them - this will give
external contributors like myself a better view what's planned and where
help is most useful.
Lars
Re: Geronimo ORB progress
Posted by Anders Hessellund Jensen <ah...@trifork.com>.
> Just to give you some direct guidance, you probably should have shot an
> email out to the group saying "what do you guys do for testing when
> more than one VM is involved" or "we have this idea for testing in more
> than one VM, what do you think?"
You are right, and I apologise. Open source development is new to us,
and we need to get used to communicating more verbosely by email so we
don't reinvent the wheel, or work in different directions, and generally
keeps everyone informed on the progress of the project.
I will be busy elsewhere for the rest of the week, but I will have a
close look at the itest plugin when I get back.
Kresten currently works full time on the ORB implementation and a lot of
progress is being made here.
- Anders
Re: Geronimo ORB progress
Posted by David Blevins <da...@visi.com>.
Sounds cool.
Just to give you some direct guidance, you probably should have shot
an email out to the group saying "what do you guys do for testing
when more than one VM is involved" or "we have this idea for testing
in more than one VM, what do you think?" Not a big deal, you're
here, you want to do good work, we can work with that.
Here is the reply I would have given to the above questions. I've
Cc'ed James and Vincent as I know they are working on or have
slightly similar things.
Sounds like a neat idea. We have the itests plugin and the a bunch
of tests that use the itest plugin. We definitely want more.
Ideally we'd have them for all the major compoments aside from just
ejb, persistence, and rmi stuff.
The basic idea behind itests that makes them slightly different than
plain junit tests ran by maven is that it's assumed that there are
other systems (servers, databases, brokers, etc) that need to be
started or connected to before the tests can run. The tests
themselves don't setup the other systems themselves so that the tests
don't become coupled with them and you can actually swap out various
aspects of those systems behind the back of the tests; server
version, protocol implementation, java version, VM implementation,
database provider, operating systems, even using embedded servers and
embedded databases.
The idea actually evolved from the tests in OpenEJB that do this. It
took a lot of work to get them to run as part of the build and the
itest plugin was the result. So now we can easily boot up geronimo,
derby, axion, activemq or whatever in whatever vm and on whatever OS
and run the exact same tests to see how things are.
Definitely give those a look at: http://cvs.openejb.org/viewrep/
openejb/openejb/modules/itests/src/java/org/openejb/test
Those particular tests allow you to plug in facades for the server
and the database so the client (the tests) can say "give me an
initial context" or "create these tables i need" in a generic way.
It's assumed that those systems were setup and guaranteed in working
state in the itest setup phase. It's also guaranteed that the server
and database facades know how to contact the server or database to
carry out the "give me an initial context" and "create these tables"
calls.
Here are some implementations of the database provider for reference:
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/AxionTestDatabase.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/DerbyTestDatabase.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/InstantDbTestDatabase.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/PostgreSqlTestDatabase.java
Here are some implementations for the server facades:
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/CorbaTestServer.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/RemoteTestServer.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/IvmTestServer.java
http://cvs.openejb.org/viewrep/openejb/openejb/modules/itests/src/
itest/org/openejb/test/RiTestServer.java
Using the itest concept you could setup any system you need before
hand, then just provide an abstraction of that system to the actual
tests. So it's not limited to just a server or a database. You
could do queue, topic, clustering heartbeat agent, directory server,
etc.
Even with just what we have we can get quite far. In a perfect
world, we would actually test against the full matrix:
Server: Local, Database: Axion
Server: Local, Database: Derby
Server: Local, Database: PostgreSQL
Server: Remote, Database: Axion
Server: Remote, Database: Derby
Server: Remote, Database: PostgreSQL
Server: Corba, Database: Axion
Server: Corba, Database: Derby
Server: Corba, Database: PostgreSQL
I had that going for a short while years ago but it was just too much
infrastructure for me to keep running. It would be nice to get
Oracle and MySQL in that list as well.
In an even more perfect world we'd test against not just different
Server and Database combinations, but JVM versions as well.
Server: Local, Database: Axion, JVM: 1.3
Server: Local, Database: Axion, JVM: 1.4
Server: Local, Database: Axion, JVM: 1.5
Server: Local, Database: Derby, JVM: 1.3
Server: Local, Database: Derby, JVM: 1.4
Server: Local, Database: Derby, JVM: 1.5
Server: Local, Database: PostgreSQL, JVM: 1.3
Server: Local, Database: PostgreSQL, JVM: 1.4
Server: Local, Database: PostgreSQL, JVM: 1.5
Server: Remote, Database: Axion, JVM: 1.3
Server: Remote, Database: Axion, JVM: 1.4
Server: Remote, Database: Axion, JVM: 1.5
Server: Remote, Database: Derby, JVM: 1.3
Server: Remote, Database: Derby, JVM: 1.4
Server: Remote, Database: Derby, JVM: 1.5
Server: Remote, Database: PostgreSQL, JVM: 1.3
Server: Remote, Database: PostgreSQL, JVM: 1.4
Server: Remote, Database: PostgreSQL, JVM: 1.5
Server: Corba, Database: Axion, JVM: 1.3
Server: Corba, Database: Axion, JVM: 1.4
Server: Corba, Database: Axion, JVM: 1.5
Server: Corba, Database: Derby, JVM: 1.3
Server: Corba, Database: Derby, JVM: 1.4
Server: Corba, Database: Derby, JVM: 1.5
Server: Corba, Database: PostgreSQL, JVM: 1.3
Server: Corba, Database: PostgreSQL, JVM: 1.4
Server: Corba, Database: PostgreSQL, JVM: 1.5
If you add JVM vendors (Sun, IBM, Apple, BEA) to the list, the
combinations goes up to like 109. Throw on OS implementations and
you get an insane number of test runs to complete.
Anyway, some of the this we still need:
1) some nice way of specifying the items from the matrix to use
(which vms, which databases, etc.)
2) Some way to automate running through the matrix.
3) Hardware (never can have too much)
4) Licenses for the OSs and Databases
Hope that gives some insight to the lay of the land as it is now.
Nothing is perfect or set in stone, so improvement is always welcome.
That said, the last part (the matrix) sounds very much like Cargo.
Maybe Vincent can comment on that.
I also know James has also been trying to solve the matrix issue.
Don't know what he's got going on.
-David
On Nov 16, 2005, at 6:15 AM, Anders Hessellund Jensen wrote:
> David Blevins wrote:
>> So what kind of testing framework is this? Is it junit-based?
>
> Yes, it is junit-based. Essentially, we have created a test
> superclass, which inherits from junit.framework.Test.
>
> So, assume we would like a Multi-JVM test with a single test case
> named "Simple". We have two JVM's, a client and a server. The
> client and server each needs to do some initialization, then the
> client initiates a test, and finally the server needs to do some
> checks after the test.
>
> A multi-JVM junit test would look something like this:
>
> class MultiJvmTest extends RemoteTest {
> public void setUp() {
> // Starts a JVM named "server"
> startTestAgent("server");
> // Starts a JVM named "client"
> startTestAgent("client");
> }
>
> public void serverBeforeSimple() {
> // Setup the server for test case "Simple"
> // This method will be invoked in the "server" JVM.
> }
> public void clientBeforeSimple() {
> // Setup the client for test case "Simple".
> // This method will be invoked in the "client" JVM.
> }
>
> public void clientTestSimple() {
> // Run the test
> }
>
> public void serverAfterSimple() {
> // Check server state after test.
> }
> }
>
> When running this test, the framework would do the following:
>
> - run setUp(). This starts the two JVM's identified by the strings
> "server" and "client". Thus, there is three JVM's running in total,
> a master JVM, and two slave JVMs.
> - invoke the serverBeforeSimple() in the "server" JVM.
> - invoke the clientBeforeSimple() in the "client" JVM.
> - invoke the clientTestSimple() in the "client" JVM.
> - invoke the serverAfterSimple() in the "server" JVM.
>
> The whole thing integrates pretty well with junit. If an exception
> is thrown in a slave JVM, it will be rethrown in the master JVM,
> resulting in a correct stack trace identifying where the test
> failed. Furthermore, it is possible to start an agent within the
> master JVM, so single-step debugging is possible as well.
>
> Communication between the JVM's takes place using plain RMI.
>
> An agent can be given a Properties as argument. There is also a
> global set of properties shared by all JVMs.
>
> The framework uses reflection to collect the methods that is called
> when the test is run. The methods must be named:
>
> <agentName>Before<testName>
> <agentName>Test<testName>
> <agentName>After<testName>
>
>> How does it related to our existing itests? Those are server
>> (and database) agnostic and can be ran across several vms and
>> orbs. Don't know if there is any overlap.
>
> I don't know how the existing itests work. There may be some overlap.
>
>> Would these test be run as part of a normal build or would we set
>> them up to run periodically in continuum or something?
>
> These tests are intended to be run as "normal" junit tests. Thus
> they should be part of the normal build.
>
>> Are the tests focused on verifying corba compliance or is this
>> somehow more generic and applicable to testing in general?
>
> The framework is quite general, but of course tailored with the
> features we needed. There is nothing CORBA-specific in it.
>
> I would be happy to know if there is code out there that does
> something similar to this framework. We have looked around, but
> haven't really found anything that seemed quite right to our purpose.
>
> Anders
>
Re: Geronimo ORB progress
Posted by Anders Hessellund Jensen <ah...@trifork.com>.
David Blevins wrote:
> So what kind of testing framework is this? Is it junit-based?
Yes, it is junit-based. Essentially, we have created a test superclass,
which inherits from junit.framework.Test.
So, assume we would like a Multi-JVM test with a single test case named
"Simple". We have two JVM's, a client and a server. The client and
server each needs to do some initialization, then the client initiates a
test, and finally the server needs to do some checks after the test.
A multi-JVM junit test would look something like this:
class MultiJvmTest extends RemoteTest {
public void setUp() {
// Starts a JVM named "server"
startTestAgent("server");
// Starts a JVM named "client"
startTestAgent("client");
}
public void serverBeforeSimple() {
// Setup the server for test case "Simple"
// This method will be invoked in the "server" JVM.
}
public void clientBeforeSimple() {
// Setup the client for test case "Simple".
// This method will be invoked in the "client" JVM.
}
public void clientTestSimple() {
// Run the test
}
public void serverAfterSimple() {
// Check server state after test.
}
}
When running this test, the framework would do the following:
- run setUp(). This starts the two JVM's identified by the strings
"server" and "client". Thus, there is three JVM's running in total, a
master JVM, and two slave JVMs.
- invoke the serverBeforeSimple() in the "server" JVM.
- invoke the clientBeforeSimple() in the "client" JVM.
- invoke the clientTestSimple() in the "client" JVM.
- invoke the serverAfterSimple() in the "server" JVM.
The whole thing integrates pretty well with junit. If an exception is
thrown in a slave JVM, it will be rethrown in the master JVM, resulting
in a correct stack trace identifying where the test failed. Furthermore,
it is possible to start an agent within the master JVM, so single-step
debugging is possible as well.
Communication between the JVM's takes place using plain RMI.
An agent can be given a Properties as argument. There is also a global
set of properties shared by all JVMs.
The framework uses reflection to collect the methods that is called when
the test is run. The methods must be named:
<agentName>Before<testName>
<agentName>Test<testName>
<agentName>After<testName>
> How does it related to our existing itests? Those are server (and
> database) agnostic and can be ran across several vms and orbs. Don't
> know if there is any overlap.
I don't know how the existing itests work. There may be some overlap.
> Would these test be run as part of a normal build or would we set them
> up to run periodically in continuum or something?
These tests are intended to be run as "normal" junit tests. Thus they
should be part of the normal build.
> Are the tests focused on verifying corba compliance or is this somehow
> more generic and applicable to testing in general?
The framework is quite general, but of course tailored with the features
we needed. There is nothing CORBA-specific in it.
I would be happy to know if there is code out there that does something
similar to this framework. We have looked around, but haven't really
found anything that seemed quite right to our purpose.
Anders
Re: Geronimo ORB progress
Posted by David Blevins <da...@visi.com>.
Just throwing out some questions in hopes to spur a conversation.
Feel free combine questions or throw in details as you see fit.
So what kind of testing framework is this? Is it junit-based?
How does it related to our existing itests? Those are server (and
database) agnostic and can be ran across several vms and orbs. Don't
know if there is any overlap.
Or is this somehow daytrader-like which is performance focused but
also makes a great way to system test.
Would these test be run as part of a normal build or would we set
them up to run periodically in continuum or something?
Are the tests focused on verifying corba compliance or is this
somehow more generic and applicable to testing in general?
Thanks,
David
On Nov 16, 2005, at 2:00 AM, Anders Hessellund Jensen wrote:
> Hi all,
>
> This is to let you all in on the progress with the Geronimo ORB
> implementation.
>
> We have been working on writing a test framework, that would allow
> us to coordinate and run ORBs in separate JVMs. The test framework
> is not 100% polished yet, but it works, and it facilitates very
> easy implementation of multiple-VM unit tests.
>
> We expect to contribute a patch within this week, which will
> contain a basic, working "Hello World" corba test.
>
> We have had some frustrations here at Trifork. It is very difficult
> to for us to work together on the code without being able to commit
> the code to a source repository, especially on a rapidly changing
> project like the ORB. Of course we can submit patches, but these
> will, in the optimal case, take at least a few hours and perhaps
> several days to get committed to the repo.
>
> Whats worse, this situation with the code in the repo is
> significantly behind, makes it virtually impossible for people
> other than us in Trifork to work on the orb.
>
> I would like to hear some community response to this. Optimally, we
> would like to gain commit access to the Geronimo repo. I understand
> that you will not just hand out commit access to everyone, and that
> this has to be deserved. I am confident that we at Trifork will
> contribute enough code to become committer on Geronimo in the
> future, however, we need a solution to this problem now.
>
> Do you have any suggestions to what we should do? Should we setup a
> separate source repository for example at Sourceforge? - We could
> then regularly sync this repo with the Geronimo repo, and everyone
> would be able to check out the very latest version of the code.
>
> Any other ideas?
>
> Best regards,
> Anders
>
Re: Geronimo ORB progress
Posted by Jacek Laskowski <jl...@apache.org>.
Anders Hessellund Jensen wrote:
Hi Anders,
> This is to let you all in on the progress with the Geronimo ORB
> implementation.
>
> We have been working on writing a test framework, that would allow us to
> coordinate and run ORBs in separate JVMs. The test framework is not
> 100% polished yet, but it works, and it facilitates very easy
> implementation of multiple-VM unit tests.
...and I must admit it's the first time I could read about it. It might
be because I had some troubles with my mail account, but it might also
be that there was no discussion about it at all in this mailing list.
Which one explains it better I'll leave to the next paragraph.
> We expect to contribute a patch within this week, which will contain a
> basic, working "Hello World" corba test.
Excellent!
> We have had some frustrations here at Trifork. It is very difficult to
> for us to work together on the code without being able to commit the
> code to a source repository, especially on a rapidly changing project
> like the ORB. Of course we can submit patches, but these will, in the
> optimal case, take at least a few hours and perhaps several days to get
> committed to the repo.
>
> Whats worse, this situation with the code in the repo is significantly
> behind, makes it virtually impossible for people other than us in
> Trifork to work on the orb.
>
> I would like to hear some community response to this. Optimally, we
> would like to gain commit access to the Geronimo repo. I understand that
> you will not just hand out commit access to everyone, and that this has
> to be deserved. I am confident that we at Trifork will contribute enough
> code to become committer on Geronimo in the future, however, we need a
> solution to this problem now.
>
> Do you have any suggestions to what we should do? Should we setup a
> separate source repository for example at Sourceforge? - We could then
> regularly sync this repo with the Geronimo repo, and everyone would be
> able to check out the very latest version of the code.
I haven't yet seen a response to it and since I see it as an important
issue, I'd like to spur a discussion about it and have it finally sorted
out, especially for the current CORBA development being conducted in
private.
The only solution I can see now is to follow the usual and proven
solution, which is to open JIRA items with patches applied. The more we
could see earlier and the less complicated the changes will be, the
better. To me it's an excellent approach to learn things and seems to be
the best way to invite others to contribute. There was already a
non-committer who showed interest in trying it out, actually. So, I'm
very reluctant to gain commit access only on the promise to contribute
more soon, which would be a bad sign to others who spend longer time
with us, but haven't yet been given it.
Would you then open new JIRA items whenever a new change is introduced.
I'm sure someone will pick it up and commit to the repo. You can always
send a note to the forum and ask to boost the process if its speed
becomes uncomfortable.
> Anders
Jacek