Bug 208160 - Position of mime resolvers is broken & they may be ignored in unit tests
Position of mime resolvers is broken & they may be ignored in unit tests
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Data Systems
7.2
All All
: P1 (vote)
: 7.2
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
: 208167 (view as bug list)
Depends on:
Blocks: 208111
  Show dependency treegraph
 
Reported: 2012-02-08 11:23 UTC by Vladimir Voskresensky
Modified: 2012-02-22 10:59 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vladimir Voskresensky 2012-02-08 11:23:28 UTC
due to http://hg.netbeans.org/releases/rev/e7d30459a7f9

mix of annotation based registration and layer based registrations causes
incorrect ordering of resolvers:
all layer.xml based resolvers are put before all annotation based resolvers after
Comment 1 Vladimir Voskresensky 2012-02-08 11:25:09 UTC
was found when evaluating issue #208111
Comment 2 Jaroslav Tulach 2012-02-09 09:58:06 UTC
Right. That is the reason why all layer based resolvers in the distribution were converted to annotation based.

The fix is to convert all others as well. Should be fairly easy with @MIMEResolver.Registration. This evaluation would mean won'tfix.

Alternatively I can change the annotation based resolvers to take priority. This would require an API review.
Comment 3 Vladimir Voskresensky 2012-02-09 11:40:27 UTC
(In reply to comment #2)
> Right. That is the reason why all layer based resolvers in the distribution
> were converted to annotation based.
> 
> The fix is to convert all others as well. Should be fairly easy with
> @MIMEResolver.Registration. This evaluation would mean won'tfix.
(In reply to comment #2)
> Right. That is the reason why all layer based resolvers in the distribution
> were converted to annotation based.
> 
> The fix is to convert all others as well. Should be fairly easy with
> @MIMEResolver.Registration. This evaluation would mean won'tfix.
The problem is that platform was changed incompatibly => application based on RCP have to be rewritten to work on this state of platform (i.e. by replacing all layer.xml based registration to annotations)

> 
> Alternatively I can change the annotation based resolvers to take priority.
> This would require an API review.
Why position is not enough to sort both kind or resolvers?
Comment 4 Jaroslav Tulach 2012-02-09 19:29:48 UTC
Will try.
Comment 5 Jaroslav Tulach 2012-02-10 13:21:04 UTC
Fix 0bcc265ca338 made declarative resolvers available in unit tests even if none of them are included in a lookup. However this still leads to problems with tests that are registering their own resolvers into lookup (bug 208167).

Moreover the combination of XML resolvers being read from file object directly and @MR.xyzRegistration resolvers being read from lookup does not respect mutual positioning. 

Moreover constructing FolderLookup is not easy as it requires some mime resolution (.instance, JavaHelp.xml, folders), but it also currently produces list of registered mime resolvers. 

Thus I am going to stop using .instance files. I'll rename them. Possibly to .xml and just annotate them with attributes that will take precedence when converting them to resolvers.
Comment 6 Jaroslav Tulach 2012-02-10 13:21:08 UTC
*** Bug 208167 has been marked as a duplicate of this bug. ***
Comment 7 Jaroslav Tulach 2012-02-10 14:16:28 UTC
core-main#bbc75f9bab51
Comment 8 Petr Jiricka 2012-02-13 10:55:15 UTC
The JavaScript tests are still failing after 3 days in JavaEE build #3742: http://bertram2.netbeans.org:8080/job/javaee/, reopening. Looks like this change is not in the build yet?
Comment 9 Jesse Glick 2012-02-13 21:39:34 UTC
(In reply to comment #7)
> core-main#bbc75f9bab51

Does not appear to exist, did you forget to push it?

If you are not using *.instance, maybe move out of Services altogether. The history is a little complicated - originally Services/MIMEResolver/*.xml had InstanceCookie and were loaded essentially using Lookup.getDefault().lookupAll(MIMEResolver.class), which permitted declarative and procedural resolvers to be intermixed. When that was changed so as to avoid a dep on loaders (bug #138846), they had to be separated (and 10d30eec11f7 put the declarative ones first, effectively making the procedural ones useless), though for compatibility the declarative resolvers were still read from the same location.

It is possible that procedural resolvers, manually registered declarative resolvers, and annotation-registered resolvers could all be loaded with a single call to Lookups.forPath("Services/MIMEResolver") - and thus freely intermixed - if RecognizeInstanceFiles were made to load the MIMEResolver objects from the declarative forms, and RecognizeInstanceObjects also delegated to this impl somehow.
Comment 10 Jaroslav Tulach 2012-02-20 14:13:57 UTC
(In reply to comment #9)
> (In reply to comment #7)
> > core-main#bbc75f9bab51
> Does not appear to exist, did you forget to push it?

Probably. It is there right now.

> If you are not using *.instance, maybe move out of Services altogether. 

The recent problems are caused by ordering. The old definitions and new definitions should inter-mix. Which is what I get when keeping the definition in Services/MIMEResolver for free.
Comment 11 Quality Engineering 2012-02-22 10:59:53 UTC
Integrated into 'main-golden', will be available in build *201202220400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/bbc75f9bab51
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #208160: Keep ordering by generating just .xml files


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo