In this case, since it is only the constructor changing, I'm +1
on
Lukas' proposal.
+1
The existing javadocs appear clear that this is not an api plugin dev's should have
been using.
The plugin dev would not even have access to all of the data needed
to
pass INTO that constructor; so even if they wanted to, they couldn't
call it.
Also, the public javadoc clearly indicate that plugin devs are not to
call the constructor/instantiate this object themselves:
javadoc on the class:
/**
*...
* <p>This context class is currently designed to be an immutable
object. Instances of this context object are to be
* created by the plugin container only.</p>
*...
*/
and the javadoc on the constructor itself:
/**
* Creates a new {@link ResourceContext} object. The plugin
container is responsible for instantiating these
* objects; plugin writers should never have to actually create
context objects.
On Tue, 2012-02-21 at 13:28 -0600, Larry O'Leary wrote:
> I would prefer the deprecation approach. i.e. overload the
> constructor
> with the new form... mark the existing version as deprecated and
> have it
> call the new one passing in a meaningful default.
>
> Then, the next major release, all items marked as deprecated could
> be
> removed. I understand that we would not expect someone to use the
> constructor directly, the point is that it is part of the API.
>
> On Tue, 2012-02-21 at 11:19 -0500, Ian Springer wrote:
> > +1.
> >
> > For clarity, you could add notes to the class and constructor
> > Javadocs
> > stating that the class is not intended to be instantiated by
> > plugins.
> >
> > On 02/21/2012 11:15 AM, Lukas Krejci wrote:
> > > Hi all,
> > >
> > > in fix for
https://bugzilla.redhat.com/show_bug.cgi?id=794489 I
> > > needed to change the ResourceContext class, which is part of
> > > our plugin API. The API changes were following:
> > >
> > > 1) add (yet another) parameter to the constructor of the class
> > > 2) add a protected method (this is not necessarily required but
> > > good from the code reuse POV).
> > >
> > > (the diff is here:
> > >
http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=blobdiff;f=modules/core/...)
> > >
> > > I don't think this should be considered a change in our public
> > > plugin API, because ResourceContext is not meant to be
> > > constructed by plugin code (an instance of ResourceContext is
> > > merely provided to a resource component during the
> > > ResourceComponent.start() method). The protected method is a)
> > > not publicly accessible and b) doesn't clash with any
> > > pre-existing method on that class.
> > >
> > > Even though I'm reasonably confident about that opinion, I'd
> > > like to get an agreement on it from other team members.
> > >
> > > Thanks,
> > >
> > > Lukas
> > > _______________________________________________
> > > rhq-devel mailing list
> > > rhq-devel(a)lists.fedorahosted.org
> > >
https://fedorahosted.org/mailman/listinfo/rhq-devel
> >
> >
>
>
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel