[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aperi-dev] V0.3 Status on various issues
|
XML Validation from behind a firewall:
The authentication declarations from
the deployment descriptor are 2.3 compatible, only the <security-role>
elements are to be moved after the <login-config> element.
Linux Client and SWT Browser Widget:
I suggest to ask the SWT platform developer
to send us one of his examples that work with BASIC authentication on Linux.
We could see whether the problem is from the Linux environment or is specific
to our application.
Regards,
Rodica
Dave Wolfe <dwolfe@xxxxxxxxxx>
Sent by: aperi-dev-bounces@xxxxxxxxxxx
04/28/2007 11:15 PM
Please respond to
Aperi Development <aperi-dev@xxxxxxxxxxx> |
|
To
| Aperi Development <aperi-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| [aperi-dev] V0.3 Status on various issues |
|
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
_______________________________________________
aperi-dev mailing list
aperi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aperi-dev