On Wed, Aug 27, 2014 at 12:15 PM, Danny Ayers <[email protected]> wrote:
> On 27 August 2014 09:41, Reto Gmür <[email protected]> wrote: > > > On Tue, Aug 26, 2014 at 6:07 PM, Danny Ayers <[email protected]> > > wrote: > > > > > > > > http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html > > > > > > but I'm still getting the 401 challenge, so I guess I'll try doing the > > > regular two-step auth. > > > > I think I'm now making progress there... > > > > > > > > > > But if you're application is running in OSGi you definitively > shouldn't > > > do > > > > this. You don't want to have to configure your app to store the > > password > > > of > > > > the instance it is running on (and need to reconfigure it, wehn the > > > > password is changed). > > > > > > > > > Hmm, I see your point, but what if an account is set up, reserved for > the > > > app, on install, wouldn't that be feasible? > > > > > Well you app could set up an account for its own access. It would still > > need to store the (random) password it set for its user on disk, which is > > not ideal but certainly better than requiring the user to provide the > > password. > > > > Right. I reckon for now I'll go this route. In fact until I've got the > thing running integrated, I'll just use the default admin/admin. Can look > at improving things later. > As I wrote, having the component taking care of accessing the triple store by being individually configured to use a sparql endpoint is nonsense in my opinion. Using a hardcoded default password even more. > > > > > > > > > > I would prefer keeping the comms as much as possible still over HTTP > > rather > > > than OSGi, more potential for distributed systems. > > > > > > > Interesting. Did you have a look at DOSGi? > > > I hadn't, very interesting. > > > > Currently what I've been using > > it to separate the triple store from the OSGi instance by using the > > clerezza virtuoso binding. You are thinking of each bundle having a > > different Triple store configured as Sparql HTTP endpoind? > > > Potentially going even farther than that, so the data could go to a totally > remote SPARQL store. What do you mean by totally remote? A Sparql enpoint accessed via HTTP is remote by default. > I can't think of a use case for that in itself, though > there may be situations when it'd be useful to go to an external proxy, set > up so that both the local store and a remote one have copies of the data. > (The remote could take the query-for-display workload). > > > > This might be a > > usecase for having TcManager provided by a service factory, this way it > > would be possible to have another instance of TcManager depending on the > > bundle requesting it. This would be transparent for the bundles, because > I > > think it really shouldn't be necessary for service implementors to care > > about the backend. On the other hand there should be a unified interface > > for the administrator to manage this distributed system. > > > > That does sounds like it might be useful...but also quite a lot of work. > Another use case or two would probably be desirable. > > fyi, this integration is proving an uphill struggle! (mostly due to my > inexperience with OSGi & Stanbol). There are only 4 aspects that I need to > do for minimal integration : > * load files from bundles (templates etc) - basically done, though I have > just run into an error that's probably just a typo in the path somewhere... > * HTTP SPARQL access - I think I'm slowly getting there > * serve UI - at minimum the UI is just 3 static HTML pages (containing > Ajaxy Javascript addressing the SPARQL endpoint). I've only have a quick go > at serving the pages inside Stanbol, something in my jax-rs isn't quite > right, probably got my paths wrong somewhere there too > * service control UI - at minimum just buttons for start/stop of the > feedreader and linkexplorer (the discovery bit) thread. I guess ideally > this should be integrated with the Felix Web Console, but if I get really > stuck on that there's always the possibility of a short-term workaround by > using the SPARQL store as a message whiteboard, between the Ajaxy client > and the server-side code. > Are you using any clerezza features? If you just need the SPARQl endpoint it might be more straight forward to have a separate application in its own OSGi container. Cheers, Reto
