Web / Rest Api to get java dependency metadata - rest

I'm looking for some REST Api that provides metada information about java libraries.
My goal is to automate 3rd party dependencies approval process.
I need following metadata about java jars:
Licence
Copyright
Home page url
Official repository url (this part is not required)
I was looking into Sonatype RepoManager Rest but it doesn't return such information
GET /service/rest/v1/components/{id}
{
"id" : "bWF2ZW4tY2VudHJhbDo4ODQ5MWNkMWQxODVkZDEzNjYwYmUwMjE1MjI2NGUwZQ",
"repository" : "maven-central",
"format" : "maven2",
"group" : "org.apache.httpcomponents",
"name" : "httpcomponents-client",
"version" : "4.3.5",
"assets" : [ {
"downloadUrl" : "http://localhost:8081/repository/maven-central/org/apache/httpcomponents/httpcomponents-client/4.3.5/httpcomponents-client-4.3.5.pom",
"path" : "org/apache/httpcomponents/httpcomponents-client/4.3.5/httpcomponents-client-4.3.5.pom",
"id" : "bWF2ZW4tY2VudHJhbDozZjVjYWUwMTc2MDIzM2I2YTFhOGUxOGQxZmFkOGM3Mw",
"repository" : "maven-central",
"format" : "maven2",
"checksum" : {
"sha1" : "95d80a44673358a5dcbcc2f510770b9f93fe5eba",
"md5" : "f4769c4e60799ede664414c26c6c5c9d"
}
}, {
"downloadUrl" : "http://localhost:8081/repository/maven-central/org/apache/httpcomponents/httpcomponents-client/4.3.5/httpcomponents-client-4.3.5.pom.sha1",
"path" : "org/apache/httpcomponents/httpcomponents-client/4.3.5/httpcomponents-client-4.3.5.pom.sha1",
"id" : "bWF2ZW4tY2VudHJhbDpmODk4YjM5MDNjYjk5YzU5ZDU3YjFlYjE0MzM1ZTcwMQ",
"repository" : "maven-central",
"format" : "maven2",
"checksum" : {
"sha1" : "6b98f5cef5d7102f8f45215bdcf48dc843d060af",
"md5" : "f3b3ac640853fcb887621d13029a1747"
}
} ]
}
So, is there an easy way to get dependency metadata?

Related

Find out user who created database/collection in MongoDB

I have so many applications on my server who are using mongo db. I want to find out the user name which is being used to create specific db/collection.
I see some application is malfunctioning and keeps on creating dbs dynamically. I want to find out the application through the user which is being used.
What i have done so far is, i found out the connection information from the mongodb logs by grepping that database and then ran this query,
db.currentOp(true).inprog.forEach(function(o){if(o.connectionId == 502925 ) printjson(o)});
And this is the result i am getting,
{
"host" : "abcd-server:27017",
"desc" : "conn502925",
"connectionId" : 502925,
"client" : "127.0.0.1:39266",
"clientMetadata" : {
"driver" : {
"name" : "mongo-java-driver",
"version" : "3.6.4"
},
"os" : {
"type" : "Linux",
"name" : "Linux",
"architecture" : "amd64",
"version" : "3.10.0-862.14.4.el7.x86_64"
},
"platform" : "Java/AdoptOpenJDK/1.8.0_212-b03"
},
"active" : false,
"currentOpTime" : "2019-07-02T07:31:39.518-0500"
}
Please let me know if there is any way to find out the user.

Migrating data in MongoDB

I am working on an application and I need to move the Stripe payment data I have saved around in my user model. I am looking for the best way of doing this. My current data is stored at user.stripe.<value> but I want to move it to user.company.stripe.<value>
Is there tools out there that can handle moving this data around for me or will I need to create a tool to handle this myself? I will be doing a decent amount of this type of data movement during a major refactor (more like a rewrite) so making a tool if non exists is okay with me just no idea how to migrate the data and other Stack Overflow posts are not being of much use that I have found.
Probably picked a bad day/time to post too... Hopefully someone can help me out with examples or direction on where to go from here.
What I want the data to look like:
{ "_id" : ObjectId("5b89c571d855a23b5b07fe95"), "company" : { "customForms" : [ ], "subUserCount" : 1, "stripe" : { "plan" : "<plan Name>", "customerId" : "cus_<ID>", "last4" : "4242", "subscriptionId" : "sub<ID>", "isCoupon" : false } }, "email" : "john.doe#example.ca", "password" : "$2a$10$gMbdy5Dh9Ym..xbVAvhaJO2xhVARAL3oXvad/fX4zAcCuZB88tR1C", "role" : "company", "companyID" : "da89bdee-4123-444c-b221-d41212320a90", }
Current data format:
{ "_id" : ObjectId("5b89c571d855a23b5b07fe95"), "company" : { "customForms" : [ ], "subUserCount" : 1 }, "stripe" : { "plan" : "testplan2", "customerId" : "cus_<ID>", "last4" : "4242", "subscriptionId" : "sub_<ID>", "isCoupon" : false }, "isVerified" : true, "email" : "john.doe#example.ca", "password" : "$2a$10$gMbdy5Dh9Ym..xbVAvhaJO2xhVARAL3oXvad/fX4zAcCuZB88tR1C", "role" : "company", "companyID" : "da89bdee-4123-444c-b221-d41212320a90" }

