Bug 52779 - Improve ConfigurationSupport for CMP mapping
Improve ConfigurationSupport for CMP mapping
Status: RESOLVED FIXED
Product: serverplugins
Classification: Unclassified
Component: Infrastructure
4.x
PC Linux
: P1 (vote)
: 4.x
Assigned To: apireviews
issues@serverplugins
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-22 23:46 UTC by Nam Nguyen
Modified: 2005-01-03 20:42 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
:


Attachments
apichanges description (3.50 KB, text/plain)
2004-12-23 08:06 UTC, Nam Nguyen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nam Nguyen 2004-12-22 23:46:38 UTC
CMP Entity Bean mapping wizard need allow creation
of a set of related CMP entity beans from a
database schema.  At the end, the wizard will push
the mapping info to the plugin for writing out to
server specific descriptors.

The original design for this CMP mapping info push
is that the wizard code going through each bean
and push the mapping one by one using following SPI:

ConfigurationSupport {
    void setMappingInfo(DeploymentConfiguration
config, String ejbName, OriginalCMPMapping mapping);
}

Now that the plugin start using this API, this
design showed weaknesses in that:
- plugin has to write multiple times to file,
causing unecessary file events.
- resolving relationships b/w beans would be more
clumsy.

To eliminate these weaknesses, this API change
proposes the following improvement for single push
protocol:

(1)
ConfigurationSupport {
    void setMappingInfo(DeploymentConfiguration
config, OriginalCMPMapping[] mapping);
} 

(2)
OriginalCMPMapping {
    String getEjbName();
}

(3)
OriginalMappingProvider removed.

Change (1) is not a incompatible change because
the interface is new for this release.  

Change (2) is an incompatible one because it add
access method to existing interface.  However, we
did not expect plugins to use this interface
without the new SPI ConfigurationSupport
introduced in this release. 

Change (3) is for cleanup a interface that is not
going to be used because of change in model of
exchange mapping info b/w CMP wizard and the
plugin code.  The push model is a better choice
with current J2eeserver framework than the pull
model that was used with old J2eeserver framework.
 None of our devmodules are using this SPI, so it
is safe to simply remove it.
Comment 1 Nam Nguyen 2004-12-23 06:58:57 UTC
Since the general expectation from a wizard is user should not need to
do an explicit save to persist the changes resulted from using the
wizard,  we also need an additional changes to give wizard code
ability to commit changes to configuration DD.  Here is the additional
change:

o.n.m.j2ee.deployment.devmodules.spi.J2eeModuleProvider.ConfigSupport {
    void saveConfiguration();
}

Plugin could save configuration itself, but in case a wizard craete a
set of new beans, multiple save is bad performance and also causing
weird UI effect (e.g. flickering save all button...).
Comment 2 Nam Nguyen 2004-12-23 08:06:06 UTC
Created attachment 19400 [details]
apichanges description
Comment 3 Nam Nguyen 2004-12-23 08:09:59 UTC
I would like to waive unit test of this api change due to the routing
nature of the involved API's/SPI's.
I have a question about signature test.  Do I have take care of
changing the golden file?  If so, please point to location and
procedure to run the test.  Thanks.
Comment 4 Nam Nguyen 2005-01-03 14:15:47 UTC
I would like to fast-track this api change due to 4.1 EA2 code-freeze
coming up.
Comment 5 Jaroslav Tulach 2005-01-03 14:41:36 UTC
I thought that this was always fastrack and I know the issue has been
here for more than a week. From my point of view, you can go on...
Comment 6 Nam Nguyen 2005-01-03 20:42:09 UTC
Described changes checked in.


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