Es begab sich aber da Christiaan Fluit zur rechten Zeit 30.10.2006
11:44 folgendes schrieb:
About the OSGI thing:
The RDF2GoRDFContainer itself. If the user doesn't provide a model - it
creates a default ModelImplSesame model. I did some searching around the
code. The only place within core architecture classes those constructors
are used is the RDF2GoRDFContainer factory. The factory itself is used
in other parts of the code but no class creates it. If removing this
dependency is a concern, I would suggest a following solution.
We are not using this factory in Aduna code, I'm not sure about others.
The whole idea about all those factories and registries everywhere is to
support a dynamic system based on e.g. OSGi where there are as little
assumptions as possible about which implementation classes are used, in
which order things are initialized and even make runtime changes to the
As we still make little use of this architecture, perhaps remove it for
now and introduce a better version as soon as we fully know/agree on
what "better" means?
one of the next tasks on DFKI side will be to wrap Aperture into a
Nepomuk interface for datawrappers,
and to bundle it as OSGI service using the Eclipse plugin concept, with
There will also be a service then running, with configuration etc.
Anyone has experience how to handle configuration the "right way" in
I am not concerned about the factories, but more on:
A) where to store config values (file, database, config file inside the
B) how to change config values (through interface, is there a
C) how to make a gui that uses B to change A
D) how to make an activator that reads A, perhaps through B?
E) or is it all dependent on a "service" bundle, that wrapps another
bundle and provides A,B,C,D for application environment X where it
runs. For example, one for Nepomuk, one for Autofocus
1. Have RDF2GoRDFContainer accept a Model from outside. Don't provide
any default implementation.
2. Ask Benjamin to create a ModelImplSesameFactory. (I'm actually
surprised it isn't there).
3. Create a constructor for RDF2GoRDFContainerFactory that accepts an
instance of the ModelFactory interface. (it is possible since as I said
no aperture class creates instances of RDFContainerFactory, and the
DEFAULT_FACTORY static field is never used in aperture).
4. Use the ModelFactory in newInstance and and getRDFContainer
5. Remove the DEFAULT_FACTORY field.
The typical OSGi-like setup that we use is to let the factory (in this
case the RDF2GORDFContainerFactory) have all configuration info stored
in its attributes. It gets this info through set methods that are
invoked by whoever creates these factories (static code, an OSGi
BundleActivator, some configuration file setup mechanism, etc).
This way the invocation of the factory's get/createNew/whatever method
is often parameterless. This ensures that future API changes have as few
consequences as possible and that configuration code needed by a
specific factory are only reflected by the set/get methods of that
factory, not by the artifact-producing methods.
Leo is right that a malformed URI is usually an indication of a bug on
our side that should be found and removed.
I'm comfortable with URI checking as long as it's optional. With this I
don't mean that it should depend on a log level whether checks are done
or not, but that the API should be constructed in such a way that a
developer can choose whether to use a safe and sound approach or play it
dirty. A method to explicitly check URIs is an example of such an
approach, as is for example org.openrdf.model's approach where you can
easily introduce your own URI implementation transparently, that does as
much or as little checking as you want.
> RepositoryAccessData - replaced by ModelAccessData
Since rdf2go doesn't support contexts directly it would be up to the
user of ModelAccessData, to provide a model implementation that would
use an appropriate context (if necessary)
Perhaps leave this class out altogether and reserve some time in the
future to revisit the AccessData API altogether?
Given recent work on the crawler implementations I really had the
feeling that we would benefit from being able to use RDF to store access
data. Of course AccessData can also have a getModel method but I think
we should consider whether we really need an AccessData on top of a
model or instead give it such a model directly. IMO AccessData does not
provide an added value over an RDF Model in the way RDFContainer does.
All in all: good work!
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Aperture-devel mailing list
DI Leo Sauermann http://www.dfki.de/~sauermann
P.O. Box 2080 Fon: +49 631 205-3503
67608 Kaiserslautern Fax: +49 631 205-3472
Germany Mail: firstname.lastname@example.org