ALPS sample implementation

I'm looking for a sample client implementation utilizing ALPS (not the mountains but the Application-Level Profile Semantics).
Do YOU! have one?
I've looked into the related RFC draft and discussions but still can figure it quite out.
Specifically I would like to know how my client should know what the descriptor describes, given that my client supposedly knows nothing about the structure and semantics of the REST API as the REST principle demands?
As a human I know that a descriptor with an id tag called "users" is likely to describe how to interact with users but how is my client to know without me telling him explicitly?
I know I could insert some kind of keyword to show up in the descriptor and tell my client to match the appropriate ones but this seems hardly the right way.
I happily provide a more detailed example given somebody is willing to read it.
I'm exploring ALPS for the first time too, and my understanding from that RFC draft wasn't immediate either.
Here is a slideshow (166 slides, so it's not possible to copy it all into this answer) from the author of the RFC which I think gives a much better understanding of the role ALPS plays.
As a human I know that a descriptor with an id tag called users is likely to describe how to interact with users but how is my client to know this without me telling him explicitly?
From this slideshow, I deduce this answer to your question: He doesn't.
In the slideshow, a sample ALPS profile is compared with equivalent HTML code for a form submit. The browser knows how to render the HTML to the screen, but only the human knows what it means to POST that form with those input fields, using that submit button.
Here is an example Complete JSON Representation taken from alps.io
{
"alps" : {
"version" : "1.0",
"doc" : {
"href" : "http://example.org/samples/full/doc.html"
},
"descriptor" : [
{
"id" : "search",
"type" : "safe",
"doc" : {"value" :
"A search form with a two inputs"
},
"descriptor" : [
{
"id" : "value",
"name" : "search",
"type" : "descriptor",
"doc" : { "value" : "input for search" }
},
{ "href" : "#resultType" }
]
},
{
"id" : "resultType",
"type" : "descriptor",
"description" : {"value" : "results format"},
"ext" : [
{
"href" : "http://alps.io/ext/range",
"value" : "summary,detail"
}
]
}
]
}
}
Take, for example, a generic mobile phone app which is displaying screens to the user based on REST responses. Say a HAL+Json response contains a reference to a search entity. The app can lookup in this ALPS document what a search entity is, and can be coded on how to represent that. Namely, a search is something which has a name/value pair (with an id) and a href. The href refers to the second descriptor with id resultType which lets the app know the format to expect for search results. The actual URLs and data involved would come from the REST responses.
From July 2014, here is a Spring blog article describing the ALPS for an app which manages a "To Do List". The ALPS document describes
What is a todo entity
What actions can be done with a todo entity
An abridged version of the ALPS profile for that small app:
{
"version" : "1.0",
"descriptors" : [ {
"id" : "todo-representation",
"descriptors" : [ {
"name" : "description",
"doc" : {
"value" : "Details about the TODO item",
"format" : "TEXT"
},
"type" : "SEMANTIC"
}, {
"name" : "title",
"doc" : {
"value" : "Title for the TODO item",
"format" : "TEXT"
},
"type" : "SEMANTIC"
}, {
"name" : "id",
"type" : "SEMANTIC"
}, {
"name" : "completed",
"doc" : {
"value" : "Is it completed?",
"format" : "TEXT"
},
"type" : "SEMANTIC"
} ]
}, {
"id" : "create-todos",
"name" : "todos",
"type" : "UNSAFE",
"rt" : "#todo-representation"
}, {
"id" : "get-todos",
"name" : "todos",
"type" : "SAFE",
"rt" : "#todo-representation"
}, {
"id" : "delete-todo",
"name" : "todo",
"type" : "IDEMPOTENT",
"rt" : "#todo-representation"
} ]
}
I guess one way to think of it might as a kind "schema", but instead of database tables, it's describing the scope of REST responses.

Fix duplicate name situation due to entities created before Orion 0.17.0

Since Orion 0.17.0 attribute type is no longer used as attribute "identification key". However, I have entities created with a pre-0.17.0 version that have attributes with the same name and different types. For example, the following entity, which have "ActivePower" duplicated:
> db.entities.findOne({"_id.type": "Regulator", "_id.id": "OUTSMART.RG_LAS_LLAMAS_01", "_id.servicePath": "/"})
{
"_id" : {
"type" : "Regulator",
"id" : "OUTSMART.RG_LAS_LLAMAS_01",
"servicePath" : "/"
},
"attrs" : [
{
"name" : "TimeInstant",
"value" : "2015-04-27T01:51:36.000000Z",
"type" : "urn:x-ogc:def:trs:IDAS:1.0:ISO8601",
"modDate" : 1430092302
},
{
"name" : "ActivePower",
"value" : "11778",
"type" : "urn:x-ogc:def:phenomenon:Outsmart:1.0:ActivePower",
"modDate" : 1430092302
},
{
"name" : "ReactivePower",
"value" : "8414",
"type" : "urn:x-ogc:def:phenomenon:Outsmart:1.0:ReactivePower",
"modDate" : 1430092302
},
{
"name" : "electricPotential",
"value" : "231",
"type" : "urn:x-ogc:def:phenomenon:IDAS:1.0:electricPotential",
"modDate" : 1430092302
},
{
"name" : "electricCurrent",
"value" : "20890",
"type" : "urn:x-ogc:def:phenomenon:IDAS:1.0:electricCurrent",
"modDate" : 1430092302
},
{
"name" : "Latitud",
"value" : "43.4716987609863",
"type" : "urn:x-ogc:def:phenomenon:IDAS:1.0:latitude",
"modDate" : 1414522843
},
{
"name" : "Longitud",
"value" : "-3.80692005157471",
"type" : "urn:x-ogc:def:phenomenon:IDAS:1.0:longitude",
"modDate" : 1401818472
},
{
"name" : "ActivePower",
"creDate" : 1393420396,
"value" : "11778.2",
"type" : "float",
"modDate" : 1430092302
}
],
"modDate" : 1430092302
}
How can I adapt that entity to work with Orion 0.17.0 and beyond?
The simplest solution is to edit the entity using mongo console, to remove all the "duplicated" attributes with the same name and leave only one. In the example above we have one ActivePower with type urn:x-ogc:def:phenomenon:Outsmart:1.0:ActivePower and other with type float. Let's assume we want to kept the first one.
First of all, stop Orion and take a backup of the database. If something gets wrong while you edit the entity, you could need that backup to go back the initial status and try again.
Next, run mongo console (let's assume that your DB is named "orion") and get the entity to modify using findOne() operation. Let's store it in the doc variable.
# mongo orion
> doc = db.entities.findOne({"_id.type": "Regulator", "_id.id": "OUTSMART.RG_LAS_LLAMAS_01", "_id.servicePath": "/"})
...
Now, identify the position within the attrs array of the attribute to remove, taking into account that the position of the first element in the vector is 0 (and not 1). Looking to the above example, the attribute to remove is the 7-th. Check that printing the attribute:
> doc.attrs[7]
{
"name" : "ActivePower",
"creDate" : 1393420396,
"value" : "11778.2",
"type" : "float",
"modDate" : 1430092302
}
Use splice() function to remove the attribute from doc, using as first parameter the position of the attribute and as second parameter 1. Print the doc value to check that it has been removed:
> doc.attrs.splice(7, 1)
...
> doc
Repeat the above operation as many time as you need to remove all duplicated (in the example case, there is only one duplicated). When you are done, save the new version of the entity in the DB:
> db.entities.save(doc)

how can I do a POST Req for a REST service in SoapUI 5.1.2 with form-data

Could you help me to resolved the problem that I have?
Using Postman (REST Client - chrome extension) I do a Post to a REST service an I get the correct answer from the services.
The answer is "201 Created" and a new row is added into the DB.
URL = http://suring-t.suremptec.com.ar/gis/13/rest/1.0/organizations
form-date = metadata
{
"meta" : {
"version" : "1.0",
"description" : "Organization"
},
"id" : null,
"name" : "test org",
"startDate" : "2014-06-05 16:20:31.334",
"endDate" : null,
"administrable" : true,
"published" : true,
"href" : "\/2\/rest\/1.0\/organizations\/1"
}
I can't find the way to make SoapUI (5.1.2) works with the same request.
URL = http://suring-t.suremptec.com.ar/gis/13/rest/1.0/organizations
form-date =
metadata
{
"meta" : {
"version" : "1.0",
"description" : "Organization"
},
"id" : null,
"name" : "test org",
"startDate" : "2014-06-05 16:20:31.334",
"endDate" : null,
"administrable" : true,
"published" : true,
"href" : "/2/rest/1.0/organizations/1"
}
The response is "200 - Ok" but
Any Ideas, how should configure the soapui request?
This should get you started Getting started with REST