Resource files deletion

[API-Evangelist]

Hello Team,

We are trying to delete java resources files via management API but however post deletion we still see under

/u01/app/apigee/var/log/edge-message-processor/work/o/test/e/dev/java folder.

It is causing inconsistent behavior in the system.(we have a java callout which references to java artifacts- keystore/properties) it is referring to old files and causing inconsistency..

Is there a way to remove the entries from above path and avoid from referring?

Thankyou

[dchiesa1]

Is there a way to remove the entries from above path and avoid from referring?

I think I understand your question. Here's my attempt at an answer.

Resource files can be stored and managed within Apigee Edge at multiple different levels, or scopes.

• the API Proxy revision
• the environment
• the organization

In all cases there is a management API that allows you to GET, POST, PUT, DELETE those resources. This corresponds to Read, Create, Update, Delete semantics. You can read the reference documentation for the APIs here.

You didn't say which scope you're using to store the resource files. Some examples follow.

scope	root URL for resourcefiles
API Proxy revision	hxxp://mgmtserver/v1/o/$ORG/apis/$APINAME/revisions/$REV/resourcefiles
environment	mgmtserver / v1/ o/ ORG/ e/ ENV/ resourcefiles
organization	hxxp://mgmtserver/v1/o/$ORG/resourcefiles

To that root, you must append two additional path elements, one for the resourcefile type, and the other for the resourcefile name. So for a jar resource named library-1.0.0.jar, scoped to the environment you would use a URL of

/v1/ o/ $ORG/ e/ $ENV/ resourcefiles/ java/ library-1.0.0.jar

a delete is simply

curl -i -n -X DELETE \ 
  $MGMTSERVER/ v1/ o/ $ORG/ e/ $ENV/ resourcefiles/ java/ library-1.0.0.jar

---

A note on resource files scoped to proxy revision.

I will be honest: I don't like the revision mechanism in the management API for Apigee Edge, for a couple reasons: It applies only to API proxy bundles, no other entities. And Revisions are mutable. !!

An implication of the latter: Apigee Edge doesn't always propagate a change to an API-proxy-scoped resourcefile to the API proxy if it is already deployed. This is A Very Bad Thing.

So, while there is an API to delete or add resources to a specific API proxy revision, I don't advise using it. Instead, just upload (import) a completely new revision of the API Proxy, and deploy THAT.

[API-Evangelist]

Thankyou Dino for the detail.

We went thru all the documentation and all possibilities but it is something the way resources load is possible issue.

Here is my frustration & we hate to use java callout now with so inconsistencies :(may be we are doing differently or the way the edge works that way..will leave it community to express any feedback).

We have a simple java callout for sign message and send to partner endpoint.

With in java callout we use propertiesFile where it refers to eg : api.properties

where api.properties

==

org.apache.wss4j.crypto.provider = org.apache.wss4j.common.crypto.Merlin

org.apache.wss4j.crypto.merlin.keystore.file = sign.jks

org.apache.wss4j.crypto.merlin.keystore.password = xxxx

org.apache.wss4j.crypto.merlin.keystore.type = jks

org.apache.wss4j.crypto.merlin.keystore.alias = test

org.apache.wss4j.crypto.merlin.keystore.private.password = xxxx

==

At env level we jar the api.properties file say apinewproperties.jar and similarly we jar signnewkeystore.jar with sign.jks and upload as a java resource.

Here is the issue :

Say we have an existing jar eg: apioldproperties.jar with api.properties file as well as signoldkeystore.jar with sign.jks file with in resources.

==

Reason we are re-doing this is because the certs are expiring we need to upload new properties and .jks file with new set of keys.

==

Now when we run the api proxy when it reaches the java callout intermittently it looks for api.properties file and try referencing from java resources what we are observing it is looking into old properties/jks reference instead of new properties/jks file.

triage ->

1.We did recycle the mps to see to close any any connections/cache -> didn't help

2.Deleted the old reference properties and jks from env (proxy was not happy as it was looking for properties file).

3.Added new properties and removed old and recycle via management api -> didn't help

Even after deleting we observe the old files at $MGMTSERVER/ v1/ o/ $ORG/ e/ $ENV/ resourcefiles/ java/

Again the issue is it does works on node1 once and fails on node1 next..-> not specific to any mp.

Finally with no option left as it was impacting the clients we have to modify the java callout to use a different properties file name (say newapi.properties) and re-jar the properties and upload to java resources.

Currently moved to old revision to avoid the impact and working on a different revision to continue triaging (some thing related to mutual auth)...

case # 1468871 for reference and if you could look at the proxy/debug logs/trace logs/snapshots etc..

Thanks.

[API-Evangelist]

@Dino-at-Google:

Did you get a chance to take a look?

[dchiesa1]

I haven't looked at your specific case. The support engineers are handling that one so, I'll let them investigate and resolve it. They can bring me in if necessary.

[API-Evangelist]

@Dino:

There is a internal bug opened but not sure about the progress..can you please take a look as we are looking for work around at-least to proceed(This is critical for us). Easy to replicate at will. kindly help.