Architecture proposals for face-to-face

[Russell Butek <bu...@us.ibm.com>]

Folks, here's a document that we (IBM) were planning to present at the
face-to-face next week.  Since we're not going to make it, I'll present it
here.  The intent of this thing is to get us all on the same page with
respect to how we proceed with AXIS development.  It is intended to be a
living document that everyone can add to and debate (with this in mind, I
suggest we store it in CVS).  As items on this document are resolved, we
can implement them and describe them in the architecture guide.

(See attached file: architecture-direction.html)

Russell Butek
butek@us.ibm.com

Re: Architecture proposals for face-to-face

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: "Russell Butek" <bu...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Wednesday, May 15, 2002 7:54 AM
Subject: Architecture proposals for face-to-face


> Folks, here's a document that we (IBM) were planning to present at the
> face-to-face next week.  Since we're not going to make it, I'll present it
> here.  The intent of this thing is to get us all on the same page with
> respect to how we proceed with AXIS development.  It is intended to be a
> living document that everyone can add to and debate (with this in mind, I
> suggest we store it in CVS).  As items on this document are resolved, we
> can implement them and describe them in the architecture guide.
>


Proposal 10: Re-write Test Harness
Status: Proposed
Proposed By: Rich Scheuerle and others
Description
Here are some objectives:
  a.. Ability to run a single test.
  b.. Ability to run a bucket of tests
  c.. Ability to run all the tests
  d.. Ability to run the tests that do not rely on remote resources.
  e.. Ability to run tests if connection problems occur with remote
resources (with warnings).
  f.. Simpler installation of tests.  Best would be auto installation
without changes to the build.xml files.  Give non-committers the ability to
quickly give us a test that we can drop in; thus giving the group a good set
of user provided tests.
  g.. Fully documented process.
Justification
The current test harness is becoming too complicated.

------------

+1

The current approach isnt scaling; and if one fails then everything breaks.
And it takes a long time to run, hence the timeouts.

Possible solutions

1. refactor the build files to all load shared property, taskdef, classpath
declarations through XML entities (easy; can be done on a case-by-case
basis; works w/ all versions of ant)

2. Write a new ant task that does bulk <ant> on files in subdirs; has a
failonerror property to keep going if there are failures. This is the fabled
<anton> task that has historically been rejected on ant-dev because " a
master build should know about its child builds". With one test per
(refactored) build file, drop in execution would be nice

3. extend Junit, write a test case descendent that generates tests against
build files. The intent would be to get a nice junit formatted http status
report

4. something fancy with XSLT
 -take one or more test descriptor files
 -generate ant build files dynamically from these
 -run 'em
 -have the output coalesced  into a fancy junit http status report

5. Run some tests in parallel. Each test should be independent, so we can
run them side by side and get through the test suite faster, especially on a
multi-cpu box. This may throw up concurrency bugs, which is a good thing.


I think the combinaiton of options (1, 4, and 5), with some hosting
mechanism (like 2 or 3) would work








There is a lot that could be done to clean up

Re: Architecture proposals for face-to-face

[Melissa Turner <mj...@apple.com>]

On Wednesday, May 15, 2002, at 07:54 , Russell Butek wrote:

> Folks, here's a document that we (IBM) were planning to present at the
> face-to-face next week.  Since we're not going to make it, I'll present 
> it
> here.  The intent of this thing is to get us all on the same page with
> respect to how we proceed with AXIS development.  It is intended to be a
> living document that everyone can add to and debate (with this in 
> mind, I
> suggest we store it in CVS).  As items on this document are resolved, we
> can implement them and describe them in the architecture guide.
>
> (See attached file: architecture-direction.html)
>
> Russell Butek
> butek@us.ibm.com
>

A TypeMapping can currently be registered on a service or globally.  
There are several problems with this two tiered system.  Do you have to 
end all of the services to install a new global TypeMapping ?  If a 
(javaType, xmlType) is not registered in the services TM or default TM 
should the global TM be consulted ?  So I propose only supporting 
TypeMapping deployment on services.

-----------------

-1

Please don't. I'd end up re-registering serializers so many times it's 
not funny (I have n services, each using the same m serializers, where 
both n and m are non-trivial). The current system is bad (the JSR's 
fault, not Axis'), but removing global mappings would make it a 
nightmare.

Proposed answers to questions: I forget exact details of the 
architecture, but I'd lean towards no, that services should not need to 
be ended to install new global TypeMappings. And yes; if you can't find 
a (java, xml) mapping in the services TM or the default TM, check the 
global one.

+Melissa