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 249383 - in Studio IDE Pro*C templates are broken
Summary: in Studio IDE Pro*C templates are broken
Status: NEW
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 8.1
Hardware: All All
: P3 normal (vote)
Assignee: Jaroslav Havlin
URL:
Keywords: REGRESSION
Depends on:
Blocks:
 
Reported: 2014-12-16 12:01 UTC by Maria Tishkova
Modified: 2016-09-02 10:51 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maria Tishkova 2014-12-16 12:01:13 UTC
In Oracle Solaris Studio nightly (trunk) builds IDE creates broken Pro*C           project (project contains test.pc.pc file instead of test.pc)
Comment 1 Maria Tishkova 2014-12-16 12:03:13 UTC
Generated pro*C file has double extension (.pc.pc)
and broken content:

${rowStruct}

${rowStructPtr}



instead of dynamically generated structure  which are based on the selected databsse/tables

struct friends_row {
    char name[4000];
    char surname[4000];
};

struct friends_row *friends_row_ptr;
Comment 2 Vladimir Voskresensky 2014-12-16 13:06:42 UTC
Svata, please, fix the next issue with templates
Comment 3 Vladimir Voskresensky 2014-12-25 15:19:05 UTC
Svata, any progress on this? I can reproduce it. Any loggers to turn on?
Comment 4 Svata Dedic 2015-01-05 14:14:47 UTC
The reason is rather subtle; all Pro*C template handlers derive from the (deprecated) org.openide.loaders.CreateFromTemplateHandler and are registered against this interface in the META-INF/services.

The Lookup implementation seems to order instances of subclasses of looked-up service *before* instances registered directly against the serivce. So implementation of (updated) Scripting handler (registered as api.templates.CFTH) were ordered after all Pro*C CFTHs (registered as openide.loaders.CFTH).

Therefore the PcCreateFromTemplateHandler was actually used instead of Scripting handler. 

A simple solution is to define a position for the default Scripting handler: services without position are ordered after all instances with position.

Random behaviour of the defect may be result of subtle changes in Lookup implementation during the time the defect was observed. 

This can be seen as a defect in Lookup implementation: while not explicitly said in lookup API definition, the defined registration techniques indicate the order of instances (without position attribute) should be driven by classpath = module dependencies = registrations for subclass of S should always follow registrations for S.

So I will not close the defect, but lower priority and pass over to Lookup maintainer(s).

Position of the default scripting handler fixed in jet-main#8d70610ef4bc
Comment 5 Quality Engineering 2015-01-07 04:01:13 UTC
Integrated into 'main-silver', will be available in build *201501070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/8d70610ef4bc
User: Svata Dedic <sdedic@netbeans.org>
Log: #249383: scripting handler specifies position so it is listed before handlers without a position - compatibility with pre-8.x