Add API-X to vagrant install #504
Comments
|
in progress |
I'll bug A. Birkland or Elliot M. in #fcrepo irc. |
|
Misspelling -- try You may also want to try using |
|
@acoburn good catch! I'll send a PR to their repo. |
|
@ruebot: just did: fcrepo4-labs/fcrepo-api-x#104 |
|
@acoburn thank you! |
* s/Salmon/Alpaca/g - Resolves Islandora/documentation#507 * Update various component versions to allow for API-X integration; Partially resolves Islandora/documentation#504 * code review check-in * more code review * one last thing
|
Lol, we gotta stop saying 'partially resolves' if there's more than one pull. Twice in one day. |
|
Oh shit. I put "resolves" in that commit message! |
|
Happened earlier with @bryjbrown today too. Sometimes github is too smart for its own good. |
|
Closed by accident due to 'resolved' being in a message. |
|
@ruebot I just created fcrepo4-labs/fcrepo-api-x#106 to describe the issue I'm running into with installing API-X. I'll have to circle back to this once it gets sorted out. |
|
@dannylamb Great! Let me know if you need a hand on my end. |
|
Looking at this again. When I did a ...and if I scroll up further: ...and a ...and finally, when I start the service again - |
|
That looks vaguely like a provisioning problem, like the |
|
Hi all, I've been on the road, and now don't have internet at the moment
except for my phone. Will try installing in Karaf by hand once I'm up and
running again.
One class of messages (looking for container, adding, etc) are due to API-X
being unable to contact Fedora. It just infinitely tries to verify that
various registry containers are present. If you start API-X in isolation,
it will keep doing this until you start Fedora.
As far as the OSGi provisioning, that is an unfamiliar error. The Karaf
feature file declares fcrepo-service-activemq and fcrepo-camel as
dependencies. I would think that camel-jms would simply be pulled in
transitively. The Dockerfile used to create the docker image does nothing
more than feature:install fcrepo-api-x, and works.
Once I get internet, I'll try to see if the errors you've been seeing can
be reproduced.
…On Apr 24, 2017 5:42 PM, "A. Soroka" ***@***.***> wrote:
Pinging @emetsger <https://github.com/emetsger> and @birkland
<https://github.com/birkland> on this-- before I launch into it, does
this look familiar at all? Any thoughts?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#504 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAfm-bAR_T1U3T-EGB0zmL_3L4wTffQdks5rzRdLgaJpZM4LrlIo>
.
|
|
@ruebot You didn't end up with a branch for this, right? You were just working off of a clean |
|
The issue I have is less about the broker being inside Karaf and more about using |
|
@whikloj Seems like that is relevant here though, eh? Because camel-toolbox will be in the same position of trying to use a |
|
@ajs6f nope, no branch on this since islandora-deprecated/claw_vagrant@8eb5513 -- I was just testing on a master build a while back and trying to implement what @acoburn recommended in the API-X ticket. |
|
@ajs6f I agree but this could also be relative amateurish work in OSGI that is causing the problems. But if I figure out something, I will definitely report back. |
|
After a good bit of tinkering about today, most of which was really just me learning This hypothesis does have the advantage of predicting that (as happened) @birkland would be able to start API-X cleanly in a non-CLAW env, but that I (in |
|
Hi @ajs6f , Ah, I see. API-X needs to be able to bootstrap and maintain itself (i.e. create containers in the repository for registries, persist extension definitions, ontologies, etc). If CLAW's repo is locked down, then API-X would need to be configured with credentials in order to maintain the data it needs to. So far, we haven't needed to do that. I think some of the API-X blueprint files would need to be updated in order to make that possible. fcrepo-api-x-jena/LdpContainerRegistry is the base impl that does such writing. It has an HttpClient injected here. That's a service reference from the bundle's blueprint file. The blueprint file from fcrepo-api-x-registry exports an HttpClient as a service, but unfortunately it isn't configured for authentication. One approach to adding auth would be to configure the client exported in fcrepo-api-x-registry to authenticate with the appropriate credentials to the desired realm (i.e the Fedora instance, at whatever host it's at). That would require updating the one blueprint file. Another approach might be to not import an HttpClient as a service reference in fcrepo-api-x-jena, and just build a new one there in its blueprint file; adding the appropriate config properties to add credentials when auth is desired. I'm not sure which approach is best... |
|
If it's possible for CLAW to publish its own in Alpaca, then that's probably the least invasive way to do it. Api-X can provide a default that we just would supplant with our own. As far as getting that token, we could provide a static one for Api-X or find some other way to get it by giving Api-X a Drupal user/pass and using that to get a token. |
|
From experience with exactly this problem in Jena, I think it's better long-term to treat with actual clients, rather than try to think of every possible option or weirdness that people might want to inflict on HTTP. But in additional to |
|
Sounds like the immediate short-term fix for CLAW is to set the right config in blueprint using Vagrant setup scripts or the like. For the long term, API-X can decide on a pattern and CLAW can adjust to match. That sound good? |
|
Sounds good to me. I need to better understand the Auth setup CLAW uses, buy would be happy to implement whatever it takes on the API-X end to make it straightforward! |
|
@birkland, Based on some cursory looks, it appears that separating the blueprint from the code would let us provide our own config and therefore http client. Or we can take the one that's declared as a service in api-x, give it a jndi name, and then make the bean refs that look for it accept a configurable jndi name. In Alpaca, CLAW can just provide its own bundle that exports an http client as another name and just update configuration to pull in the right one from jndi. I think that'd be the least invasive option. I can help out with that right after I wrap up #597, which should be soon. |
|
All of those ideas sound good, and if I'm not mistaken, there is an additional possibility that comes from OSGi: using OSGi Services to provide a properly-configured client Karaf-wide (like JNDI, but OSGi-specific with some extra flavor). Blueprint can use a service ranking to select from various clients on offer. |
|
Now that I examine JWT a bit more, it's not clear to me that a simple client will do the job. Is it not the case that a series of interactions must take place between client and server to start an authenticated conversation? We may need to look at |
|
I was taking a look at it yesterday - having no prior familiarity with JWT. It looks to me like there needs to be an exchange that ultimately results the client getting a token that it can then use in requests to Fedora. It's unclear to me if that token expires, or otherwise needs to be messed with once it's obtained. In any case, it looks like we'd need to have a service which performs that interaction, then publishes a pre-configured HTTPClient to the OSGi service registry. That HTTPClient may have to be a façade or proxy to hide token re-negotiation logic that may have to occur from time time, if necessary. I think this is what @dannylamb was referring to by "a bundle that exports an http client as another name" If that's the case, then the modification API-X needs is a configuration param for the identity/name of the httpclient. |
|
+1 to API-X having such a config-- that would be useful far beyond this ticket. |
|
All right, I'll get on it! |
|
For the JWT case, I suspect that we might be able to use interceptors to deal with the pattern, a la https://hc.apache.org/httpcomponents-client-4.2.x/httpclient/examples/org/apache/http/examples/client/ClientGZipContentCompression.java |
|
So we haven't tried it yet, but the drupal module we're using for JWT auth provides an endpoint to request a token using your drupal user/pass. That's the exchange that would have to take place. So we'll need to make an API-X user for CLAW and give it a user/pass (or just let it run as admin for now), use that to get the token, and then jam that token in as an Authorization header for every request that gets sent out during bootstrapping. And yes, that token can expire, so care may have to be taken there. I don't have a ton of experience using the Apache HTTP client, so I'm not sure what the best way to force that header is. Either way, I'm going to play around with the drupal module to see if I can enable that endpoint and see how it behaves. |
|
@dannylamb I think we can use the interceptors I mention above for the kind of pattern you are describing. We'd have a stateful request interceptor which would check to see if it has a token in hand, and if not, request one, presumably using the same "wrapped" client. In either case, it then adds the token to the header appropriately. I don't think we would need a response interceptor... |
|
@birkland We've got a PR ^^^ for when you're ready to try injecting the client. |
|
@ajs6f Great, thanks. I'm aiming for an API-X PR this afternoon |
|
"What do you implement content services in?" |
Installation instructions are outlined here: https://github.com/fcrepo4-labs/fcrepo-api-x.
tl;dr Run this from the karaf client and see what breaks.
The text was updated successfully, but these errors were encountered: