9 Dec
2012
9 Dec
'12
6:39 p.m.
Hello,
I have a problem with a unit test (extending
AbstractBridgedComponentTestCase) of a component.
That component is injected with several xwiki components (QueryManager,
Logger, ExecutionContext ...) that get properly automatically mocked by the
test setup. I inherit from xwiki-commons-pom 4.3.
But the following:
@Inject
LoggerManager loggerManager;
... fails to be mocked by the test, or to be available from the embeddable
component manager :
...
Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find
descriptor for the component [role = [interface
org.xwiki.logging.LoggerManager] hint = [default]]
at
org.xwiki.component.embed.EmbeddableComponentManager.getComponentInstance(EmbeddableComponentManager.java:355)
at
org.xwiki.component.embed.EmbeddableComponentManager.getInstance(EmbeddableComponentManager.java:161)
...
I checked it's a org.xwiki.logging.LoggerManager, has a @Role, everything
seems ok ...
Any help welcome,
BR,
Jeremie
10 Dec
10 Dec
1:22 p.m.
Hi,
I could workaround that quite easily, by adding the following in my setUp()
method, just before retrieving my class under tests from the component
manager:
getComponentManager().registerMockComponent(getMockery(),
LoggerManager.class);
But it seems to confirm that, for any reason, the LoggerManager was not
automatically mocked by AbstractBridgedComponentTestCase.
BR,
Jeremie
--
View this message in context:
http://xwiki.475771.n2.nabble.com/Problem-mocking-LoggerManager-tp7582812p7…
Sent from the XWiki- Users mailing list archive at Nabble.com.
1:36 p.m.
Hi Jeremie,
On Dec 10, 2012, at 1:22 PM, jerem <jeremie.bousquet(a)gmail.com> wrote:
Hi,
I could workaround that quite easily, by adding the following in my setUp()
method, just before retrieving my class under tests from the component
manager:
getComponentManager().registerMockComponent(getMockery(),
LoggerManager.class);
But it seems to confirm that, for any reason, the LoggerManager was not
automatically mocked by AbstractBridgedComponentTestCase.
This is an old/legacy class and you should try to not use it.
That said it extends AbstractComponentTestCase which will register in the CM all annotated
components it finds in the CP.
The only reason it wouldn't register one component is because it's not in the CP.
So either you don't have that dep voluntarily in your pom.xml because it's a
runtime dep. You have 2 options:
1) add it as a test dep
2) do what you've done and mock the component.
Thanks
-Vincent
2:16 p.m.
Hi Vincent,
2012/12/10 Vincent Massol <vincent(a)massol.net>
Hi Jeremie,
On Dec 10, 2012, at 1:22 PM, jerem <jeremie.bousquet(a)gmail.com> wrote:
I'd prefer not, but as I depend on old core I believe there's no
alternative ... Or there is ?
By the way I'd prefer not depend on old core but DAB was really too limited
for my needs. DAB is ok for very specific use, but for heavy modifications
on documents and XObjects api is a bit cumbersome. I wrote a component
extending DocumentAccessBridge for my own needs, trying to isolate old core
to very limited location in my code, but for now it's not "clean". At the
end I think I'll be able to remove AbstractBridgedComponentTestCase for my
tests completely.
Hi,
I could workaround that quite easily, by adding the following in my
setUp()
method, just before retrieving my class under
tests from the component
manager:
getComponentManager().registerMockComponent(getMockery(),
LoggerManager.class);
But it seems to confirm that, for any reason, the LoggerManager was not
automatically mocked by AbstractBridgedComponentTestCase.
This is an old/legacy class and you should try to not use it.
That said it extends AbstractComponentTestCase which will register in the
CM all annotated components it finds in the CP.
The only reason it wouldn't register one component is because it's not in
the CP. So either you don't have that dep voluntarily in your pom.xml
because it's a runtime dep. You have 2 options:
1) add it as a test dep
It's already in xwiki-commons-logging-api, brought by parent
xwiki-commons-pom, in scope compile...
When you mean not in CP, you mean the component interface (with @Role) or
any concrete implementation class ?
I tried to add both (xwiki-commons-logging-api and
xwiki-commons-logging-logback in scope test) with same result.
2) do what you've done and mock the component.
Yes I'll stick to that anyway, but I wanted to make sure it was not a
symptom of something bad somewhere.
Thanks
-Vincent
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
Thanks,
Jeremie
2:28 p.m.
On Dec 10, 2012, at 2:16 PM, Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com> wrote:
This just defines the LoggerManager interface, not a component implementation so nothing
will get registered in the CM.
DefaultLoggerManager is in xwki-commons-logging-logback…
Hi Vincent,
2012/12/10 Vincent Massol <vincent(a)massol.net>
Not really...
Create a specific bridge for your code so that all the rest of your code can use your
bridge interface and be easily tested.
Then what remains is just to test the bridge but this can be done in integration or
functional testing for example, or with AbstractBridgedComponentTestCase.
Hi Jeremie,
On Dec 10, 2012, at 1:22 PM, jerem <jeremie.bousquet(a)gmail.com> wrote:
I'd prefer not, but as I depend on old core I believe there's no
alternative ... Or there is ? Hi,
I could workaround that quite easily, by adding the following in my
setUp()
method, just before retrieving my class under
tests from the component
manager:
getComponentManager().registerMockComponent(getMockery(),
LoggerManager.class);
But it seems to confirm that, for any reason, the LoggerManager was not
automatically mocked by AbstractBridgedComponentTestCase.
This is an old/legacy class and you should try to not use it.
By the way I'd prefer not depend on old core but
DAB was really too limited
for my needs. DAB is ok for very specific use, but for heavy modifications
on documents and XObjects api is a bit cumbersome. I wrote a component
extending DocumentAccessBridge for my own needs, trying to isolate old core
to very limited location in my code, but for now it's not "clean". At the
end I think I'll be able to remove AbstractBridgedComponentTestCase for my
tests completely.
Yes, having your own Bridge is the best idea ATM.
That said it
extends AbstractComponentTestCase which will register in the
CM all annotated components it finds in the CP.
The only reason it wouldn't register one component is because it's not in
the CP. So either you don't have that dep voluntarily in your pom.xml
because it's a runtime dep. You have 2 options:
1) add it as a test dep
It's already in xwiki-commons-logging-api, brought by parent
xwiki-commons-pom, in scope compile...
When you mean not in CP, you mean the component interface (with @Role) or
any concrete implementation class ?
The way it works is that the Component annotation loader will scan the CP for
components.txt files and register all components it finds. xwiki-commons-logging-ap
doesn't bring a components.txt file with an implementation of LoggerManager...
I tried to add both (xwiki-commons-logging-api and
xwiki-commons-logging-logback in scope test) with same result.
xwiki-commons-logging-logback should work but maybe I don't understand your problem…
Thanks
-Vincent
2) do what
you've done and mock the component.
Yes I'll stick to that anyway, but I wanted to make sure it was not a
symptom of something bad somewhere.
>
> Thanks
> -Vincent
4522
days inactive
4523
days old
4 comments
3 participants
participants (3)
-
jerem -
Jeremie BOUSQUET
-
Vincent Massol