Hi Pierre,

Thanks! removing the destroy callback resolves the issue. And nice to learn
that you don't have to remove these dependencies manually anymore :)

One more thought ... I think the onRemoved callback is also not really
useful in this case as it's only cleaning up the WinkServlet instance but
once onRemoved is called this instance will never be re-used so cleaning
would not be needed here?

I've created FELIX-5274 for this.

Regards,
Bram

On Wed, Jun 1, 2016 at 9:57 PM Pierre De Rop <[email protected]> wrote:

> I now see the warnings while running the org.amdatu.web.rest.itest project
> !
>
> ok, Bram, I took a look at the WinkServlet, and I see that from
> the WinkServlet.dmInit() method, a dependency is dynamically added:
>
>     protected void dmInit() {
>         ServiceDependency dep =
> m_component.getDependencyManager().createServiceDependency()
>                 .setService(JaxRsRequestInterceptor.class)
>                 .setRequired(false)
>                 .setCallbacks(m_requestInterceptorHandler,
> "addedInterceptor", "removedInterceptor");
>
>         m_component.add(dep);
>         m_requestInterceptorDependency = dep;
>     }
>
> This is perfectly OK.
>
> now, from the dmDestroy() method, I see that the dynamic dependency is then
> removed:
>
>     protected final void dmDestroy() {
>         if (m_requestInterceptorDependency != null) {
>             m_component.remove(m_requestInterceptorDependency);
>             m_requestInterceptorDependency = null;
>         }
>     }
>
> But since the improvement made in FELIX-5054 (see [1]), it is not needed
> anymore to cleanup "instance bound" dependencies from the destroy method,
> because DM does this automatically for you.
>
> Now, I tried to comment the dmDestroy method, and it seems to work
> seamlessly (no more warnings displayed):
>
>     protected final void dmDestroy() {
> //        if (m_requestInterceptorDependency != null) {
> //            m_component.remove(m_requestInterceptorDependency);
> //            m_requestInterceptorDependency = null;
> //        }
>     }
>
> Can you confirm that it also works in your environment ?
>
> However, even if it's ok now, of course, if you still remove the dynamic
> dependency from the destroy method (it is your initial case), then it
> should still work seamlessly without any warnings displayed, so it seems
> that you came across a bug which happens when you remove the dynamic
> dependency from the destroy callback.
>
> Can you please open a JIRA issue, I will investigate it asap. In the
> meantime, I think you can just remove the dmDestroy callback, which is not
> necessary anymore since the FELIX-5054 fix.
>
> many thanks;
>
> [1] https://issues.apache.org/jira/browse/FELIX-5054
>
> cheers
> /Pierre
>
> On Wed, Jun 1, 2016 at 7:34 PM, Bram Pouwelse <[email protected]> wrote:
>
> > Hi Pierre,
> >
> > Just built dm from trunk but I get the same log message :(
> >
> > You can checkout the branch (feature/AMDATUWEB-59) and run the itests
> > from org.amdatu.web.rest.itest
> > project. I've added some sysouts in the callback methods log (appended at
> > the end of the message) ... so it's only the onRemove callback that
> fails.
> >
> > Regards,
> > Bram
> >
> > onAdd
> > init
> > onChange
> > onAdd
> > init
> > onAdd
> > init
> > destroy
> > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> > found on component instances []
> > onChange
> > onAdd
> > init
> > onAdd
> > init
> > onAdd
> > init
> > destroy
> > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> > found on component instances []
> > destroy
> > [main] ERROR org.amdatu.web.rest.wink - [main] "onRemove" callback not
> > found on component instances []
> >
> >
> >
> > On Wed, Jun 1, 2016 at 5:43 PM Pierre De Rop <[email protected]>
> > wrote:
> >
> > > Hello Bram,
> > >
> > > The "callback not found on component instances ..." log is normally
> > > displayed when a callback is not found from some given callback
> > > instance(s).
> > >
> > > However, I just saw that when a callback instance was used (it is the
> > case
> > > when an adapter is used), then the log was wrong: it did not log the
> > actual
> > > callback instance.
> > >
> > > I fixed this in the  revision 1746480.
> > > Can you please svn update the dm from the trunk, and try to reproduce,
> > and
> > > see if the log is more meaningful now ?
> > >
> > > Then , if you can't figure out what is going one, then can you tell me
> > how
> > > I can reproduce the problem using amdatu-web ?
> > >
> > > let me know.
> > >
> > > cheers;
> > > /Pierre
> > >
> > > On Wed, Jun 1, 2016 at 4:33 PM, Bram Pouwelse <[email protected]>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I have some troubles with a dependency manager adapter service, for
> > some
> > > > reason it fails to call the remove callback (looking at the message
> > there
> > > > are no instances available to invoke the method on). Tried to
> reproduce
> > > the
> > > > issue in less complex project but I don't have the problem there...
> > > >
> > > > The component is added in the DependencyActivatorBase#init method
> full
> > > > source is in bitbucket [1]
> > > >
> > > > manager.add(createAdapterService(ApplicationService.class, null,
> > "onAdd",
> > > > "onChange", "onRemove")
> > > >   .setInterface(Servlet.class.getName(), null)
> > > >   .setImplementation(WinkServlet.class)
> > > >   .setCallbacks("dmInit", "dmStart", "dmStop", "dmDestroy")
> > > >   );
> > > >
> > > > Any hints on where to start looking would be welcome ;)
> > > >
> > > > Regards,
> > > > Bram
> > > >
> > > > 1:
> > > >
> > > >
> > >
> >
> https://bitbucket.org/amdatu/amdatu-web/src/74aabd7944c1e2365d2f8313228d69f3278a1d7a/org.amdatu.web.rest/src/org/amdatu/web/rest/wink/Activator.java?at=feature%2FAMDATUWEB-59&fileviewer=file-view-default
> > > >
> > >
> >
>

Reply via email to