[aperi-dev] V0.3 Status on various issues

[Dave Wolfe <dwolfe@xxxxxxxxxx>]

DB2 testing and defects 184535 and 184536:
I fixed both 184535 and 184536 and checked
them in.  I marked 184535 fixed since I was able to repro w/Derby
and verify my fix. For 184536 I need to test with DB2 using the new build.
Rodica tried the new build this (Saturday)
morning, but had problems with the JDBC drivers. I didn't get the exact
details. I will try the build myself.

XML Validation from behind a firewall:
        Yeah,
validation by DTD or Schema seems to be required. 
        As
near as I can tell -Dorg.mortbay.xml.XmlParser.NotValidating=true doesn't
stop the server from trying to access the DTD or Schema URL.
        The
aperi-reports deployment descriptor is 2.4 compliant, but the birt-viewer
is 2.3 compliant.
        I
converted aperi-reports deployment descriptor to 2.3 compliant to match
the birt-viewer deployment descriptor then modified the XML DOCTYPE declaration
in both to look like this:
     
  <!DOCTYPE
web-app
     
              PUBLIC
"-//Sun Microsystems,
Inc.//DTD Web Application 2.3//EN"
     
              "file:///C:/Aperi-Dev/Code/AperiDebug/reporting/web-app_2_3.dtd">
        and
downloaded the DTD to the given location. 
        This
works even when my test system is completely disconnected from the network
(wire pulled).
        So,
pending a review from Rodica on some changes to the authentication declaration,
I'll check in the 2.3 compliant web.xml for aperi-reports and we can write
some instructions on how to tweak the web.xml files for behind-the-firewall
operation.

Linux Client and SWT Browser Widget:
        I
have been actively working this since Wednesday. 
        I
got a fresh RedHat Enterprise Linux 3 AS installed and was able to exactly
reproduce the failure using Rodica's build of the GUI. I am now trying
a build from the IDE with some experimental code to debug with on the platform.
I haven't gotten that to work yet.
        I
also have been in contact with a SWT platform developer familiar with these
issues (the guy who fixed bugzilla 184536). 
        He
was very helpful and attempted to reproduce the problem with a few combinations
of Mozilla (including SeaMonkey 1.0.8 the version on RHEL 3 AS), but was
unable to reproduce it with the examples he had available.  
        This
means the issue is probably unique to our configuration.
        There
are essentially four variables here: 
         
              1) The
version of Mozilla and the GUI framework it is built for (GTK versus Motif),
and how it was linked (ok, that was three variables in one).
         
              2) The
version of the SWT platform libraries we are using (Eclipse 3.2.1 versus
say 3.3M6, apparently there have been a lot of changes in the SWT Browser
Widget since 3.2).
         
              3) The
_javascript_, CSS, and HTML which is our unique application.
         
              4) The
application server and its authentication mode (we use BASIC, we cold use
FORM which Rodica has tested with and shown to work without crashes)
        The
most likely root cause is that something about our particular configuration
conspires to cause a bad parameter to be passed to a native library that
causes a fault that makes the JVM dump core.
        As
I see it we have three ways to continue pursuit of this issue:
         
      1) Try different combinations of Mozilla/SWT/JRE
to see if we can find a combo that works
         
              Pros)
Relatively low tech, no special tools or knowledge required
         
              Cons)
Time intensive with no promises of a better result, and we end up with
a more complicated recipe
         
      2)  Debug the problem to its root cause
with configuration we have then see if we can get it fixed or work around
it
         
              Pros)
Actually adds value, and we can take definitive action since we know the
root cause
         
              Cons)
Time intensive and a potential learning curve (none of us have debugged
GUI stuff on Linux), and once we knew the root cause it could be in any
of several packages from multiple sources or an interaction between packages
that we would have to ask someone else to fix  (or incorporate our
fix) and it wouldn't necessarily show up in any release generally available
anytime soon, so we'd probably have to patch it.
         
      3) Convert the application to use FORM instead
of BASIC authentication
         
              Pros)
Relatively easy to do 
         
              Cons)
Requires we write more HTML and restructure the way the UI initially presents
itself, may still be other issues we haven't discovered yet...

Dave Wolfe/Portland/IBM
(dwolfe@xxxxxxxxxx)
TL: 775-3376 Office: 503-578-3376 Personal: 503-329-3960

UI Technical Lead, Aperi Open Source Storage Management http://www.eclipse.org/aperi

"A good composer does not imitate; he steals." - Igor Stravinsky

 

Craig Laverone/San Jose/IBM@IBMUS
Sent by: aperi-dev-bounces@xxxxxxxxxxx

04/27/2007 04:35 PM

Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx>

To	aperi-dev@xxxxxxxxxxx
cc
Subject	[aperi-dev] Aperi 0.3 Unit Testing: DB2 on W2K

Aperi 0.3 Unit Testing: DB2 on Windows 2000

Findings:

1. I was unable to run the report server on the lab machines because Jetty
is attempting to connect to the internet to validate the schema. I tried
setting the command line option "-Dorg.mortbay.xml.XmlParser.NotValidating=true"
but this didn't fix the problem. I need to investigate this further.

2. Reproduced bug 172223 

3. Opened bugs 184496 (Fixed), 184536, 184536.

-- Craig
_________________________________________________________________________________________
Craig Laverone | 408-284-4897 | laverone@xxxxxxxxxx | Aperi Development
| http://www.eclipse.org/aperi_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev