[Bug 3350] missing codebase attribute may casue NPE in ALACA dialogue

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3350

--- Comment #15 from stefan at kemtrak.com ---
Hi, quick answer:
I'll be testing "." codebase ASAP, thanks a huge bunch for the tip!!

If it fixes that, I will test on all platforms to see it still works (Win XP
with Java 7.45 was very picky about that, having a "*" codebase made it fail -
omitting it worked, I'll try with "." now).

If ti works I will then implement that fix, so none of my customers will have
any problems at all!

Also: Since the current code works on all other platforms except IcedTea,
customer has the option to run it still using another platform.

So we have no emergency.

I will also answer you mail as soon as I have run the tests.

I understand the point that ITW correctly returns codebase as null but if you
read the jnlp 7.0 spec, I think it can be omitted from the jnlp file. That's
what I understood. And it seems omitting works on all other platforms. So ITW
should still work if it is null/omitted. It is also good for consistency
against the developers. That the code works the same on all platforms. You can
think about that.

As I said I will also answer you mail as soon as I have run the tests.

(In reply to JiriVanek from comment #14)
> > > this is very starnge. Do you mind to verify even with cleared cache? (javaws
> > > -Xclearcache)
> > 
> > Yes, nice you mentioned that, it can be very confusing with caching. I will
> 
> Speaking about mentioning - try to enable java-console (in debugging panel)
> it is providing very good info. Yo can separate stdout/err and itw/app logs,
> and much more...
> 
> > from now on clear the cache between any run to make sure.
> > I can report that with clean cache the results are slightly different. This
> > time Today I have also ran multiple times each experiment to make sure. So:
> > 
> > With *none* of the 
> > 1) deployment.manifest.attributes.check=NONE
> > 2) deployment.security.level=ALLOW_UNSIGNED
> > I get the initial bug report - nothing loads
> > 
> > With just nr.2 activated, main class loads but nothing else
> > Different than yesterday: With just nr.1 activated, now - main class loads
> > again but nothing else. Yesterday this did not happen, I guess probably
> > because it ran a cached version.
> > 
> > Unfortunately I can't really say I understand the results. But I hope it
> > helps you.
> 
> Nor do I. This is really strange. For me the app works 100% after fixing
> yours bug. Also before fixing it worked 100% *except*
> deployment.security.level=ALLOW_UNSIGNED -which triggered the bug.
> 
> This looks like issue in itw, but I will skip it as (at least for while or
> while you bug it again if it harms later) it is different issue.
> 
> > > > 
> > > > [ITW-JAVAWS][ERROR_DEBUG][Wed Apr 05 14:57:25 CEST
> > > > 2017][net.sourceforge.jnlp.Parser.getParserInstance(Parser.java:1351)] NETX
> > > > Thread# 5fd0d5ae, name main: java.lang.ClassNotFoundException:
> > > > net/sourceforge/jnlp/MalformedXMLParser
> > > 
> > > This smell like packaging bug. Missing tagsoup!
> > 
> > If there is any HTML or XML tag I need to add to make it work, I am more
> > than happy to try.
> 
> No. Thats build switch. Looks like your distro (ubuntu) is not using tagsoup
> (as it is optional, but crucial ) dependence.
> > 
> > > > 
> > > > [ITW-JAVAWS][ERROR_DEBUG][Wed Apr 05 14:57:25 CEST
> > > ...
> > > > 
> > > > By the way both .jar files are signed.
> > > 
> > > Are they signed by same cert or each by its own?
> > 
> > Same certificate but they are signed on different dates. Still
> > Kemtrakpro.jar contains all the important classes, jcalender only contains a
> > calender implementation.
> 
> that is good and correct
> > 
> > > 
> > > > 
> 
> So your original bug - form code point - seems to be resolved (c#9). 
> I will keep this open for a related discussion. But close later.
> 
> Now the question is, how much busines blocker it is?
> 
> 
> btw - you can (imho) fix this whole thing by using codebase="." in jnlp
> file. All troubles should disappear.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20170406/7cf536da/attachment-0001.html>