72708 - Need trivial changes to oji module to support OJI 2

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect)

Comment 1

[edburns]

Attachment: cvs diff -u of fix for this bug, provided by [e-mail]

Comment 2

[drapeau]

Hey, how about specifying what kind of trivial changes, or why?  Somethin' like
that.  It's easier than me looking at the patch (call me lazy).

Comment 3

[Nikolay Igotti]

Changes are:
  - adding IID accessors to nsIJVMPlugin and nsIJVMConsole interface - I think
    better patch would  add accessors to the end of interface definition -
    to save binary compatibility with Java Plugin
 -  together with old way of obtaining of JVM service (GetFactory) use new way
    GetService - it's good anyway and shouldn't break Java Plugin

Comment 4

[edburns]

Need review.

Comment 5

[drapeau]

edburns: you can review this change yourself, can't you?  You're the OJI module
owner.  I think all you may need is sr=, but you *should* be able to do the r=
yourself, right?

Comment 6

[edburns]

ra=edburns (this patch is from Nikolay Igotti, I'm not the original author).

Comment 7

[Chris Waterson]

cc'ing [e-mail]. andrei: edburns is going to use the service manager to 
get the JVM instead of nsIPluginHost::GetPluginFactory(). What do you think?

edburns: don't use NS_WITH_SERVICE; instead, do

  nsCOMPtr<nsIPlugin> f =
    do_GetService(<insert contract-id here>, &err);

If av's okay with the change, sr=waterson.

Comment 8

[Chris Waterson]

Hrm. Just thought of something. If you're forcing the plugin to be installed as 
an XPCOM component now, then you'll force a double-install of the Java plugin on 
someone's machine.

For example, if someone had installed the Sun Java plugin in the 4.x plugins 
directory, then (in theory), Mozilla would find that plugin as part of the 
normal course of loading plugins. (On Windows anyway.)

Do you really want to break that?

Comment 9

[drapeau]

waterson: good point.  I think this was already covered by bug 27755, though
(Mozilla looks for OJI plug-in firstn in old Navigator's plugins directory).
The bug was fixed.  In the analysis, it looks as if two handlers for the
x-java-vm MIME type are indeed registered, but the "correct" one gets priority
(the one that's in the Mozilla plugins dir).

Seems to me that this would be the same case: I'm guessing (but don't actually
know) that XPCOM components that act as MIME type handlers would also get put on
the head of the plugins list, ahead of 4.X plugins.  If that's correct, then I
think the issue you bring up won't hurt us.

Does anybody know if that's true, though?  (XPCOM MIME type handlers get put on
the head of the list, ahead of 4.X plugins)

Comment 10

[av (gone)]

No, George, 27755 is about plugins from 4.x installation. What Chris is talking 
about (if I got it right) is that we may have a plugin in the Plugins folder of 
Mozilla installation and an xpcom component capable of handling the same mime 
type. And again, no, xpcom components do not take over legacy plugins. If we 
have a component and a plugin for the same mime type they both will be in the 
list of handlers, moreover, plugin will be picked up as plugins are scanned 
after components thus added ahead of components in the list.

This is a big issue, I believe there is a bug on this: we need to implement a 
mechanism to manage mime type handlers choosing one and disabling others.

Comment 11

[drapeau]

Hey Andrei: yep, I know that bug 27755 is about 4.X plugins, not XPCOM.  I 
pointed out the bug because it's similar in the sense that there's a priority 
ordering going on.  And it turned out that, even though 4.X plugins were loaded 
last, the fix was to put them *after* Mozilla plugins (originally, if you put 
4.X plugins in the plugin list last, they got put at the top of the list, but 
you were good enough to change that behavior).

Still, I see your point that the XPCOM-vs-MozillaPluginsFolder clash can't be 
that easily resolved.

So, it sounds like the priority order for MIME type handlers is this:

1) Legacy plugins in the Mozilla plugins directory
2) Legacy plugins in the $HOME/.netscape/plugins directory (you know what I 
mean)
3) XPCOM-style plugins in the $MOZILLA/dist/bin/components directory.

Do I have that right?
And do you know the bug number for the "need mechanism to manage mime type 
handlers" issue you mentioned?  That would be helpful to know.

Comment 12

[av (gone)]

George Drapeau wrote:
> So, it sounds like the priority order for MIME type handlers is this:
> 1) Legacy plugins in the Mozilla plugins directory
> 2) Legacy plugins in the $HOME/.netscape/plugins directory (you know what I 
> mean)
> 3) XPCOM-style plugins in the $MOZILLA/dist/bin/components directory.
> Do I have that right?

Not exactly. It's more like this:
1) legacy plugins in home/netscape/plugins (but this doesn't really matter much 
since we do it for 'big three' only and on Windows only)
2) legacy plugins in Mozilla (but if the filename is the same it will throw away 
a candidate from punkt ein. E.g. Flash from Mozilla Plugins folder will take a 
command even there is Flash in Netscape 4.x installation. So number one doesn't 
really matter at all
3) XPCOM-style plugins in the $MOZILLA/dist/bin/components directory.

Comment 13

[edburns]

I agree that this discussion is important for waterfall, but it's not directly 
applicable to this bug's checkin.  Av, can you give me r= for the diff?  

Thanks,

Ed

Comment 14

[av (gone)]

r=av

Comment 15

[edburns]

Fix checked in.

Comment 16

[edburns]

Nikolay, the change to jri_md.h, broke the build.  Can you work around this 
file in your build scripts?

Comment 17

[Nikolay Igotti]

Yes, I can work around it, for example with 
define JRI_MD_H 
in nsoji.idl. But I think we need big review of JNI headers usage in Mozilla.
Why we need jri.h jri_md.h at all? And jni.h jni_md.h should be taken from
JDKROOT.

Comment 18

[edburns]

We'll work around the jri_md.h problem.  Marking fixed.

Comment 19

[shrirang khanzode]

spam : marking verif( rubberstamp)