You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@marmotta.apache.org by Sergio Fernández <wi...@apache.org> on 2014/05/26 09:57:48 UTC
Re: [GSoC] dev period
Hi,
On 24/05/14 05:02, Qihong Lin wrote:
> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
> resource. The unit test has been made as well.
> Please check my last 2 commits:
> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
Great. I reviewed and commented directly there.
> However, the unit test seems to be ugly. You can see in
> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
> object of LdpServiceSPARQLImpl. Is there other more elegant way to
> test LdpServiceSPARQLImpl?
> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
> ConfigurationService and ldpContext. How can I make the unit test by
> injecting them into LdpServiceSPARQLImpl?
You can get services from the EmbeddedMarmotta, see this example:
https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39
But for preventing random behaviors, since now you have two
implementations of the LdpService, you have to take a look how to have
alternatives with CDI and get the right one:
http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: [GSoC] dev period
Posted by Sergio Fernández <se...@salzburgresearch.at>.
Hi Qihong Lin,
On 20/06/14 11:51, Qihong Lin wrote:
> The wiki is very helpful. Thanks!
> I'll code following the restrictions. I think the best way to make it,
> is to study LdpServiceImpl and provide the corresponding identical
> methods for LdpServiceSPARQLImpl, because LdpServiceImpl is supposed
> to be strictly stick to the restrictions, isn't it?
>
> I just made 2 commits [1] of the methods of addResource() and
> deleteResource(), with the unit tests [2]. As is promised in the
> project plan, you can assess both the reading and writing capabilities
> of LDP-RS in the mid-term evaluation.
>
> Until the mid-term evaluation, I think things are going well at my
> side. I'll complete the rest of the implementations of the methods. I
> appreciate your help very much.
This week I'll take a closer code to your work for the mid-term
evaluation, and I'll come back to you with more concrete details. But I
think the project is going in the right direction.
Please, take into account that the official LDP Test Suite has
significantly evolved in the last week, and it can be a very useful
resource for you:
http://w3c.github.io/ldp-testsuite
Cheers,
--
Sergio Fernández
Senior Researcher
Knowledge and Media Technologies
Salzburg Research Forschungsgesellschaft mbH
Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
T: +43 662 2288 318 | M: +43 660 2747 925
sergio.fernandez@salzburgresearch.at
http://www.salzburgresearch.at
Re: [GSoC] dev period
Posted by Qihong Lin <co...@gmail.com>.
Hi Sergio,
The wiki is very helpful. Thanks!
I'll code following the restrictions. I think the best way to make it,
is to study LdpServiceImpl and provide the corresponding identical
methods for LdpServiceSPARQLImpl, because LdpServiceImpl is supposed
to be strictly stick to the restrictions, isn't it?
I just made 2 commits [1] of the methods of addResource() and
deleteResource(), with the unit tests [2]. As is promised in the
project plan, you can assess both the reading and writing capabilities
of LDP-RS in the mid-term evaluation.
Until the mid-term evaluation, I think things are going well at my
side. I'll complete the rest of the implementations of the methods. I
appreciate your help very much.
Cheers,
Qihong Lin
[1] https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
[2] https://github.com/confidencesun/marmotta/blob/926ae5de17d8c414184c0051f688101adf17003e/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
On Wed, Jun 11, 2014 at 6:50 AM, Sergio Fernández <wi...@apache.org> wrote:
> Dear Qihong Lin,
>
> apologize for the late reply.
>
>
> On 10/06/14 13:38, Qihong Lin wrote:
>>
>> Dear Sergio,
>>
>> I just figured out the reason of the problem 1). The bean.xml was not
>> copied into the building output folder, although was in the source
>> folder. I fixed it in eclipse. Everything works well now.
>
>
> Great, so the issue was actually in your IDE. Please, verify it does not
> appear on a regular build environment (raw maven).
>
>
>> Could you please just help me with the problem 2)? Thanks a lot!
>
>
> Remember that the scope of your project is restricted to the internals of
> Marmotta. All related with HTTP (headers and so on) are handled by the web
> service, where any of the two service implementations can be plug-in.
>
> For the second part of your question, that's an internal decision of
> Marmotta. The storage layer is out of the scope of the LDP spec. More
> precisely, LDP Marmotta storage is implemented by:
>
> * Using <http://www.w3.org/ns/ldp#> as "management" context, where store
> some management data
> * Internally every LDP-R will be stored in its own context
>
> Further details about our implementation restrictions are available from the
> wiki:
>
> http://wiki.apache.org/marmotta/LDPImplementationReport#Implementation_Restrictions
>
> Thanks for binging here that questions. Finding out those details means that
> you are in the right path for developing your project.
>
> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 660 2747 925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
Re: [GSoC] dev period
Posted by Sergio Fernández <wi...@apache.org>.
Dear Qihong Lin,
apologize for the late reply.
On 10/06/14 13:38, Qihong Lin wrote:
> Dear Sergio,
>
> I just figured out the reason of the problem 1). The bean.xml was not
> copied into the building output folder, although was in the source
> folder. I fixed it in eclipse. Everything works well now.
Great, so the issue was actually in your IDE. Please, verify it does not
appear on a regular build environment (raw maven).
> Could you please just help me with the problem 2)? Thanks a lot!
Remember that the scope of your project is restricted to the internals
of Marmotta. All related with HTTP (headers and so on) are handled by
the web service, where any of the two service implementations can be
plug-in.
For the second part of your question, that's an internal decision of
Marmotta. The storage layer is out of the scope of the LDP spec. More
precisely, LDP Marmotta storage is implemented by:
* Using <http://www.w3.org/ns/ldp#> as "management" context, where store
some management data
* Internally every LDP-R will be stored in its own context
Further details about our implementation restrictions are available from
the wiki:
http://wiki.apache.org/marmotta/LDPImplementationReport#Implementation_Restrictions
Thanks for binging here that questions. Finding out those details means
that you are in the right path for developing your project.
Cheers,
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 660 2747 925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: [GSoC] dev period
Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,
I just figured out the reason of the problem 1). The bean.xml was not
copied into the building output folder, although was in the source
folder. I fixed it in eclipse. Everything works well now.
Could you please just help me with the problem 2)? Thanks a lot!
Yours,
Qihong Lin
On Tue, Jun 3, 2014 at 8:46 PM, Qihong Lin <co...@gmail.com> wrote:
> Dear Sergio,
>
> I try to fix the problems you commented. The code have been just committed [1].
>
> But there're some further issues to discuss:
>
> 1) EmbeddedMarmotta
> I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
> is added at "src\test\resources\META-INF". But it throws
> "DeploymentException: WELD-001408" (see Apendix (1): stack trace for
> running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
> in marmotta-core also throws "UnsatisfiedResolutionException:
> WELD-001308" at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
> EmbeddedMarmotta itself have some problems? Or am I wrong for any
> configuration mistakes of weld CDI? Finally, I have to restore the
> code to the ugly "new LdpServiceSPARQLImpl()" approach for testing.
>
> 2) RDF resource VS. LDP-RS
> I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
> But it seems that most of the rules are out of the scopes of my SPARQL
> implementation work. For example, the rules like "HTTP Link header"
> and "HTTP Request-URI" for LDP-RS are not concerned in the level of my
> work. Is that correct?
> I try to make the equivalent method for LdpServiceImpl.exists(), which
> has only one sentence:
> "return connection.hasStatement(resource, null, null, true, ldpContext);"
> It uses "ldpContext" pointing to "http://www.w3.org/ns/ldp#", which is
> a graph name in the triplestore. Does it mean all of the LDP-RSs must
> be in the graph of "http://www.w3.org/ns/ldp#"? I don't see this
> request in the W3C LDP documentation[3]. What's your opinion?
> It uses "true" for the 4th parameter of connection.hasStatement()
> method, which includes inferred ones during querying. But I see this
> in the W3C LDP documenation [3]:
> "4.3.1.10 LDP servers must not require LDP clients to implement
> inferencing in order to recognize the subset of content defined by LDP
> ... The practical implication is that all content defined by LDP must
> be explicitly represented, unless noted otherwise within this
> document."
> Therefore, shall we change it to "false" to avoid inferred triples?
> Further more, should I care about SPARQL Entailment Regimes [4]? No?
>
> Best regards,
> Qihong Lin
>
>
> [1] https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
> [2] https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
> [3] http://www.w3.org/TR/ldp/#ldprs
> [4] http://www.w3.org/TR/sparql11-entailment/
>
> Appendix (1): stack trace for running LdpServiceSPARQLImplTest
> org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
> at injection point [BackedAnnotatedField] @Inject protected
> org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
> at org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
> at org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService(LdpServiceImpl.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService
> at org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService(LdpWebService.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Exception 0 :
> org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ConfigurationService with qualifiers
> @Default
> at injection point [BackedAnnotatedField] @Inject private
> org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService
> at org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService(LdpBinaryStoreServiceImpl.java:0)
>
> at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
> at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
> at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
> at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
> at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:76)
> at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:475)
> at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:392)
> at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:85)
> at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:66)
> at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
> at org.apache.marmotta.platform.ldp.testsuite.LdpServiceSPARQLImplTest.before(LdpServiceSPARQLImplTest.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
> Appendix (2): stack trace for running EmbeddedMarmottaTest
> org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308:
> Unable to resolve any beans for Types: [class
> org.apache.marmotta.platform.core.startup.MarmottaStartupService];
> Bindings: [QualifierInstance{annotationClass=interface
> javax.enterprise.inject.Any, values={}, hashCode=1250708224}]
> at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:815)
> at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:75)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.getService(AbstractMarmotta.java:92)
> at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:88)
> at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
> at org.apache.marmotta.platform.core.test.embedded.EmbeddedMarmottaTest.testMarmottaStartup(EmbeddedMarmottaTest.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
>
> On Mon, May 26, 2014 at 3:57 PM, Sergio Fernández <wi...@apache.org> wrote:
>> Hi,
>>
>> On 24/05/14 05:02, Qihong Lin wrote:
>>>
>>> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
>>> resource. The unit test has been made as well.
>>> Please check my last 2 commits:
>>> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
>>
>>
>> Great. I reviewed and commented directly there.
>>
>>> However, the unit test seems to be ugly. You can see in
>>> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
>>> object of LdpServiceSPARQLImpl. Is there other more elegant way to
>>> test LdpServiceSPARQLImpl?
>>> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
>>> ConfigurationService and ldpContext. How can I make the unit test by
>>> injecting them into LdpServiceSPARQLImpl?
>>
>>
>> You can get services from the EmbeddedMarmotta, see this example:
>>
>> https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39
>>
>> But for preventing random behaviors, since now you have two implementations
>> of the LdpService, you have to take a look how to have alternatives with CDI
>> and get the right one:
>>
>> http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives
>>
>> Cheers,
>>
>> --
>> Sergio Fernández
>> Senior Researcher
>> Knowledge and Media Technologies
>> Salzburg Research Forschungsgesellschaft mbH
>> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
>> T: +43 662 2288 318 | M: +43 660 2747 925
>> sergio.fernandez@salzburgresearch.at
>> http://www.salzburgresearch.at
Re: [GSoC] dev period
Posted by Qihong Lin <co...@gmail.com>.
Dear Sergio,
I try to fix the problems you commented. The code have been just committed [1].
But there're some further issues to discuss:
1) EmbeddedMarmotta
I change the test case [2] to use EmbeddedMarmotta. The bean.xml file
is added at "src\test\resources\META-INF". But it throws
"DeploymentException: WELD-001408" (see Apendix (1): stack trace for
running LdpServiceSPARQLImplTest). In addition , EmbeddedMarmottaTest
in marmotta-core also throws "UnsatisfiedResolutionException:
WELD-001308" at my side (Eclipse+egit+m2e, see Appendix (2) ). Does
EmbeddedMarmotta itself have some problems? Or am I wrong for any
configuration mistakes of weld CDI? Finally, I have to restore the
code to the ugly "new LdpServiceSPARQLImpl()" approach for testing.
2) RDF resource VS. LDP-RS
I read the W3C LDP documentation[3]. There're some rules for LDP-RS.
But it seems that most of the rules are out of the scopes of my SPARQL
implementation work. For example, the rules like "HTTP Link header"
and "HTTP Request-URI" for LDP-RS are not concerned in the level of my
work. Is that correct?
I try to make the equivalent method for LdpServiceImpl.exists(), which
has only one sentence:
"return connection.hasStatement(resource, null, null, true, ldpContext);"
It uses "ldpContext" pointing to "http://www.w3.org/ns/ldp#", which is
a graph name in the triplestore. Does it mean all of the LDP-RSs must
be in the graph of "http://www.w3.org/ns/ldp#"? I don't see this
request in the W3C LDP documentation[3]. What's your opinion?
It uses "true" for the 4th parameter of connection.hasStatement()
method, which includes inferred ones during querying. But I see this
in the W3C LDP documenation [3]:
"4.3.1.10 LDP servers must not require LDP clients to implement
inferencing in order to recognize the subset of content defined by LDP
... The practical implication is that all content defined by LDP must
be explicitly represented, unless noted otherwise within this
document."
Therefore, shall we change it to "false" to avoid inferred triples?
Further more, should I care about SPARQL Entailment Regimes [4]? No?
Best regards,
Qihong Lin
[1] https://github.com/confidencesun/marmotta/commit/d8e8048931de8a5f92c90ebf6a728822a2d3ed74
[2] https://github.com/confidencesun/marmotta/blob/d8e8048931de8a5f92c90ebf6a728822a2d3ed74/platform/marmotta-ldp/src/test/java/org/apache/marmotta/platform/ldp/testsuite/LdpServiceSPARQLImplTest.java
[3] http://www.w3.org/TR/ldp/#ldprs
[4] http://www.w3.org/TR/sparql11-entailment/
Appendix (1): stack trace for running LdpServiceSPARQLImplTest
org.jboss.weld.exceptions.DeploymentException: Exception List with 4 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
at injection point [BackedAnnotatedField] @Inject protected
org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService
at org.apache.marmotta.platform.core.logging.BaseLoggingModule.configurationService(BaseLoggingModule.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService
at org.apache.marmotta.platform.ldp.services.LdpServiceImpl.configurationService(LdpServiceImpl.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService
at org.apache.marmotta.platform.ldp.webservices.LdpWebService.configurationService(LdpWebService.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ConfigurationService with qualifiers
@Default
at injection point [BackedAnnotatedField] @Inject private
org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService
at org.apache.marmotta.platform.ldp.services.LdpBinaryStoreServiceImpl.configurationService(LdpBinaryStoreServiceImpl.java:0)
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:368)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:289)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:135)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:166)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:514)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
at org.jboss.weld.bootstrap.ConcurrentValidator.validateBeans(ConcurrentValidator.java:76)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:475)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:392)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:85)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:66)
at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
at org.apache.marmotta.platform.ldp.testsuite.LdpServiceSPARQLImplTest.before(LdpServiceSPARQLImplTest.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Appendix (2): stack trace for running EmbeddedMarmottaTest
org.jboss.weld.exceptions.UnsatisfiedResolutionException: WELD-001308:
Unable to resolve any beans for Types: [class
org.apache.marmotta.platform.core.startup.MarmottaStartupService];
Bindings: [QualifierInstance{annotationClass=interface
javax.enterprise.inject.Any, values={}, hashCode=1250708224}]
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:815)
at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:75)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.getService(AbstractMarmotta.java:92)
at org.apache.marmotta.platform.core.test.base.AbstractMarmotta.<init>(AbstractMarmotta.java:88)
at org.apache.marmotta.platform.core.test.base.EmbeddedMarmotta.<init>(EmbeddedMarmotta.java:35)
at org.apache.marmotta.platform.core.test.embedded.EmbeddedMarmottaTest.testMarmottaStartup(EmbeddedMarmottaTest.java:34)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
On Mon, May 26, 2014 at 3:57 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hi,
>
> On 24/05/14 05:02, Qihong Lin wrote:
>>
>> I've completed the code of LdpServiceSPARQLImpl.exist() for RDF
>> resource. The unit test has been made as well.
>> Please check my last 2 commits:
>> https://github.com/confidencesun/marmotta/commits/MARMOTTA-444
>
>
> Great. I reviewed and commented directly there.
>
>> However, the unit test seems to be ugly. You can see in
>> LdpServiceSPARQLImplTest.testResourceExist() that I directly new the
>> object of LdpServiceSPARQLImpl. Is there other more elegant way to
>> test LdpServiceSPARQLImpl?
>> Also, I find that LdpServiceSPARQLImpl uses LdpBinaryStoreService,
>> ConfigurationService and ldpContext. How can I make the unit test by
>> injecting them into LdpServiceSPARQLImpl?
>
>
> You can get services from the EmbeddedMarmotta, see this example:
>
> https://github.com/confidencesun/marmotta/blob/MARMOTTA-444/platform/marmotta-core/src/test/java/org/apache/marmotta/platform/core/test/prefix/PrefixServiceTest.java#L39
>
> But for preventing random behaviors, since now you have two implementations
> of the LdpService, you have to take a look how to have alternatives with CDI
> and get the right one:
>
> http://docs.jboss.org/weld/reference/latest/en-US/html_single/#alternatives
>
> Cheers,
>
> --
> Sergio Fernández
> Senior Researcher
> Knowledge and Media Technologies
> Salzburg Research Forschungsgesellschaft mbH
> Jakob-Haringer-Straße 5/3 | 5020 Salzburg, Austria
> T: +43 662 2288 318 | M: +43 660 2747 925
> sergio.fernandez@salzburgresearch.at
> http://www.salzburgresearch.at