This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 28126 - Install-Before not working after new module introduced.
Summary: Install-Before not working after new module introduced.
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on: 29671
Blocks:
  Show dependency tree
 
Reported: 2002-10-18 19:17 UTC by Michael Ottati
Modified: 2008-12-23 08:30 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Zip file with additional files for this case. (18.43 KB, application/octet-stream)
2002-10-18 19:20 UTC, Michael Ottati
Details
IDE Log with old (pre manifest change) ser file used at startup. (103.62 KB, text/plain)
2002-10-18 23:39 UTC, Michael Ottati
Details
IDE Log when loaders.ser was first purged from the userdir (96.71 KB, text/plain)
2002-10-18 23:40 UTC, Michael Ottati
Details
Options screen with old loaders.ser file (60.68 KB, image/png)
2002-10-21 19:10 UTC, Michael Ottati
Details
Options screen when loaders.ser has been purged. (67.51 KB, image/png)
2002-10-21 19:11 UTC, Michael Ottati
Details
Possible patch (1.87 KB, patch)
2002-10-21 20:46 UTC, Jesse Glick
Details | Diff
Proposed 3.4.1 patch (1.84 KB, patch)
2002-11-29 14:28 UTC, Jesse Glick
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Ottati 2002-10-18 19:17:33 UTC
In making a simple change to a module in s1studio, I  
changed the manefist to express that my data loader would 
be installed before the loaders defined in the jarpackager 
module. In order to do this, I added the following lines 
to my manifest.



Name: 
com/sun/forte4j/j2ee/ejbmodule/importejbjar/EJBJarLoaderDat
aLoader.class
OpenIDE-Module-Class: Loader
Install-Before: 
org.netbeans.modules.jarpackager.JarDataObject,
    org.netbeans.modules.jarpackager.SimpleJarDataObject

When testing the change, my moules file recognition did 
not take place. It was not until I deleted the 
system/loaders.ser file from the user directory, that the 
proper loader order took effect.

How I made the change:

1:   Made the manifest change to my module.
2:   Rebuilt the jar.
3:   Copied the jar into firststart/modules/
4:   Ran the test out of firststart.

It was not until I removed the loaders.ser file that the 
system worked as I expected it to.

Reproducing this problem will perhaps take a fair amount 
of configuration, and would involve more data that is 
allowed to be attached to an IZ case.

The following should be sufficient to reproduce.

1:  Get a copy of s1studio that exhibits the original 
problem from 
http://ffj.ebay/kits/ffj/trunk/Build021014_1/FFJ-dev-
021014_1-f4j_ee.zip (about 35 megabytes)

2:  run it and look at the attached EJB-Jar file in the 
explorer.

3:  make the change described above to the manifest of 
ejbmodule.jar 

4:  Run again and look at the file from step 2.

5:  shutdown and delete loaders.ser 

6:  run again and look at the files from step 2.

At this point the icon for the jar file should change and 
be expandable.

I am attaching to this case the following files, all 
zipped up into a single attachment.

Files attached.

The log and loaders.ser files when the change is first 
made to the module.
ide.log.afterPurge
loaders.ser.afterPurge

The log and loaders.ser which was created after purging 
the original.
ide.log.beforePurge  
loaders.ser.beforePurge


Test data which should be recognized by the Install-Before 
change.
Module.jar

Modified manifest file for ejbjarmodule

manifest.mf
Comment 1 Michael Ottati 2002-10-18 19:20:32 UTC
Created attachment 7709 [details]
Zip file with additional files for this case.
Comment 2 Jesse Glick 2002-10-18 21:34:24 UTC
Oops, forgot to have you set

-J-Dorg.netbeans.core.LoaderPoolNode=0

during all these operations and attach ide.log. That would be helpful.
Comment 3 Michael Ottati 2002-10-18 23:39:19 UTC
Created attachment 7710 [details]
IDE Log with old (pre manifest change) ser file used at startup.
Comment 4 Michael Ottati 2002-10-18 23:40:57 UTC
Created attachment 7711 [details]
IDE Log when loaders.ser was first purged from the userdir
Comment 5 Jesse Glick 2002-10-21 16:38:15 UTC
Well, the log claims that your loader was in fact installed before
either of the JAR loaders. Did you confirm that the ordering was
actually incorrect in Object Types in the Options dialog, or just that
file recognition failed to work as expected until after a restart? If
you did not check this, my guess is that the refreshing of the data
object pool was the problem, not the loader ordering.
Comment 6 Michael Ottati 2002-10-21 19:10:11 UTC
Created attachment 7724 [details]
Options screen with old loaders.ser file
Comment 7 Michael Ottati 2002-10-21 19:11:46 UTC
Created attachment 7725 [details]
Options screen when loaders.ser has been purged.
Comment 8 Michael Ottati 2002-10-21 19:14:25 UTC
I have attached the options screens. Looks to me like the 
order is different depending on if I start with the old 
loaders.ser file or if I start with no loaders.ser file.
Comment 9 Jesse Glick 2002-10-21 20:45:29 UTC
Indeed. Unfortunately the order reported in the log file under "After
sort:" does not at all match the order shown in the Object Types node.
Looks like readPool() reverted the order.

If you *add* a new loader with an Install-Before or Install-After
declaration, the pool gets resorted. But I guess adding such an
ordering attr to an *existing* loader does not trigger the resort.

Please try the attached patch (untested) and let me know if it fixes
the problem for you.
Comment 10 Jesse Glick 2002-10-21 20:46:22 UTC
Created attachment 7726 [details]
Possible patch
Comment 11 Jesse Glick 2002-10-21 20:47:02 UTC
See also issue #13880 which was somewhat similar.
Comment 12 Jesse Glick 2002-10-24 18:01:07 UTC
Seems to be fixed now.

committed     Up-To-Date  1.62       
core/src/org/netbeans/core/LoaderPoolNode.java
Comment 13 Jesse Glick 2002-11-29 14:28:53 UTC
Created attachment 8112 [details]
Proposed 3.4.1 patch
Comment 14 Jesse Glick 2002-11-29 14:29:45 UTC
Someone want to review this patch please?
Comment 15 Jesse Glick 2002-12-02 19:17:05 UTC
Still awaiting review.
Comment 16 Jaroslav Tulach 2002-12-03 09:53:46 UTC
Hi. This issue is marked as 3.4.1_CANDIDATE. It means that it should be
integrated into release341 one branch. The plan at
http://www.netbeans.org/devhome/docs/releases/34/index.html expected beta1 to be
produced on Dec01. That did not happen due to a lot of outstanding not
integrated candidates like this one. 

Would it be possible to spend few minutes by backporting this fix? Thank you in
advance.
Comment 17 Jaroslav Tulach 2002-12-03 10:18:47 UTC
How should I review this, I have not seen the class for a long time. I
can only confirm that the changes look fine. And if it seems to work
then fine.
Comment 18 Jesse Glick 2002-12-03 23:05:13 UTC
In release341:

Checking in core/src/org/netbeans/core/LoaderPoolNode.java;
/cvs/core/src/org/netbeans/core/LoaderPoolNode.java,v  <-- 
LoaderPoolNode.java
new revision: 1.58.46.1; previous revision: 1.58
done

To verify: confirm that under Object Types, Image is below URL. Shut
down. Edit image.jar manifest:

<<<
Install-Before: org.netbeans.modules.text.TXTDataObject
===
Install-Before: org.netbeans.modules.text.TXTDataObject,
org.netbeans.modules.url.URLDataObject
>>>

Restart. Image should be above URL.
Comment 19 Marian Mirilovic 2005-07-12 09:05:34 UTC
closed