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. > > > > > > 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. 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. Cheers, Danny.
