From Manvendra.Rai at ril.com Wed Jun 1 00:29:25 2016 From: Manvendra.Rai at ril.com (Manvendra.Rai at ril.com) Date: Wed, 1 Jun 2016 04:29:25 +0000 Subject: [Apiman-user] Question: How to stop path segments & query parameters from going on to the back-end API endpoint? In-Reply-To: References: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com> <6faccc66-f9f1-e6ee-1dc5-45e44d71285b@redhat.com> Message-ID: <346a8d68f6914b638541f277a5aa62e6@SIDC1EXMBX23.in.ril.com> Thanks much Eric, helps a lot indeed. Thanks, Manav -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 31 May 2016 22:59 To: Nidhish Agrawal; apiman-user at lists.jboss.org Cc: Manvendra Rai Subject: Re: [Apiman-user] Question: How to stop path segments & query parameters from going on to the back-end API endpoint? The URL field holds the absolute URL sent by the client. The 'destination' field is just the extra path segments beyond the managed endpoint. So for example: https://localhost:8443/apiman-gateway/MyOrg/MyApi/1.7/path/to/dest In this case, the 'url' field will hold the entire value from above, while the 'destination' will hold just this: /path/to/dest The full URL exists only for auditing and reference purposes, while 'destination' is used downstream from the policies when proxying to the back end API. -Eric On 5/31/2016 1:24 PM, Nidhish.Agrawal at ril.com wrote: > Hi Eric, > > Thanks for the very quick response, I am working on the policies part > with manav > > I am manipulating with > request.setUrl(request.getUrl().subString(0,15)) , but it not stoping the path param to pass with endpoint. > > Can you please give difference between destination & url. > > Regards > Nidhish Agrawal > > Direct : +91-22-4475 0085 > Mobile : +91-8828002901 > E- mail : nidhish > > > > > On 5/31/16, 8:40 PM, "Eric Wittmann" wrote: > >> Hi Manav, >> >> This would require a custom policy to be implemented (this is pretty >> easy if you have access to a java developer!). Unfortunately we >> don't have any policies out of the box that will let you manipulate the path. >> >> But here is how you could do it in a custom plugin: >> >> >> https://gist.github.com/EricWittmann/aa0073b47f1f4d159c6a75e60ab22faf >> >> This is just pseudo-code, mind you. But basically you can manipulate >> the path, headers, and query params in whatever way you wish. >> >> -Eric >> >> On 5/31/2016 8:01 AM, Manvendra.Rai at ril.com wrote: >>> Hello All, >>> >>> I left this question on freenode IRC and though to post the same >>> on the email group. >>> >>> >>> >>> *Question*: We are using API Gateway for couple of things and one of >>> the main functionalities we are leveraging is - Managed API. >>> >>> >>> >>> Our requirement is to create a Plugin which will invoke backend API >>> after fetching _fielded from the database_ based on the object id >>> from the Manage URL. >>> >>> >>> >>> Say for example - >>> >>> >>> >>> My manage API is - >>> >>> >>> >>> http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid} >>> >> 7d> >>> >>> >>> >>> >>> >>> My Backend API >>> >>> >>> >>> http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fil >>> eid} >>> >>> >> filei >>> d%7d> >>> >>> >>> >>> We have implemented almost all this requirement but have one issue. >>> As per the default behaviour, API Gateway proxies all path segments >>> beyond the {version} segment with query parameters back-end API. >>> >>> This is causing an issue because [objected] is also being sent to >>> Backend API. >>> >>> >>> >>> So my question is to know how can we stop {objected} from going to >>> Backend API? >>> >>> >>> >>> Thanks for your time looking at the issue and advising back. >>> >>> >>> >>> Thanks, >>> >>> Manav >>> >>> >>> >>> >>> "*Confidentiality Warning*: This message and any attachments are >>> intended only for the use of the intended recipient(s), are >>> confidential and may be privileged. If you are not the intended >>> recipient, you are hereby notified that any review, re-transmission, >>> conversion to hard copy, copying, circulation or other use of this >>> message and any attachments is strictly prohibited. If you are not >>> the intended recipient, please notify the sender immediately by >>> return email and delete this message and any attachments from your system. >>> >>> *Virus Warning:* Although the company has taken reasonable >>> precautions to ensure no viruses are present in this email. The >>> company cannot accept responsibility for any loss or damage arising >>> from the use of this email or attachment." >>> >>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> > > "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). > are confidential and may be privileged. If you are not the intended > recipient. you are hereby notified that any review. re-transmission. > conversion to hard copy. copying. circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. > and delete this message and any attachments from your system. > > Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. > The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment." > "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. and delete this message and any attachments from your system. Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment." From eric.wittmann at redhat.com Wed Jun 1 12:25:52 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 1 Jun 2016 12:25:52 -0400 Subject: [Apiman-user] Transfer Quota Policy In-Reply-To: References: Message-ID: Thanks for the question Subba. Because apiman streams the data in both directions, we don't necessarily know whether a response will violate the transfer quota policy (at the time the policy is being applied). Here is the sequence of events: 1) receive HTTP request 2) apply Policy to request 3) connect to back-end API 4) stream data from originating client to back-end API 5) receive HTTP response from back-end API 6) apply Policy to response 7) stream data from back-end API to originating client 8) record # of bytes transferred, update counter So if the number of bytes from #7 exceeds the allowed amount, it will still pass (but the *next* request will fail). There is also a race condition where multiple concurrent requests could all get past step #6. This is all done this way for performance reasons. If you are in need of a stricter approach, we would need to discuss how that could be built. -Eric On 6/1/2016 10:47 AM, Subbarao Denduluri wrote: > Hello Eric, > > > > We are trying to configure the transfer quota policy at the client > app level. When we give the policy to a lower level of 2 KB , the > first couple of request are going through even if they return a larger > amount of data. How do we interpret the download data limit ? Is it > size of the json the api is returning or something else? > > > > Thanks > > Subba > From sdenduluri at ebsco.com Wed Jun 1 13:06:04 2016 From: sdenduluri at ebsco.com (Subbarao Denduluri) Date: Wed, 1 Jun 2016 17:06:04 +0000 Subject: [Apiman-user] Transfer Quota Policy In-Reply-To: References: Message-ID: Thank you Eric for the response. That explains the scenario. -Subba -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: Wednesday, June 01, 2016 12:26 PM To: Subbarao Denduluri ; apiman-user at lists.jboss.org Subject: Re: Transfer Quota Policy Thanks for the question Subba. Because apiman streams the data in both directions, we don't necessarily know whether a response will violate the transfer quota policy (at the time the policy is being applied). Here is the sequence of events: 1) receive HTTP request 2) apply Policy to request 3) connect to back-end API 4) stream data from originating client to back-end API 5) receive HTTP response from back-end API 6) apply Policy to response 7) stream data from back-end API to originating client 8) record # of bytes transferred, update counter So if the number of bytes from #7 exceeds the allowed amount, it will still pass (but the *next* request will fail). There is also a race condition where multiple concurrent requests could all get past step #6. This is all done this way for performance reasons. If you are in need of a stricter approach, we would need to discuss how that could be built. -Eric On 6/1/2016 10:47 AM, Subbarao Denduluri wrote: > Hello Eric, > > > > We are trying to configure the transfer quota policy at the client > app level. When we give the policy to a lower level of 2 KB , the > first couple of request are going through even if they return a larger > amount of data. How do we interpret the download data limit ? Is it > size of the json the api is returning or something else? > > > > Thanks > > Subba > From cstolte at ebsco.com Fri Jun 3 13:02:47 2016 From: cstolte at ebsco.com (Christopher Stolte) Date: Fri, 3 Jun 2016 17:02:47 +0000 Subject: [Apiman-user] APIMAN, clustering, and versioning Message-ID: Hello Apiman community, Our team is hoping to use Apiman in a production environment that includes a load-balanced cluster of Apiman gateway instances. Those instances would share Elasticsearch storage for metrics etc., as per this architecture summary: http://www.apiman.io/latest/production-guide.html#_architecture_summary As we imagine this scenario, some questions pop up that we don't have answers to. For example, what assumptions can we make about data integrity when Apiman releases a new version? Are major releases the only ones that might break a schema (and thus not coexist happily in a cluster with other instances of a different version) ? I apologize if this is documented somewhere - I took a look around but didn't find anything related to versioning semantics. Basically we'd like to understand the upgrade path for a given instance within a cluster. Apiman team: what have you tested or consciously targeted as far as clustered environments? Has anyone out there in the community tried to use a cluster of gateways? Has there been any work done related to this ticket? https://issues.jboss.org/browse/APIMAN-278 Thank you in advance for any comments or guidance! Chris Stolte -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160603/fa8d4a7b/attachment-0001.html From eric.wittmann at redhat.com Mon Jun 6 15:02:48 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 6 Jun 2016 15:02:48 -0400 Subject: [Apiman-user] APIMAN, clustering, and versioning In-Reply-To: References: Message-ID: Hi Chris. Thanks for the question. Some responses below: On 6/3/2016 1:02 PM, Christopher Stolte wrote: > Our team is hoping to use Apiman in a production environment that > includes a load-balanced cluster of Apiman gateway instances. Those > instances would share Elasticsearch storage for metrics etc., as per > this architecture summary: Note that if you simply have multiple instances of the gateway running, all pointed to the same ES storage, you do not need those gateway instances to be "clustered". It's a subtle point, but it might be important. Note that this point may change in the future as we create better implementations of certain components (like rate limiting). > As we imagine this scenario, some questions pop up that we don't have > answers to. For example, what assumptions can we make about data > integrity when Apiman releases a new version? Are major releases the > only ones that might break a schema (and thus not coexist happily in a > cluster with other instances of a different version) ? I apologize if > this is documented somewhere - I took a look around but didn't find > anything related to versioning semantics. Basically we'd like to > understand the upgrade path for a given instance within a cluster. This is a great question, and something that isn't yet very mature within apiman. The short answer is that we don't make any guarantees (currently) in community with regard to when the schema may change. Rolling upgrades is not yet something we've explicitly planned for. The current (easy) approach is to stand up a new environment for the new version of apiman, then migrate your data from old to new. Once done, you can do a cutover. If you have a large number of instances this may not be possible. > Apiman team: what have you tested or consciously targeted as far as > clustered environments? Has anyone out there in the community tried to > use a cluster of gateways? Has there been any work done related to this > ticket? We have just begun our internal clustering testing, so we be getting this sort of experience very soon. We'll be testing for HA and scalability first and foremost. That said, the software is designed to easily run in a "cluster" (quotes used because as previously mentioned, the nodes do not actually need to be running in a proper cluster). -Eric From cstolte at ebsco.com Tue Jun 7 13:44:18 2016 From: cstolte at ebsco.com (Christopher Stolte) Date: Tue, 7 Jun 2016 17:44:18 +0000 Subject: [Apiman-user] APIMAN, clustering, and versioning In-Reply-To: References: , Message-ID: Hi Eric, Thanks for your response. In the event of a schema change, would your team be providing anything in the way of migration/validation scripts or tools? I assume it would be mentioned in the release notes, right? I know you can't predict the future, but could you characterize the frequency of such changes at this point? (i.e. known schema changes coming soon and often / probably something in the next 6 months / unlikely to rare...) Thanks, Chris ________________________________ From: Eric Wittmann Sent: Monday, June 6, 2016 3:02:48 PM To: Christopher Stolte; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] APIMAN, clustering, and versioning Hi Chris. Thanks for the question. Some responses below: On 6/3/2016 1:02 PM, Christopher Stolte wrote: > Our team is hoping to use Apiman in a production environment that > includes a load-balanced cluster of Apiman gateway instances. Those > instances would share Elasticsearch storage for metrics etc., as per > this architecture summary: Note that if you simply have multiple instances of the gateway running, all pointed to the same ES storage, you do not need those gateway instances to be "clustered". It's a subtle point, but it might be important. Note that this point may change in the future as we create better implementations of certain components (like rate limiting). > As we imagine this scenario, some questions pop up that we don't have > answers to. For example, what assumptions can we make about data > integrity when Apiman releases a new version? Are major releases the > only ones that might break a schema (and thus not coexist happily in a > cluster with other instances of a different version) ? I apologize if > this is documented somewhere - I took a look around but didn't find > anything related to versioning semantics. Basically we'd like to > understand the upgrade path for a given instance within a cluster. This is a great question, and something that isn't yet very mature within apiman. The short answer is that we don't make any guarantees (currently) in community with regard to when the schema may change. Rolling upgrades is not yet something we've explicitly planned for. The current (easy) approach is to stand up a new environment for the new version of apiman, then migrate your data from old to new. Once done, you can do a cutover. If you have a large number of instances this may not be possible. > Apiman team: what have you tested or consciously targeted as far as > clustered environments? Has anyone out there in the community tried to > use a cluster of gateways? Has there been any work done related to this > ticket? We have just begun our internal clustering testing, so we be getting this sort of experience very soon. We'll be testing for HA and scalability first and foremost. That said, the software is designed to easily run in a "cluster" (quotes used because as previously mentioned, the nodes do not actually need to be running in a proper cluster). -Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160607/d3e61b4d/attachment.html From eric.wittmann at redhat.com Tue Jun 7 14:55:16 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 7 Jun 2016 14:55:16 -0400 Subject: [Apiman-user] APIMAN, clustering, and versioning In-Reply-To: References: Message-ID: The way we handle upgrades from older versions (version X) to newer ones that have breaking schema changes (version Y) is as follows: 1) export all data from version X - the result will be a (potentially large) JSON file - "version X" will be included in the meta-data for this export file) 2) install version Y (new instances, new+empty DB instance) 3) import the file from step #1 into version Y 4) profit! The important point here is that step #3 will automatically detect that it is importing an older file and will "upgrade" the data to the latest version, if necessary. This approach allows us to support the following: - Upgrade from arbitrary older version of apiman to an arbitrary newer version - Upgrade apiman from one storage mechanism to another (e.g. switch from mysql to postgresql, or even switch from mysql to elasticsearch) - Automatic, periodic backup of all relevant data for later restoration It's worth noting that metrics information is currently not included in this process - we'll need a solution to that in the future. The current assumption is that the metrics data is stored in elasticsearch in a format that will not change soon... Of course, this isn't a good story for a cluster of nodes that require rolling updates. Clearly to support that we would need to prevent any breaking DB schema changes so... ...to answer your other question - I don't anticipate any *breaking* changes to the schema in the foreseeable future. But as you say, I can't guarantee it. :) I would expect any schema changes to be additive (new tables or columns). That said, we will not likely be providing DDL patch scripts in community - so any in-place DB upgrades will be more manual than you might like (e.g. diff the full DDLs to create your own patch script). -Eric On 6/7/2016 1:44 PM, Christopher Stolte wrote: > Hi Eric, > > > Thanks for your response. In the event of a schema change, would your > team be providing anything in the way of migration/validation scripts or > tools? I assume it would be mentioned in the release notes, right? I > know you can't predict the future, but could you characterize the > frequency of such changes at this point? (i.e. known schema changes > coming soon and often / probably something in the next 6 months / > unlikely to rare...) > > > Thanks, > > Chris > > ------------------------------------------------------------------------ > *From:* Eric Wittmann > *Sent:* Monday, June 6, 2016 3:02:48 PM > *To:* Christopher Stolte; apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] APIMAN, clustering, and versioning > > Hi Chris. Thanks for the question. > > Some responses below: > > On 6/3/2016 1:02 PM, Christopher Stolte wrote: >> Our team is hoping to use Apiman in a production environment that >> includes a load-balanced cluster of Apiman gateway instances. Those >> instances would share Elasticsearch storage for metrics etc., as per >> this architecture summary: > > Note that if you simply have multiple instances of the gateway running, > all pointed to the same ES storage, you do not need those gateway > instances to be "clustered". It's a subtle point, but it might be > important. Note that this point may change in the future as we create > better implementations of certain components (like rate limiting). > >> As we imagine this scenario, some questions pop up that we don't have >> answers to. For example, what assumptions can we make about data >> integrity when Apiman releases a new version? Are major releases the >> only ones that might break a schema (and thus not coexist happily in a >> cluster with other instances of a different version) ? I apologize if >> this is documented somewhere - I took a look around but didn't find >> anything related to versioning semantics. Basically we'd like to >> understand the upgrade path for a given instance within a cluster. > > This is a great question, and something that isn't yet very mature > within apiman. The short answer is that we don't make any guarantees > (currently) in community with regard to when the schema may change. > Rolling upgrades is not yet something we've explicitly planned for. The > current (easy) approach is to stand up a new environment for the new > version of apiman, then migrate your data from old to new. Once done, > you can do a cutover. If you have a large number of instances this may > not be possible. > >> Apiman team: what have you tested or consciously targeted as far as >> clustered environments? Has anyone out there in the community tried to >> use a cluster of gateways? Has there been any work done related to this >> ticket? > > We have just begun our internal clustering testing, so we be getting > this sort of experience very soon. We'll be testing for HA and > scalability first and foremost. That said, the software is designed to > easily run in a "cluster" (quotes used because as previously mentioned, > the nodes do not actually need to be running in a proper cluster). > > -Eric From Ashish.Patel at futureretail.in Wed Jun 8 06:33:01 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Wed, 8 Jun 2016 16:03:01 +0530 Subject: [Apiman-user] apiman Production Deployment Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> Hi, I was referring production guide (http://www.apiman.io/latest/production-guide.html) for apiman production deployment @ our organisation. have few queries, appreciate if someone can help. 1. We want to have single API Manager for our consumers in "on-premise" and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " Apiman Gateway" in on-premise and couple of on cloud ? If yes, what would be possible deployment architecture ? (best place to put RDBMS on-prem/cloud, best place to put keyclock server/ ES server..etc ?) 2. production guide having wildfly version, however we would prefer tomcat / vert.x, any specific guide changes for tomcat / vert.x ? 3. Can we have companies using apiman on production ? any benchmarking stats and case study material ? Thanks & Regards, Ashish ________________________________ Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160608/8e10cf99/attachment-0001.html From Ashish.Patel at futureretail.in Thu Jun 9 08:45:36 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Thu, 9 Jun 2016 18:15:36 +0530 Subject: [Apiman-user] Transformer policy plugin issue Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> Hi, We are facing issue while using Transformer plugin. Scenario: We have SOAP Service in backend and want to expose as JSON to client App. 1. we have registered the SOAP service in Implementation (with Basic Auth). 2. added policy for using Transformation plugin (Client: JSON, Server:XML). 3. Published as Public API. Through Rest Client -> Called Public API (POST -> content type as application/json and json input), however it failed with 500 error (able to read stacktrace - suggest input is not passed correctly). With more debugging: As there are no logs from Transformation plugin, have added sysouts and found that JsonToXmlTransformer is NOT being called for input (json -> xml) transformation, however, on response XmlToJsonTransformer is being called successfully. Kindly suggest. Thanks & Regards, Ashish Patel "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. ________________________________ Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160609/221e4739/attachment.html From eric.wittmann at redhat.com Fri Jun 10 10:59:19 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 10 Jun 2016 10:59:19 -0400 Subject: [Apiman-user] Transformer policy plugin issue In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> Message-ID: The transformation policy may not be suitable for converting soap to json. Soap is xml, for sure, but it has a pretty specific format. I'm not sure a direct mapping with JSON is possible, so you might need a custom plugin policy to accomplish this. That said, I would have expected the JsonToXmlTransformer to at least be invoked on the request payload, even if the results aren't exactly what is needed. Can you please open a JIRA for this bug? https://issues.jboss.org/projects/APIMAN Thanks, Eric On 6/9/2016 8:45 AM, Ashish Patel wrote: > Hi, > > > > We are facing issue while using Transformer plugin. > > > > Scenario: We have SOAP Service in backend and want to expose as JSON to > client App. > > > > 1. we have registered the SOAP service in Implementation (with Basic Auth). > > 2. added policy for using Transformation plugin (Client: JSON, Server:XML). > > 3. Published as Public API. > > > > Through Rest Client -> Called Public API (POST -> content type as > application/json and json input), however it failed with 500 error (able > to read stacktrace - suggest input is not passed correctly). > > > > With more debugging: As there are no logs from Transformation plugin, > have added sysouts and found that JsonToXmlTransformer is NOT being > called for input (json -> xml) transformation, however, on response > XmlToJsonTransformer is being called successfully. > > > > Kindly suggest. > > > > Thanks & Regards, > > Ashish Patel > > > > "Scientists investigate that which already is;Engineers create that > which has never been." - Albert Einstein. > > > > > ------------------------------------------------------------------------ > Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The views > expressed in this email are those of the sender and not Future Group's. > The recipient should check this email and attachments for the presence > of viruses. Future Group accepts no liability for any damage caused by > any virus transmitted by this email. Future Group may monitor and record > all emails. > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From mjoyappa at EBSCO.COM Fri Jun 10 13:38:30 2016 From: mjoyappa at EBSCO.COM (Mohan Joyappa) Date: Fri, 10 Jun 2016 17:38:30 +0000 Subject: [Apiman-user] Different API version-Contract Creation Message-ID: Hi Eric, I have following scenario. I have two version of same API. Version 1 of API is the base version and version 2 of API has some additional changes to it (like some extra policy and what not). When I try to create a contract for my clientApp, I get to select what version of API I need to use as shown below [cid:image003.png at 01D1C31D.59B13A70] So if I select API version 1.0 and click on OK, contract is always created with latest version of API no matter what other older version of API you have. [cid:image004.png at 01D1C31D.59B13A70] Is this intentionally designed? If yes, the first step to choose a particular API version while creating a contract is somewhat misleading to me. Best Mohan Joyappa -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160610/c654a256/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 25800 bytes Desc: image003.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160610/c654a256/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 83422 bytes Desc: image004.png Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160610/c654a256/attachment-0003.png From Ashish.Patel at futureretail.in Mon Jun 13 01:04:17 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Mon, 13 Jun 2016 10:34:17 +0530 Subject: [Apiman-user] Transformer policy plugin issue In-Reply-To: References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E71BFFC@DC-SRV-MBX-08> Thanks Eric for quick response. We want SOAP to JSON for our legacy Apps (like SAP ECC) which can't expose JSON. We want to have standard input for all our Mobile / APIs as JSON and so we need this conversion (though not 100% REST compatible). Sure, APIMAN-1182, opened. Thanks & Regards, Ashish Patel (M) +91 93270 15128 "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 10 June 2016 20:29 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Transformer policy plugin issue The transformation policy may not be suitable for converting soap to json. Soap is xml, for sure, but it has a pretty specific format. I'm not sure a direct mapping with JSON is possible, so you might need a custom plugin policy to accomplish this. That said, I would have expected the JsonToXmlTransformer to at least be invoked on the request payload, even if the results aren't exactly what is needed. Can you please open a JIRA for this bug? https://issues.jboss.org/projects/APIMAN Thanks, Eric On 6/9/2016 8:45 AM, Ashish Patel wrote: > Hi, > > > > We are facing issue while using Transformer plugin. > > > > Scenario: We have SOAP Service in backend and want to expose as JSON to > client App. > > > > 1. we have registered the SOAP service in Implementation (with Basic Auth). > > 2. added policy for using Transformation plugin (Client: JSON, Server:XML). > > 3. Published as Public API. > > > > Through Rest Client -> Called Public API (POST -> content type as > application/json and json input), however it failed with 500 error (able > to read stacktrace - suggest input is not passed correctly). > > > > With more debugging: As there are no logs from Transformation plugin, > have added sysouts and found that JsonToXmlTransformer is NOT being > called for input (json -> xml) transformation, however, on response > XmlToJsonTransformer is being called successfully. > > > > Kindly suggest. > > > > Thanks & Regards, > > Ashish Patel > > > > "Scientists investigate that which already is;Engineers create that > which has never been." - Albert Einstein. > > > > > ------------------------------------------------------------------------ > Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The views > expressed in this email are those of the sender and not Future Group's. > The recipient should check this email and attachments for the presence > of viruses. Future Group accepts no liability for any damage caused by > any virus transmitted by this email. Future Group may monitor and record > all emails. > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From eric.wittmann at redhat.com Mon Jun 13 12:01:50 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 13 Jun 2016 12:01:50 -0400 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> Message-ID: Hi Ashish. Sorry for the delay in my response. I'll do my best to answer your questions. > 1. We want to have single API Manager for our consumers in "on-premise" > and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " > Apiman Gateway" in on-premise and couple of on cloud ? If yes, what > would be possible deployment architecture ? (best place to put RDBMS > on-prem/cloud, best place to put keyclock server/ ES server..etc ?) There are a very large number of choices here! It depends a lot on exactly what you're trying to achieve. Two different configurations jump to mind. Config 1 - A single "logical" API Gateway In this configuration, every API Gateway node (regardless of whether it is on-prem or in the cloud) shares a common data store. This allows every node to service the *same* set of APIs. In this case the single gateway storage (database or elasticsearch) will need to be accessible by all gateway nodes. In the UI, there is only *one* gateway, so there are no extra steps that API developers need take when publishing APIs. However, every Gateway node must be able to access every back-end endpoint at the same URL. Config 2 - Two "logical" API Gateways In this config, the on-prem gateway node(s) and the in-cloud gateway node(s) each have their own gateway storage (database and/or elasticsearch). When set up this way, the API Manager must be configured with *both* gateways, and each gateway should have a sensible name, such as "On Premise Gateway" and "Cloud Gateway". In the UI, the API Developers will need to choose which of the two API Gateways their API should be published to (they must choose *at least one* gateway). This allows different gateways to service different APIs, offering more flexibility. > 2. production guide having wildfly version, however we would prefer > tomcat / vert.x, any specific guide changes for tomcat / vert.x ? We only have documentation for Wildfly at the moment, but if you wish to use Tomcat it should be relatively simple to extrapolate the documentation to that platform. The vert.x implementation is experimental at this point, and should not be used in production. > 3. Can we have companies using apiman on production ? any benchmarking > stats and case study material ? I'm sorry to say that we don't currently have reference users or production benchmarks yet. These materials will surely be coming in the future as the project matures. Thanks! -Eric From eric.wittmann at redhat.com Mon Jun 13 12:07:16 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 13 Jun 2016 12:07:16 -0400 Subject: [Apiman-user] Transformer policy plugin issue In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E71BFFC@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E71BFFC@DC-SRV-MBX-08> Message-ID: SOAP<->JSON conversion is, in my opinion, a separate feature request. I have updated APIMAN-1182 to reflect that. I think this is a valuable feature to have, but given our current backlog of work I cant' give you any great idea of when it might be implemented. If you are up for it, it should be very possible to implement this functionality yourself as a custom policy. Perhaps that could serve as a contribution back to the community which could then be improved upon for the benefit of all! :) I'd be happy to provide some direction on such an effort. If that's not possible, we'll have to get to it as soon as we can. :) -Eric On 6/13/2016 1:04 AM, Ashish Patel wrote: > Thanks Eric for quick response. > > We want SOAP to JSON for our legacy Apps (like SAP ECC) which can't expose JSON. We want to have standard input for all our Mobile / APIs as JSON and so we need this conversion (though not 100% REST compatible). > > Sure, APIMAN-1182, opened. > > Thanks & Regards, > Ashish Patel > (M) +91 93270 15128 > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 10 June 2016 20:29 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] Transformer policy plugin issue > > The transformation policy may not be suitable for converting soap to > json. Soap is xml, for sure, but it has a pretty specific format. I'm > not sure a direct mapping with JSON is possible, so you might need a > custom plugin policy to accomplish this. > > That said, I would have expected the JsonToXmlTransformer to at least be > invoked on the request payload, even if the results aren't exactly what > is needed. > > Can you please open a JIRA for this bug? > > https://issues.jboss.org/projects/APIMAN > > Thanks, > > Eric > > On 6/9/2016 8:45 AM, Ashish Patel wrote: >> Hi, >> >> >> >> We are facing issue while using Transformer plugin. >> >> >> >> Scenario: We have SOAP Service in backend and want to expose as JSON to >> client App. >> >> >> >> 1. we have registered the SOAP service in Implementation (with Basic Auth). >> >> 2. added policy for using Transformation plugin (Client: JSON, Server:XML). >> >> 3. Published as Public API. >> >> >> >> Through Rest Client -> Called Public API (POST -> content type as >> application/json and json input), however it failed with 500 error (able >> to read stacktrace - suggest input is not passed correctly). >> >> >> >> With more debugging: As there are no logs from Transformation plugin, >> have added sysouts and found that JsonToXmlTransformer is NOT being >> called for input (json -> xml) transformation, however, on response >> XmlToJsonTransformer is being called successfully. >> >> >> >> Kindly suggest. >> >> >> >> Thanks & Regards, >> >> Ashish Patel >> >> >> >> "Scientists investigate that which already is;Engineers create that >> which has never been." - Albert Einstein. >> >> >> >> >> ------------------------------------------------------------------------ >> Disclaimer: This message may contain privileged and confidential >> information and is solely for the use of intended recipient. The views >> expressed in this email are those of the sender and not Future Group's. >> The recipient should check this email and attachments for the presence >> of viruses. Future Group accepts no liability for any damage caused by >> any virus transmitted by this email. Future Group may monitor and record >> all emails. >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > From eric.wittmann at redhat.com Mon Jun 13 12:11:10 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 13 Jun 2016 12:11:10 -0400 Subject: [Apiman-user] Different API version-Contract Creation In-Reply-To: References: Message-ID: <3eea952f-592d-9c3b-5608-8fa3f4ece26f@redhat.com> If I understand correctly, then this is most likely a bug. Could you write up a JIRA issue for this? Perhaps mark it as a Blocker if possible. I will try to reproduce it asap. In the meantime, you could use the alternate approach to finding APIs and creating contracts. See the "Search for APIs to consume" link on the details page (in the top box) for a given Client App: http://imgur.com/Q70IIxJ -Eric On 6/10/2016 1:38 PM, Mohan Joyappa wrote: > Hi Eric, > > > > I have following scenario. I have two version of same API. Version 1 of > API is the base version and version 2 of API has some additional changes > to it (like some extra policy and what not). When I try to create a > contract for my clientApp, I get to select what version of API I need to > use as shown below > > > > > > > > > > So if I select API version 1.0 and click on OK, contract is always > created with latest version of API no matter what other older version of > API you have. > > > > > > Is this intentionally designed? If yes, the first step to choose a > particular API version while creating a contract is somewhat misleading > to me. > > > > > > Best > > Mohan Joyappa > > > > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From mjoyappa at EBSCO.COM Mon Jun 13 13:32:27 2016 From: mjoyappa at EBSCO.COM (Mohan Joyappa) Date: Mon, 13 Jun 2016 17:32:27 +0000 Subject: [Apiman-user] Different API version-Contract Creation In-Reply-To: <3eea952f-592d-9c3b-5608-8fa3f4ece26f@redhat.com> References: <3eea952f-592d-9c3b-5608-8fa3f4ece26f@redhat.com> Message-ID: Thanks Eric. APIMAN-1187 has been created Best Mohan -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: Monday, June 13, 2016 12:11 PM To: Mohan Joyappa ; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Different API version-Contract Creation If I understand correctly, then this is most likely a bug. Could you write up a JIRA issue for this? Perhaps mark it as a Blocker if possible. I will try to reproduce it asap. In the meantime, you could use the alternate approach to finding APIs and creating contracts. See the "Search for APIs to consume" link on the details page (in the top box) for a given Client App: http://imgur.com/Q70IIxJ -Eric On 6/10/2016 1:38 PM, Mohan Joyappa wrote: > Hi Eric, > > > > I have following scenario. I have two version of same API. Version 1 > of API is the base version and version 2 of API has some additional > changes to it (like some extra policy and what not). When I try to > create a contract for my clientApp, I get to select what version of > API I need to use as shown below > > > > > > > > > > So if I select API version 1.0 and click on OK, contract is always > created with latest version of API no matter what other older version > of API you have. > > > > > > Is this intentionally designed? If yes, the first step to choose a > particular API version while creating a contract is somewhat > misleading to me. > > > > > > Best > > Mohan Joyappa > > > > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160613/78b52983/attachment-0001.html From Ashish.Patel at futureretail.in Tue Jun 14 01:32:23 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Tue, 14 Jun 2016 11:02:23 +0530 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE10@DC-SRV-MBX-08> Thanks Eric, this helps a lot. We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). Thanks & Regards, Ashish Patel (M) +91 93270 15128 "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 13 June 2016 21:32 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] apiman Production Deployment Hi Ashish. Sorry for the delay in my response. I'll do my best to answer your questions. > 1. We want to have single API Manager for our consumers in "on-premise" > and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " > Apiman Gateway" in on-premise and couple of on cloud ? If yes, what > would be possible deployment architecture ? (best place to put RDBMS > on-prem/cloud, best place to put keyclock server/ ES server..etc ?) There are a very large number of choices here! It depends a lot on exactly what you're trying to achieve. Two different configurations jump to mind. Config 1 - A single "logical" API Gateway In this configuration, every API Gateway node (regardless of whether it is on-prem or in the cloud) shares a common data store. This allows every node to service the *same* set of APIs. In this case the single gateway storage (database or elasticsearch) will need to be accessible by all gateway nodes. In the UI, there is only *one* gateway, so there are no extra steps that API developers need take when publishing APIs. However, every Gateway node must be able to access every back-end endpoint at the same URL. Config 2 - Two "logical" API Gateways In this config, the on-prem gateway node(s) and the in-cloud gateway node(s) each have their own gateway storage (database and/or elasticsearch). When set up this way, the API Manager must be configured with *both* gateways, and each gateway should have a sensible name, such as "On Premise Gateway" and "Cloud Gateway". In the UI, the API Developers will need to choose which of the two API Gateways their API should be published to (they must choose *at least one* gateway). This allows different gateways to service different APIs, offering more flexibility. > 2. production guide having wildfly version, however we would prefer > tomcat / vert.x, any specific guide changes for tomcat / vert.x ? We only have documentation for Wildfly at the moment, but if you wish to use Tomcat it should be relatively simple to extrapolate the documentation to that platform. The vert.x implementation is experimental at this point, and should not be used in production. > 3. Can we have companies using apiman on production ? any benchmarking > stats and case study material ? I'm sorry to say that we don't currently have reference users or production benchmarks yet. These materials will surely be coming in the future as the project matures. Thanks! -Eric Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From Ashish.Patel at futureretail.in Tue Jun 14 01:57:12 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Tue, 14 Jun 2016 11:27:12 +0530 Subject: [Apiman-user] Transformer policy plugin issue In-Reply-To: References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E71BFFC@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE7E@DC-SRV-MBX-08> Yes, sure will definitely try the custom plugin + contribution to OSS. On guiding part, below are my initial queries. 1. Currently XML Transformation plugin definition does not mention that it only works one way -> from backendAPI response to ClientApp. Ideally it should also work from ClientApp -> backendAPI request. I thought this is a bug and so logged as bug, if not then in Plugin Description it should mention that it only work for backendAPI responses. 2. SOAP is XML and so XML<->JSON should work for SOAP (as XML) message. Can you please elaborate more on the difference of transformation for SOAP/XML ? i.e. <> 1234567890 <> { "soapenv:Envelope": { "soapenv:Body": { "urn:CustSearchReq": { "Mobile": "1234567890" } "xmlns:soapenv": "http://schemas.xmlsoap.org/soap/envelope/" "xmlns:urn":"urn:com:ia:eai:crm:cust:search" "soapenv:Header": "" } } } 3. I have gone through http://www.apiman.io/latest/developer-guide.html, for environment setup (to start with CustomPlugin). Kindly guide if anything on top of this. Thanks & Regards, Ashish Patel "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 13 June 2016 21:37 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] Transformer policy plugin issue SOAP<->JSON conversion is, in my opinion, a separate feature request. I have updated APIMAN-1182 to reflect that. I think this is a valuable feature to have, but given our current backlog of work I cant' give you any great idea of when it might be implemented. If you are up for it, it should be very possible to implement this functionality yourself as a custom policy. Perhaps that could serve as a contribution back to the community which could then be improved upon for the benefit of all! :) I'd be happy to provide some direction on such an effort. If that's not possible, we'll have to get to it as soon as we can. :) -Eric On 6/13/2016 1:04 AM, Ashish Patel wrote: > Thanks Eric for quick response. > > We want SOAP to JSON for our legacy Apps (like SAP ECC) which can't expose JSON. We want to have standard input for all our Mobile / APIs as JSON and so we need this conversion (though not 100% REST compatible). > > Sure, APIMAN-1182, opened. > > Thanks & Regards, > Ashish Patel > > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 10 June 2016 20:29 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] Transformer policy plugin issue > > The transformation policy may not be suitable for converting soap to > json. Soap is xml, for sure, but it has a pretty specific format. I'm > not sure a direct mapping with JSON is possible, so you might need a > custom plugin policy to accomplish this. > > That said, I would have expected the JsonToXmlTransformer to at least be > invoked on the request payload, even if the results aren't exactly what > is needed. > > Can you please open a JIRA for this bug? > > https://issues.jboss.org/projects/APIMAN > > Thanks, > > Eric > > On 6/9/2016 8:45 AM, Ashish Patel wrote: >> Hi, >> >> >> >> We are facing issue while using Transformer plugin. >> >> >> >> Scenario: We have SOAP Service in backend and want to expose as JSON to >> client App. >> >> >> >> 1. we have registered the SOAP service in Implementation (with Basic Auth). >> >> 2. added policy for using Transformation plugin (Client: JSON, Server:XML). >> >> 3. Published as Public API. >> >> >> >> Through Rest Client -> Called Public API (POST -> content type as >> application/json and json input), however it failed with 500 error (able >> to read stacktrace - suggest input is not passed correctly). >> >> >> >> With more debugging: As there are no logs from Transformation plugin, >> have added sysouts and found that JsonToXmlTransformer is NOT being >> called for input (json -> xml) transformation, however, on response >> XmlToJsonTransformer is being called successfully. >> >> >> >> Kindly suggest. >> >> >> >> Thanks & Regards, >> >> Ashish Patel >> >> >> >> "Scientists investigate that which already is;Engineers create that >> which has never been." - Albert Einstein. >> >> >> >> >> ------------------------------------------------------------------------ >> Disclaimer: This message may contain privileged and confidential >> information and is solely for the use of intended recipient. The views >> expressed in this email are those of the sender and not Future Group's. >> The recipient should check this email and attachments for the presence >> of viruses. Future Group accepts no liability for any damage caused by >> any virus transmitted by this email. Future Group may monitor and record >> all emails. >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From Ashish.Patel at futureretail.in Tue Jun 14 07:35:50 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Tue, 14 Jun 2016 17:05:50 +0530 Subject: [Apiman-user] apiman Production Deployment References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BC3D8@DC-SRV-MBX-08> Hi Eric, In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ? http://postimg.org/image/qzll2wwhz/ Thanks & Regards, Ashish Patel -----Original Message----- From: Ashish Patel Sent: 14 June 2016 11:02 To: 'Eric Wittmann'; apiman-user at lists.jboss.org Subject: RE: [Apiman-user] apiman Production Deployment Thanks Eric, this helps a lot. We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). Thanks & Regards, Ashish Patel (M) +91 93270 15128 "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 13 June 2016 21:32 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] apiman Production Deployment Hi Ashish. Sorry for the delay in my response. I'll do my best to answer your questions. > 1. We want to have single API Manager for our consumers in "on-premise" > and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " > Apiman Gateway" in on-premise and couple of on cloud ? If yes, what > would be possible deployment architecture ? (best place to put RDBMS > on-prem/cloud, best place to put keyclock server/ ES server..etc ?) There are a very large number of choices here! It depends a lot on exactly what you're trying to achieve. Two different configurations jump to mind. Config 1 - A single "logical" API Gateway In this configuration, every API Gateway node (regardless of whether it is on-prem or in the cloud) shares a common data store. This allows every node to service the *same* set of APIs. In this case the single gateway storage (database or elasticsearch) will need to be accessible by all gateway nodes. In the UI, there is only *one* gateway, so there are no extra steps that API developers need take when publishing APIs. However, every Gateway node must be able to access every back-end endpoint at the same URL. Config 2 - Two "logical" API Gateways In this config, the on-prem gateway node(s) and the in-cloud gateway node(s) each have their own gateway storage (database and/or elasticsearch). When set up this way, the API Manager must be configured with *both* gateways, and each gateway should have a sensible name, such as "On Premise Gateway" and "Cloud Gateway". In the UI, the API Developers will need to choose which of the two API Gateways their API should be published to (they must choose *at least one* gateway). This allows different gateways to service different APIs, offering more flexibility. > 2. production guide having wildfly version, however we would prefer > tomcat / vert.x, any specific guide changes for tomcat / vert.x ? We only have documentation for Wildfly at the moment, but if you wish to use Tomcat it should be relatively simple to extrapolate the documentation to that platform. The vert.x implementation is experimental at this point, and should not be used in production. > 3. Can we have companies using apiman on production ? any benchmarking > stats and case study material ? I'm sorry to say that we don't currently have reference users or production benchmarks yet. These materials will surely be coming in the future as the project matures. Thanks! -Eric Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From eric.wittmann at redhat.com Tue Jun 14 08:49:43 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 14 Jun 2016 08:49:43 -0400 Subject: [Apiman-user] Transformer policy plugin issue In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE7E@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E69AF99@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E71BFFC@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE7E@DC-SRV-MBX-08> Message-ID: <2921eb3d-555a-1aef-5aad-a7b617af8714@redhat.com> Regarding #1 - yes good point. If the transformation policy is not working for the input, then it is broken and we need to fix it. I will create a new jira for this (I shouldn't have changed yours, sorry about that). https://issues.jboss.org/browse/APIMAN-1188 Regarding #2 - SOAP uses namespaces and attributes which I doubt will get transformed in a sensible way with the generic transformation policy (e.g. the 'actor' attribute on a header). I think a transformer that understands that it's dealing with SOAP will result in a much better implementation. As for #3 - the Developer Guide should be pretty thorough. Here is a blog post that might help as well: http://www.apiman.io/blog/micro-services/development/2015/11/12/micro-services.html -Eric On 6/14/2016 1:57 AM, Ashish Patel wrote: > Yes, sure will definitely try the custom plugin + contribution to OSS. > > On guiding part, below are my initial queries. > > 1. Currently XML Transformation plugin definition does not mention that it only works one way -> from backendAPI response to ClientApp. Ideally it should also work from ClientApp -> backendAPI request. I thought this is a bug and so logged as bug, if not then in Plugin Description it should mention that it only work for backendAPI responses. > > 2. SOAP is XML and so XML<->JSON should work for SOAP (as XML) message. Can you please elaborate more on the difference of transformation for SOAP/XML ? > > i.e. <> > > > > > 1234567890 > > > > > > <> > > { > "soapenv:Envelope": { > "soapenv:Body": { > "urn:CustSearchReq": { "Mobile": "1234567890" } > "xmlns:soapenv": "http://schemas.xmlsoap.org/soap/envelope/" > "xmlns:urn":"urn:com:ia:eai:crm:cust:search" > "soapenv:Header": "" > } > } > } > > 3. I have gone through http://www.apiman.io/latest/developer-guide.html, for environment setup (to start with CustomPlugin). Kindly guide if anything on top of this. > > Thanks & Regards, > Ashish Patel > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 13 June 2016 21:37 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] Transformer policy plugin issue > > SOAP<->JSON conversion is, in my opinion, a separate feature request. I > have updated APIMAN-1182 to reflect that. > > I think this is a valuable feature to have, but given our current > backlog of work I cant' give you any great idea of when it might be > implemented. > > If you are up for it, it should be very possible to implement this > functionality yourself as a custom policy. Perhaps that could serve as > a contribution back to the community which could then be improved upon > for the benefit of all! :) > > I'd be happy to provide some direction on such an effort. > > If that's not possible, we'll have to get to it as soon as we can. :) > > -Eric > > > On 6/13/2016 1:04 AM, Ashish Patel wrote: >> Thanks Eric for quick response. >> >> We want SOAP to JSON for our legacy Apps (like SAP ECC) which can't expose JSON. We want to have standard input for all our Mobile / APIs as JSON and so we need this conversion (though not 100% REST compatible). >> >> Sure, APIMAN-1182, opened. >> >> Thanks & Regards, >> Ashish Patel >> >> >> "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. >> >> >> >> -----Original Message----- >> From: Eric Wittmann [mailto:eric.wittmann at redhat.com] >> Sent: 10 June 2016 20:29 >> To: Ashish Patel; apiman-user at lists.jboss.org >> Subject: Re: [Apiman-user] Transformer policy plugin issue >> >> The transformation policy may not be suitable for converting soap to >> json. Soap is xml, for sure, but it has a pretty specific format. I'm >> not sure a direct mapping with JSON is possible, so you might need a >> custom plugin policy to accomplish this. >> >> That said, I would have expected the JsonToXmlTransformer to at least be >> invoked on the request payload, even if the results aren't exactly what >> is needed. >> >> Can you please open a JIRA for this bug? >> >> https://issues.jboss.org/projects/APIMAN >> >> Thanks, >> >> Eric >> >> On 6/9/2016 8:45 AM, Ashish Patel wrote: >>> Hi, >>> >>> >>> >>> We are facing issue while using Transformer plugin. >>> >>> >>> >>> Scenario: We have SOAP Service in backend and want to expose as JSON to >>> client App. >>> >>> >>> >>> 1. we have registered the SOAP service in Implementation (with Basic Auth). >>> >>> 2. added policy for using Transformation plugin (Client: JSON, Server:XML). >>> >>> 3. Published as Public API. >>> >>> >>> >>> Through Rest Client -> Called Public API (POST -> content type as >>> application/json and json input), however it failed with 500 error (able >>> to read stacktrace - suggest input is not passed correctly). >>> >>> >>> >>> With more debugging: As there are no logs from Transformation plugin, >>> have added sysouts and found that JsonToXmlTransformer is NOT being >>> called for input (json -> xml) transformation, however, on response >>> XmlToJsonTransformer is being called successfully. >>> >>> >>> >>> Kindly suggest. >>> >>> >>> >>> Thanks & Regards, >>> >>> Ashish Patel >>> >>> >>> >>> "Scientists investigate that which already is;Engineers create that >>> which has never been." - Albert Einstein. >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> Disclaimer: This message may contain privileged and confidential >>> information and is solely for the use of intended recipient. The views >>> expressed in this email are those of the sender and not Future Group's. >>> The recipient should check this email and attachments for the presence >>> of viruses. Future Group accepts no liability for any damage caused by >>> any virus transmitted by this email. Future Group may monitor and record >>> all emails. >>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >> >> Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. >> > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > From eric.wittmann at redhat.com Tue Jun 14 08:56:09 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 14 Jun 2016 08:56:09 -0400 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE10@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE10@DC-SRV-MBX-08> Message-ID: If you choose to go with two logical gateways, then API developers will need to select one of them (or both) in the API Manager UI. This allows the developer to choose which of the Gateways to publish to. In your described scenario I definitely think I would recommend this approach. If you want two separated Gateways but do not want API developers to have to pick between them, then we would need to find an alternative solution. Perhaps something custom - something that sits in between the API Manager and the (multiple) API Gateways so that when an API is published, it gets published to both gateways. That's not something we support right now. -Eric On 6/14/2016 1:32 AM, Ashish Patel wrote: > Thanks Eric, this helps a lot. > > We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. > > With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). > > Thanks & Regards, > Ashish Patel > (M) +91 93270 15128 > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 13 June 2016 21:32 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > Sorry for the delay in my response. I'll do my best to answer your > questions. > >> 1. We want to have single API Manager for our consumers in "on-premise" >> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >> would be possible deployment architecture ? (best place to put RDBMS >> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) > > There are a very large number of choices here! It depends a lot on > exactly what you're trying to achieve. Two different configurations > jump to mind. > > Config 1 - A single "logical" API Gateway > > In this configuration, every API Gateway node (regardless of whether it > is on-prem or in the cloud) shares a common data store. This allows > every node to service the *same* set of APIs. In this case the single > gateway storage (database or elasticsearch) will need to be accessible > by all gateway nodes. > > In the UI, there is only *one* gateway, so there are no extra steps that > API developers need take when publishing APIs. However, every Gateway > node must be able to access every back-end endpoint at the same URL. > > > Config 2 - Two "logical" API Gateways > > In this config, the on-prem gateway node(s) and the in-cloud gateway > node(s) each have their own gateway storage (database and/or > elasticsearch). When set up this way, the API Manager must be > configured with *both* gateways, and each gateway should have a sensible > name, such as "On Premise Gateway" and "Cloud Gateway". > > In the UI, the API Developers will need to choose which of the two API > Gateways their API should be published to (they must choose *at least > one* gateway). This allows different gateways to service different > APIs, offering more flexibility. > >> 2. production guide having wildfly version, however we would prefer >> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? > > We only have documentation for Wildfly at the moment, but if you wish to > use Tomcat it should be relatively simple to extrapolate the > documentation to that platform. The vert.x implementation is > experimental at this point, and should not be used in production. > >> 3. Can we have companies using apiman on production ? any benchmarking >> stats and case study material ? > > I'm sorry to say that we don't currently have reference users or > production benchmarks yet. These materials will surely be coming in the > future as the project matures. > > Thanks! > > -Eric > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > From Ashish.Patel at futureretail.in Wed Jun 15 07:40:01 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Wed, 15 Jun 2016 17:10:01 +0530 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BBE10@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BCD59@DC-SRV-MBX-08> Hi Eric, No issue with two separate Gateway for API Developers, they shall choose appropriate one. Had query on the overall deployment architecture, sent yesterday on same subject. Appreciate if you can look into it and suggest ? Thanks & Regards, Ashish Patel "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 14 June 2016 18:26 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] apiman Production Deployment If you choose to go with two logical gateways, then API developers will need to select one of them (or both) in the API Manager UI. This allows the developer to choose which of the Gateways to publish to. In your described scenario I definitely think I would recommend this approach. If you want two separated Gateways but do not want API developers to have to pick between them, then we would need to find an alternative solution. Perhaps something custom - something that sits in between the API Manager and the (multiple) API Gateways so that when an API is published, it gets published to both gateways. That's not something we support right now. -Eric On 6/14/2016 1:32 AM, Ashish Patel wrote: > Thanks Eric, this helps a lot. > > We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. > > With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). > > Thanks & Regards, > Ashish Patel > (M) +91 93270 15128 > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 13 June 2016 21:32 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > Sorry for the delay in my response. I'll do my best to answer your > questions. > >> 1. We want to have single API Manager for our consumers in "on-premise" >> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >> would be possible deployment architecture ? (best place to put RDBMS >> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) > > There are a very large number of choices here! It depends a lot on > exactly what you're trying to achieve. Two different configurations > jump to mind. > > Config 1 - A single "logical" API Gateway > > In this configuration, every API Gateway node (regardless of whether it > is on-prem or in the cloud) shares a common data store. This allows > every node to service the *same* set of APIs. In this case the single > gateway storage (database or elasticsearch) will need to be accessible > by all gateway nodes. > > In the UI, there is only *one* gateway, so there are no extra steps that > API developers need take when publishing APIs. However, every Gateway > node must be able to access every back-end endpoint at the same URL. > > > Config 2 - Two "logical" API Gateways > > In this config, the on-prem gateway node(s) and the in-cloud gateway > node(s) each have their own gateway storage (database and/or > elasticsearch). When set up this way, the API Manager must be > configured with *both* gateways, and each gateway should have a sensible > name, such as "On Premise Gateway" and "Cloud Gateway". > > In the UI, the API Developers will need to choose which of the two API > Gateways their API should be published to (they must choose *at least > one* gateway). This allows different gateways to service different > APIs, offering more flexibility. > >> 2. production guide having wildfly version, however we would prefer >> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? > > We only have documentation for Wildfly at the moment, but if you wish to > use Tomcat it should be relatively simple to extrapolate the > documentation to that platform. The vert.x implementation is > experimental at this point, and should not be used in production. > >> 3. Can we have companies using apiman on production ? any benchmarking >> stats and case study material ? > > I'm sorry to say that we don't currently have reference users or > production benchmarks yet. These materials will surely be coming in the > future as the project matures. > > Thanks! > > -Eric > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From cstolte at ebsco.com Wed Jun 15 10:59:04 2016 From: cstolte at ebsco.com (Christopher Stolte) Date: Wed, 15 Jun 2016 14:59:04 +0000 Subject: [Apiman-user] building apiman on Redhat Message-ID: Hello, I am trying to build apiman-1.2.6.Final on Redhat. Server details: $ uname -or 3.10.0-229.el7.x86_64 GNU/Linux $ java -version openjdk version "1.8.0_91" The build fails at this point: [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install node and npm) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Installing node version v5.6.0 [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting Node.js files in node_tmp [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Installed node locally. [INFO] Installing npm version 3.6.0 [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting NPM files in node/ [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules [INFO] Installed NPM locally. [INFO] [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. Node/npm appear to be globally installed: $ npm -v 2.15.1 $ node -v v4.4.3 I then tried to execute that npm command from the stated directory, and got this: $ cd manager/ui/war $ npm install --color=false npm WARN peerDependencies The peer dependency marked@^0.3.3 included from marked-terminal will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN prefer global marked at 0.3.5 should be installed with -g npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included from grunt-contrib-cssmin will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.1 included from grunt-jekyll will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.5 included from grunt-contrib-less will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-uglify will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-connect will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-watch will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm ERR! Linux 3.10.0-229.el7.x86_64 npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" npm ERR! node v4.4.3 npm ERR! npm v2.15.1 npm ERR! code EBADPLATFORM npm ERR! notsup Unsupported npm ERR! notsup Not compatible with your operating system or architecture: fsevents at 1.0.8 npm ERR! notsup Valid OS: darwin npm ERR! notsup Valid Arch: any npm ERR! notsup Actual OS: linux npm ERR! notsup Actual Arch: x64 npm ERR! Please include the following file with any support request: npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log Does anyone have an idea as to what is going on here? I see some threads about the maven plugin that installs node/npm locally (https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's going on here. I'm especially confused about versions, since the plugin installed versions [5.6.0/3.6.0] locally but the above error message is referencing the globally installed versions [4.4.3/2.15.1]. Any help much appreciated! Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160615/73c02f15/attachment-0001.html From ryordan at redhat.com Wed Jun 15 13:21:53 2016 From: ryordan at redhat.com (Rachel Yordan) Date: Wed, 15 Jun 2016 13:21:53 -0400 Subject: [Apiman-user] building apiman on Redhat In-Reply-To: References: Message-ID: Hey Chris, When you run `$ npm install` or even `$ node -v` you are using the globally installed binary as opposed to the local one, even if you are within the directory, as you can see here: npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" The deprecation warning at the end of the build log should not be enough to cause a build failure. To get a more detailed error regarding the build failure I'd try using the local binary from within the `war` directory you were in with `$ node/npm install --color=false`. You can also test that it's using the correct binary with `$ node/npm -v` or `$ node/node -v`. What is causing the build to fail could be several things, but I always recommend starting with a clean slate before each test build -- try running the following before triggering your build again: $ rm -rf node_modules/ $ npm cache clean Feel free to ping me on IRC if that doesn't help you get a better idea of what's going on. Hope it helps! :) Rachel Yord?n IRC: ryordan GH: @kahboom On Wed, Jun 15, 2016 at 10:59 AM, Christopher Stolte wrote: > Hello, > > > I am trying to build apiman-1.2.6.Final on Redhat. Server details: > > > $ uname -or > > 3.10.0-229.el7.x86_64 GNU/Linux > > > $ java -version > > openjdk version "1.8.0_91" > > > The build fails at this point: > > > [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install node > and npm) @ apiman-manager-ui-war --- > > [INFO] Found proxies: [] > > [INFO] Installing node version v5.6.0 > > [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp > > [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz > > [INFO] No proxies configured > > [INFO] No proxy was configured, downloading directly > > [INFO] Extracting Node.js files in node_tmp > > [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp > > [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node > > [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp > > [INFO] Installed node locally. > > [INFO] Installing npm version 3.6.0 > > [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz > > [INFO] No proxies configured > > [INFO] No proxy was configured, downloading directly > > [INFO] Extracting NPM files in node/ > > [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules > > [INFO] Installed NPM locally. > > [INFO] > > [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- > > [INFO] Found proxies: [] > > [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war > > [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. > > > Node/npm appear to be globally installed: > > > $ npm -v > > 2.15.1 > > $ node -v > > v4.4.3 > > > I then tried to execute that npm command from the stated directory, and > got this: > > > $ cd manager/ui/war > > $ npm install --color=false > > npm WARN peerDependencies The peer dependency marked@^0.3.3 included from > marked-terminal will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN prefer global marked at 0.3.5 should be installed with -g > > npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will > fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as > soon as possible. Use 'npm ls graceful-fs' to find it in the tree. > > npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included from > grunt-contrib-cssmin will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN peerDependencies The peer dependency grunt@~0.4.1 included from > grunt-jekyll will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN peerDependencies The peer dependency grunt@~0.4.5 included from > grunt-contrib-less will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from > grunt-contrib-uglify will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from > grunt-contrib-connect will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer maintained. > Upgrade to lodash@^4.0.0. > > npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from > grunt-contrib-watch will no > > npm WARN peerDependencies longer be automatically installed to fulfill the > peerDependency > > npm WARN peerDependencies in npm 3+. Your application will need to depend > on it explicitly. > > npm ERR! Linux 3.10.0-229.el7.x86_64 > > npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" > "--color=false" > > npm ERR! node v4.4.3 > > npm ERR! npm v2.15.1 > > npm ERR! code EBADPLATFORM > > npm ERR! notsup Unsupported > > npm ERR! notsup Not compatible with your operating system or architecture: > fsevents at 1.0.8 > > npm ERR! notsup Valid OS: darwin > > npm ERR! notsup Valid Arch: any > > npm ERR! notsup Actual OS: linux > > npm ERR! notsup Actual Arch: x64 > > npm ERR! Please include the following file with any support request: > > npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log > > Does anyone have an idea as to what is going on here? I see some threads > about the maven plugin that installs node/npm locally ( > https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's > going on here. I'm especially confused about versions, since the plugin > installed versions [5.6.0/3.6.0] locally but the above error message is > referencing the globally installed versions [4.4.3/2.15.1]. > > > Any help much appreciated! > > Chris > > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160615/271c636b/attachment.html From eric.wittmann at redhat.com Wed Jun 15 14:21:01 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 15 Jun 2016 14:21:01 -0400 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BC3D8@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BC3D8@DC-SRV-MBX-08> Message-ID: Hi Ashish. I'm a little bit confused by some of the box labeling I think. Some of the boxes in the top half of the diagram are labelled "Cloud" when I expected them to be labelled On-Premise. Is that intentional or copy/paste errors? -Eric On 6/14/2016 7:35 AM, Ashish Patel wrote: > Hi Eric, > > In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ? > > http://postimg.org/image/qzll2wwhz/ > > Thanks & Regards, > Ashish Patel > > -----Original Message----- > From: Ashish Patel > Sent: 14 June 2016 11:02 > To: 'Eric Wittmann'; apiman-user at lists.jboss.org > Subject: RE: [Apiman-user] apiman Production Deployment > > Thanks Eric, this helps a lot. > > We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. > > With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). > > Thanks & Regards, > Ashish Patel > (M) +91 93270 15128 > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 13 June 2016 21:32 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > Sorry for the delay in my response. I'll do my best to answer your > questions. > >> 1. We want to have single API Manager for our consumers in "on-premise" >> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >> would be possible deployment architecture ? (best place to put RDBMS >> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) > > There are a very large number of choices here! It depends a lot on > exactly what you're trying to achieve. Two different configurations > jump to mind. > > Config 1 - A single "logical" API Gateway > > In this configuration, every API Gateway node (regardless of whether it > is on-prem or in the cloud) shares a common data store. This allows > every node to service the *same* set of APIs. In this case the single > gateway storage (database or elasticsearch) will need to be accessible > by all gateway nodes. > > In the UI, there is only *one* gateway, so there are no extra steps that > API developers need take when publishing APIs. However, every Gateway > node must be able to access every back-end endpoint at the same URL. > > > Config 2 - Two "logical" API Gateways > > In this config, the on-prem gateway node(s) and the in-cloud gateway > node(s) each have their own gateway storage (database and/or > elasticsearch). When set up this way, the API Manager must be > configured with *both* gateways, and each gateway should have a sensible > name, such as "On Premise Gateway" and "Cloud Gateway". > > In the UI, the API Developers will need to choose which of the two API > Gateways their API should be published to (they must choose *at least > one* gateway). This allows different gateways to service different > APIs, offering more flexibility. > >> 2. production guide having wildfly version, however we would prefer >> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? > > We only have documentation for Wildfly at the moment, but if you wish to > use Tomcat it should be relatively simple to extrapolate the > documentation to that platform. The vert.x implementation is > experimental at this point, and should not be used in production. > >> 3. Can we have companies using apiman on production ? any benchmarking >> stats and case study material ? > > I'm sorry to say that we don't currently have reference users or > production benchmarks yet. These materials will surely be coming in the > future as the project matures. > > Thanks! > > -Eric > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > From cstolte at ebsco.com Wed Jun 15 14:47:07 2016 From: cstolte at ebsco.com (Christopher Stolte) Date: Wed, 15 Jun 2016 18:47:07 +0000 Subject: [Apiman-user] building apiman on Redhat In-Reply-To: References: , Message-ID: Hi Rachel, Thanks for your response. There are a few things here which are confusing me: 1. the build log says "Running 'npm install --color=false' in /var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war" is that correct? (it seems like it's trying to run a globally installed npm...) If it's trying to use a locally installed npm, why isn't is using a relative path to it? 2. If I change manager/ui/war/node/npm so that NODE_EXE=./node/node (instead of "node") it succeeds. 3. The failing job is being run by Jenkins, and the Jenkins user has no node on it's path. But if I run the build as a different user who does, it works. It seems that the plugin which installs nodejs locally, or some subsequent part of the build process, isn't referring to them correctly (and thus is dependent on a globally installed node in order to work). Any insight? For what it's worth I can build the exact same source, from the same repo, with the same command, on my mac, which has node and npm installed globally. Thanks, Chris ________________________________ From: Rachel Yordan Sent: Wednesday, June 15, 2016 1:21:53 PM To: Christopher Stolte Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] building apiman on Redhat Hey Chris, When you run `$ npm install` or even `$ node -v` you are using the globally installed binary as opposed to the local one, even if you are within the directory, as you can see here: npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" The deprecation warning at the end of the build log should not be enough to cause a build failure. To get a more detailed error regarding the build failure I'd try using the local binary from within the `war` directory you were in with `$ node/npm install --color=false`. You can also test that it's using the correct binary with `$ node/npm -v` or `$ node/node -v`. What is causing the build to fail could be several things, but I always recommend starting with a clean slate before each test build -- try running the following before triggering your build again: $ rm -rf node_modules/ $ npm cache clean Feel free to ping me on IRC if that doesn't help you get a better idea of what's going on. Hope it helps! :) Rachel Yord?n IRC: ryordan GH: @kahboom On Wed, Jun 15, 2016 at 10:59 AM, Christopher Stolte > wrote: Hello, I am trying to build apiman-1.2.6.Final on Redhat. Server details: $ uname -or 3.10.0-229.el7.x86_64 GNU/Linux $ java -version openjdk version "1.8.0_91" The build fails at this point: [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install node and npm) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Installing node version v5.6.0 [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting Node.js files in node_tmp [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Installed node locally. [INFO] Installing npm version 3.6.0 [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting NPM files in node/ [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules [INFO] Installed NPM locally. [INFO] [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. Node/npm appear to be globally installed: $ npm -v 2.15.1 $ node -v v4.4.3 I then tried to execute that npm command from the stated directory, and got this: $ cd manager/ui/war $ npm install --color=false npm WARN peerDependencies The peer dependency marked@^0.3.3 included from marked-terminal will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN prefer global marked at 0.3.5 should be installed with -g npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included from grunt-contrib-cssmin will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.1 included from grunt-jekyll will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.5 included from grunt-contrib-less will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-uglify will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-connect will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-watch will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm ERR! Linux 3.10.0-229.el7.x86_64 npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" npm ERR! node v4.4.3 npm ERR! npm v2.15.1 npm ERR! code EBADPLATFORM npm ERR! notsup Unsupported npm ERR! notsup Not compatible with your operating system or architecture: fsevents at 1.0.8 npm ERR! notsup Valid OS: darwin npm ERR! notsup Valid Arch: any npm ERR! notsup Actual OS: linux npm ERR! notsup Actual Arch: x64 npm ERR! Please include the following file with any support request: npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log Does anyone have an idea as to what is going on here? I see some threads about the maven plugin that installs node/npm locally (https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's going on here. I'm especially confused about versions, since the plugin installed versions [5.6.0/3.6.0] locally but the above error message is referencing the globally installed versions [4.4.3/2.15.1]. Any help much appreciated! Chris _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160615/2004f55a/attachment-0001.html From Ashish.Patel at futureretail.in Thu Jun 16 03:54:11 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Thu, 16 Jun 2016 13:24:11 +0530 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BC3D8@DC-SRV-MBX-08> Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E8227E0@DC-SRV-MBX-08> Hi Eric, Oh, yes copy paste. Modified it. Kindly suggest. https://postimg.org/image/ebydokdbl/ One specific query on KeyCloak : can we have only one - KeyCloak (OnPrem) ? or is it mandatory to keep OnPrem and Cloud ? Thanks & Regards, Ashish Patel "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. -----Original Message----- From: Eric Wittmann [mailto:eric.wittmann at redhat.com] Sent: 15 June 2016 23:51 To: Ashish Patel; apiman-user at lists.jboss.org Subject: Re: [Apiman-user] apiman Production Deployment Hi Ashish. I'm a little bit confused by some of the box labeling I think. Some of the boxes in the top half of the diagram are labelled "Cloud" when I expected them to be labelled On-Premise. Is that intentional or copy/paste errors? -Eric On 6/14/2016 7:35 AM, Ashish Patel wrote: > Hi Eric, > > In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ? > > http://postimg.org/image/qzll2wwhz/ > > Thanks & Regards, > Ashish Patel > > -----Original Message----- > From: Ashish Patel > Sent: 14 June 2016 11:02 > To: 'Eric Wittmann'; apiman-user at lists.jboss.org > Subject: RE: [Apiman-user] apiman Production Deployment > > Thanks Eric, this helps a lot. > > We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. > > With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). > > Thanks & Regards, > Ashish Patel > (M) +91 93270 15128 > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 13 June 2016 21:32 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > Sorry for the delay in my response. I'll do my best to answer your > questions. > >> 1. We want to have single API Manager for our consumers in "on-premise" >> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >> would be possible deployment architecture ? (best place to put RDBMS >> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) > > There are a very large number of choices here! It depends a lot on > exactly what you're trying to achieve. Two different configurations > jump to mind. > > Config 1 - A single "logical" API Gateway > > In this configuration, every API Gateway node (regardless of whether it > is on-prem or in the cloud) shares a common data store. This allows > every node to service the *same* set of APIs. In this case the single > gateway storage (database or elasticsearch) will need to be accessible > by all gateway nodes. > > In the UI, there is only *one* gateway, so there are no extra steps that > API developers need take when publishing APIs. However, every Gateway > node must be able to access every back-end endpoint at the same URL. > > > Config 2 - Two "logical" API Gateways > > In this config, the on-prem gateway node(s) and the in-cloud gateway > node(s) each have their own gateway storage (database and/or > elasticsearch). When set up this way, the API Manager must be > configured with *both* gateways, and each gateway should have a sensible > name, such as "On Premise Gateway" and "Cloud Gateway". > > In the UI, the API Developers will need to choose which of the two API > Gateways their API should be published to (they must choose *at least > one* gateway). This allows different gateways to service different > APIs, offering more flexibility. > >> 2. production guide having wildfly version, however we would prefer >> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? > > We only have documentation for Wildfly at the moment, but if you wish to > use Tomcat it should be relatively simple to extrapolate the > documentation to that platform. The vert.x implementation is > experimental at this point, and should not be used in production. > >> 3. Can we have companies using apiman on production ? any benchmarking >> stats and case study material ? > > I'm sorry to say that we don't currently have reference users or > production benchmarks yet. These materials will surely be coming in the > future as the project matures. > > Thanks! > > -Eric > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. From eric.wittmann at redhat.com Thu Jun 16 05:29:39 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 16 Jun 2016 05:29:39 -0400 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E8227E0@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E62CE8A@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E7BC3D8@DC-SRV-MBX-08> <7F9CC9E7FDAD3C4E9B251D35B702CF51314E8227E0@DC-SRV-MBX-08> Message-ID: I think this diagram looks pretty good now! :) I don't think there's any issue with having a single Keycloak to support both on-prem and cloud. That would make user and realm management much easier, obviously. -Eric On 6/16/2016 3:54 AM, Ashish Patel wrote: > Hi Eric, > > Oh, yes copy paste. Modified it. Kindly suggest. > > https://postimg.org/image/ebydokdbl/ > > One specific query on KeyCloak : can we have only one - KeyCloak (OnPrem) ? or is it mandatory to keep OnPrem and Cloud ? > > Thanks & Regards, > Ashish Patel > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 15 June 2016 23:51 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > I'm a little bit confused by some of the box labeling I think. Some of > the boxes in the top half of the diagram are labelled "Cloud" when I > expected them to be labelled On-Premise. Is that intentional or > copy/paste errors? > > -Eric > > On 6/14/2016 7:35 AM, Ashish Patel wrote: >> Hi Eric, >> >> In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ? >> >> http://postimg.org/image/qzll2wwhz/ >> >> Thanks & Regards, >> Ashish Patel >> >> -----Original Message----- >> From: Ashish Patel >> Sent: 14 June 2016 11:02 >> To: 'Eric Wittmann'; apiman-user at lists.jboss.org >> Subject: RE: [Apiman-user] apiman Production Deployment >> >> Thanks Eric, this helps a lot. >> >> We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. >> >> With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). >> >> Thanks & Regards, >> Ashish Patel >> (M) +91 93270 15128 >> >> "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. >> >> >> >> -----Original Message----- >> From: Eric Wittmann [mailto:eric.wittmann at redhat.com] >> Sent: 13 June 2016 21:32 >> To: Ashish Patel; apiman-user at lists.jboss.org >> Subject: Re: [Apiman-user] apiman Production Deployment >> >> Hi Ashish. >> >> Sorry for the delay in my response. I'll do my best to answer your >> questions. >> >>> 1. We want to have single API Manager for our consumers in "on-premise" >>> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >>> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >>> would be possible deployment architecture ? (best place to put RDBMS >>> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) >> >> There are a very large number of choices here! It depends a lot on >> exactly what you're trying to achieve. Two different configurations >> jump to mind. >> >> Config 1 - A single "logical" API Gateway >> >> In this configuration, every API Gateway node (regardless of whether it >> is on-prem or in the cloud) shares a common data store. This allows >> every node to service the *same* set of APIs. In this case the single >> gateway storage (database or elasticsearch) will need to be accessible >> by all gateway nodes. >> >> In the UI, there is only *one* gateway, so there are no extra steps that >> API developers need take when publishing APIs. However, every Gateway >> node must be able to access every back-end endpoint at the same URL. >> >> >> Config 2 - Two "logical" API Gateways >> >> In this config, the on-prem gateway node(s) and the in-cloud gateway >> node(s) each have their own gateway storage (database and/or >> elasticsearch). When set up this way, the API Manager must be >> configured with *both* gateways, and each gateway should have a sensible >> name, such as "On Premise Gateway" and "Cloud Gateway". >> >> In the UI, the API Developers will need to choose which of the two API >> Gateways their API should be published to (they must choose *at least >> one* gateway). This allows different gateways to service different >> APIs, offering more flexibility. >> >>> 2. production guide having wildfly version, however we would prefer >>> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? >> >> We only have documentation for Wildfly at the moment, but if you wish to >> use Tomcat it should be relatively simple to extrapolate the >> documentation to that platform. The vert.x implementation is >> experimental at this point, and should not be used in production. >> >>> 3. Can we have companies using apiman on production ? any benchmarking >>> stats and case study material ? >> >> I'm sorry to say that we don't currently have reference users or >> production benchmarks yet. These materials will surely be coming in the >> future as the project matures. >> >> Thanks! >> >> -Eric >> >> Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. >> > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > From Ashish.Patel at futureretail.in Thu Jun 16 11:51:41 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Thu, 16 Jun 2016 21:21:41 +0530 Subject: [Apiman-user] apiman Production Deployment References: 5:34689 Message-ID: <45v5956c6p83l2aiqsa0jqjm.1466092301139@email.android.com> Cool Thanks Eric. I have proposed separate ES for cloud gateway to avoid frequent cloud<->OnPrem n/w calls. Will API Manager be able to show cloud gateway metrics? If Yes, wanted to know how that works.. and if no, what are other options to view cloud gateway metrics? Thanks again, Ashish. Sent from my phone On Eric Wittmann , 16-Jun-2016 2:58 pm wrote: I think this diagram looks pretty good now! :) I don't think there's any issue with having a single Keycloak to support both on-prem and cloud. That would make user and realm management much easier, obviously. -Eric On 6/16/2016 3:54 AM, Ashish Patel wrote: > Hi Eric, > > Oh, yes copy paste. Modified it. Kindly suggest. > > https://postimg.org/image/ebydokdbl/ > > One specific query on KeyCloak : can we have only one - KeyCloak (OnPrem) ? or is it mandatory to keep OnPrem and Cloud ? > > Thanks & Regards, > Ashish Patel > > "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. > > > > -----Original Message----- > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > Sent: 15 June 2016 23:51 > To: Ashish Patel; apiman-user at lists.jboss.org > Subject: Re: [Apiman-user] apiman Production Deployment > > Hi Ashish. > > I'm a little bit confused by some of the box labeling I think. Some of > the boxes in the top half of the diagram are labelled "Cloud" when I > expected them to be labelled On-Premise. Is that intentional or > copy/paste errors? > > -Eric > > On 6/14/2016 7:35 AM, Ashish Patel wrote: >> Hi Eric, >> >> In addition to below doubt over "Two Logical API Gateway", have got proposed deployment diagram - can you please review and suggest ? >> >> http://postimg.org/image/qzll2wwhz/ >> >> Thanks & Regards, >> Ashish Patel >> >> -----Original Message----- >> From: Ashish Patel >> Sent: 14 June 2016 11:02 >> To: 'Eric Wittmann'; apiman-user at lists.jboss.org >> Subject: RE: [Apiman-user] apiman Production Deployment >> >> Thanks Eric, this helps a lot. >> >> We would go with Two "logical" API Gateways, as it gives more flexibility. One Doubt: 1. UI will be only one right - be @On Premise / On Cloud. >> >> With single "logical" API Gateway, more concerned over Cloud<->OnPremise Network glitches, may become bottleneck for lot of DB/ES calls (at least for one gateway). >> >> Thanks & Regards, >> Ashish Patel >> (M) +91 93270 15128 >> >> "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. >> >> >> >> -----Original Message----- >> From: Eric Wittmann [mailto:eric.wittmann at redhat.com] >> Sent: 13 June 2016 21:32 >> To: Ashish Patel; apiman-user at lists.jboss.org >> Subject: Re: [Apiman-user] apiman Production Deployment >> >> Hi Ashish. >> >> Sorry for the delay in my response. I'll do my best to answer your >> questions. >> >>> 1. We want to have single API Manager for our consumers in "on-premise" >>> and "cloud" (AWS/Azure..etc). So, can we deploy couple of instance of " >>> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what >>> would be possible deployment architecture ? (best place to put RDBMS >>> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) >> >> There are a very large number of choices here! It depends a lot on >> exactly what you're trying to achieve. Two different configurations >> jump to mind. >> >> Config 1 - A single "logical" API Gateway >> >> In this configuration, every API Gateway node (regardless of whether it >> is on-prem or in the cloud) shares a common data store. This allows >> every node to service the *same* set of APIs. In this case the single >> gateway storage (database or elasticsearch) will need to be accessible >> by all gateway nodes. >> >> In the UI, there is only *one* gateway, so there are no extra steps that >> API developers need take when publishing APIs. However, every Gateway >> node must be able to access every back-end endpoint at the same URL. >> >> >> Config 2 - Two "logical" API Gateways >> >> In this config, the on-prem gateway node(s) and the in-cloud gateway >> node(s) each have their own gateway storage (database and/or >> elasticsearch). When set up this way, the API Manager must be >> configured with *both* gateways, and each gateway should have a sensible >> name, such as "On Premise Gateway" and "Cloud Gateway". >> >> In the UI, the API Developers will need to choose which of the two API >> Gateways their API should be published to (they must choose *at least >> one* gateway). This allows different gateways to service different >> APIs, offering more flexibility. >> >>> 2. production guide having wildfly version, however we would prefer >>> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? >> >> We only have documentation for Wildfly at the moment, but if you wish to >> use Tomcat it should be relatively simple to extrapolate the >> documentation to that platform. The vert.x implementation is >> experimental at this point, and should not be used in production. >> >>> 3. Can we have companies using apiman on production ? any benchmarking >>> stats and case study material ? >> >> I'm sorry to say that we don't currently have reference users or >> production benchmarks yet. These materials will surely be coming in the >> future as the project matures. >> >> Thanks! >> >> -Eric >> >> Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. >> > > Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. > ________________________________ Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160616/40a81187/attachment-0001.html From eric.wittmann at redhat.com Thu Jun 16 15:05:36 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 16 Jun 2016 15:05:36 -0400 Subject: [Apiman-user] apiman Production Deployment In-Reply-To: <45v5956c6p83l2aiqsa0jqjm.1466092301139@email.android.com> References: <45v5956c6p83l2aiqsa0jqjm.1466092301139@email.android.com> Message-ID: I think your best bet may be to set up a periodic transfer of metrics data from the cloud to on-premise so that all your metrics are in a single ES instance. I believe ES has some tools to help with this, but I don't have enough expertise in ES to be sure. As for apiman, at the moment it can only interrogate a single metrics store for data. -Eric On 6/16/2016 11:51 AM, Ashish Patel wrote: > Cool Thanks Eric. > > I have proposed separate ES for cloud gateway to avoid frequent > cloud<->OnPrem n/w calls. Will API Manager be able to show cloud > gateway metrics? If Yes, wanted to know how that works.. and if no, > what are other options to view cloud gateway metrics? > > Thanks again, > Ashish. > > > > Sent from my phone > On Eric Wittmann , 16-Jun-2016 2:58 pm wrote: > > I think this diagram looks pretty good now! :) I don't think there's > any issue with having a single Keycloak to support both on-prem and > cloud. That would make user and realm management much easier, > obviously. > > -Eric > > On 6/16/2016 3:54 AM, Ashish Patel wrote: > > Hi Eric, > > > > Oh, yes copy paste. Modified it. Kindly suggest. > > > > https://postimg.org/image/ebydokdbl/ > > > > One specific query on KeyCloak : can we have only one - KeyCloak > (OnPrem) ? or is it mandatory to keep OnPrem and Cloud ? > > > > Thanks & Regards, > > Ashish Patel > > > > "Scientists investigate that which already is;Engineers create > that which has never been." - Albert Einstein. > > > > > > > > -----Original Message----- > > From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > > Sent: 15 June 2016 23:51 > > To: Ashish Patel; apiman-user at lists.jboss.org > > Subject: Re: [Apiman-user] apiman Production Deployment > > > > Hi Ashish. > > > > I'm a little bit confused by some of the box labeling I think. > Some of > > the boxes in the top half of the diagram are labelled "Cloud" when I > > expected them to be labelled On-Premise. Is that intentional or > > copy/paste errors? > > > > -Eric > > > > On 6/14/2016 7:35 AM, Ashish Patel wrote: > >> Hi Eric, > >> > >> In addition to below doubt over "Two Logical API Gateway", have > got proposed deployment diagram - can you please review and suggest ? > >> > >> http://postimg.org/image/qzll2wwhz/ > >> > >> Thanks & Regards, > >> Ashish Patel > >> > >> -----Original Message----- > >> From: Ashish Patel > >> Sent: 14 June 2016 11:02 > >> To: 'Eric Wittmann'; apiman-user at lists.jboss.org > >> Subject: RE: [Apiman-user] apiman Production Deployment > >> > >> Thanks Eric, this helps a lot. > >> > >> We would go with Two "logical" API Gateways, as it gives more > flexibility. One Doubt: 1. UI will be only one right - be @On > Premise / On Cloud. > >> > >> With single "logical" API Gateway, more concerned over > Cloud<->OnPremise Network glitches, may become bottleneck for lot of > DB/ES calls (at least for one gateway). > >> > >> Thanks & Regards, > >> Ashish Patel > >> (M) +91 93270 15128 > >> > >> "Scientists investigate that which already is;Engineers create > that which has never been." - Albert Einstein. > >> > >> > >> > >> -----Original Message----- > >> From: Eric Wittmann [mailto:eric.wittmann at redhat.com] > >> Sent: 13 June 2016 21:32 > >> To: Ashish Patel; apiman-user at lists.jboss.org > >> Subject: Re: [Apiman-user] apiman Production Deployment > >> > >> Hi Ashish. > >> > >> Sorry for the delay in my response. I'll do my best to answer your > >> questions. > >> > >>> 1. We want to have single API Manager for our consumers in > "on-premise" > >>> and "cloud" (AWS/Azure..etc). So, can we deploy couple of > instance of " > >>> Apiman Gateway" in on-premise and couple of on cloud ? If yes, what > >>> would be possible deployment architecture ? (best place to put RDBMS > >>> on-prem/cloud, best place to put keyclock server/ ES server..etc ?) > >> > >> There are a very large number of choices here! It depends a lot on > >> exactly what you're trying to achieve. Two different configurations > >> jump to mind. > >> > >> Config 1 - A single "logical" API Gateway > >> > >> In this configuration, every API Gateway node (regardless of > whether it > >> is on-prem or in the cloud) shares a common data store. This allows > >> every node to service the *same* set of APIs. In this case the > single > >> gateway storage (database or elasticsearch) will need to be > accessible > >> by all gateway nodes. > >> > >> In the UI, there is only *one* gateway, so there are no extra > steps that > >> API developers need take when publishing APIs. However, every > Gateway > >> node must be able to access every back-end endpoint at the same URL. > >> > >> > >> Config 2 - Two "logical" API Gateways > >> > >> In this config, the on-prem gateway node(s) and the in-cloud gateway > >> node(s) each have their own gateway storage (database and/or > >> elasticsearch). When set up this way, the API Manager must be > >> configured with *both* gateways, and each gateway should have a > sensible > >> name, such as "On Premise Gateway" and "Cloud Gateway". > >> > >> In the UI, the API Developers will need to choose which of the > two API > >> Gateways their API should be published to (they must choose *at least > >> one* gateway). This allows different gateways to service different > >> APIs, offering more flexibility. > >> > >>> 2. production guide having wildfly version, however we would prefer > >>> tomcat / vert.x, any specific guide changes for tomcat / vert.x ? > >> > >> We only have documentation for Wildfly at the moment, but if you > wish to > >> use Tomcat it should be relatively simple to extrapolate the > >> documentation to that platform. The vert.x implementation is > >> experimental at this point, and should not be used in production. > >> > >>> 3. Can we have companies using apiman on production ? any > benchmarking > >>> stats and case study material ? > >> > >> I'm sorry to say that we don't currently have reference users or > >> production benchmarks yet. These materials will surely be coming > in the > >> future as the project matures. > >> > >> Thanks! > >> > >> -Eric > >> > >> Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The > views expressed in this email are those of the sender and not Future > Group's. The recipient should check this email and attachments for > the presence of viruses. Future Group accepts no liability for any > damage caused by any virus transmitted by this email. Future Group > may monitor and record all emails. > >> > > > > Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The > views expressed in this email are those of the sender and not Future > Group's. The recipient should check this email and attachments for > the presence of viruses. Future Group accepts no liability for any > damage caused by any virus transmitted by this email. Future Group > may monitor and record all emails. > > > > > ------------------------------------------------------------------------ > Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The views > expressed in this email are those of the sender and not Future Group's. > The recipient should check this email and attachments for the presence > of viruses. Future Group accepts no liability for any damage caused by > any virus transmitted by this email. Future Group may monitor and record > all emails. From ryordan at redhat.com Fri Jun 17 11:16:03 2016 From: ryordan at redhat.com (Rachel Yordan) Date: Fri, 17 Jun 2016 11:16:03 -0400 Subject: [Apiman-user] building apiman on Redhat In-Reply-To: References: Message-ID: Chris, Apologies for the delayed response, I'm currently working on another project. I also got your PMs on IRC, I'll message you back on there now. But in the meantime, are you running CentOS? This is more of a Jenkins and frontend-maven-plugin issue as opposed to an apiman-specific issue, but I can try my best to help. I think this could possibly be an issue with the fact that your project has a space in the name, as I've had issues in the past related to spaces in the project name. Either way, it doesn't hurt to try building it without spaces! Also, don't forget to undo the changes you've made to node/npm as you don't want it to affect that. 1. It doesn't need to use a relative path because the local Node binary that is being used is responsible for calling `npm install` (locally). Having said that, if you don't have a Node path set, it's going to use the globally installed Node and you try this manually without the frontend-maven-plugin. If you are 100% sure you're not doing that, then there could be a bug in the plugin that handles that: https://github.com/eirslett/frontend-maven-plugin 2, 3. Try building manually as the Jenkins user, so that it's easier to debug. Btw, what error are you getting on the build as the Jenkins user? - Download the jenkins-cli.jar file (http:///jnlpJars/jenkins-cli.jar) and place this jar in the directory from which you are going to run the Jenkins build command. - Switch to the Jenkins user with `sudo su -s /bin/bash jenkins` on the build server. - cd into the `/var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war` directory, or wherever Jenkins is storing the workspace files. - Use the Jenkins CLI to build it manually. You can view the CLI commands available at http:///cli/ ( e.g http://localhost:8080/cli/ ), but it will the build command will be something like this: java -jar jenkins-cli.jar -s http:/// build build-name [-c] [-f] [-p] [-r N] [-s] [-v] [-w] Some of the flags are very useful in this case: -f : Follow the build progress. Like -s only interrupts are not passed through to the build. -p : Specify the build parameters in the key=value format. -v : Prints out the console output of the build. Use with -s I would try adding build parameters to see if it's really an issue with the NODE_EXE var. Absolute worst case scenario, temporarily set the NODE_EXE var for that specific project either via an execute shell script on the Jenkins job configuration settings (can't remember if that's a separate plugin or not), or you can switch to the Jenkins user and set it that way. You shouldn't have to do this though, and if you do, I'd open up a PR in the frontend-maven-plugin repo. Hope this helps! Rachel On Wed, Jun 15, 2016 at 2:47 PM, Christopher Stolte wrote: > Hi Rachel, > > > Thanks for your response. There are a few things here which are confusing > me: > > > 1. the build log says "Running 'npm install --color=false' in > /var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war" > > is that correct? (it seems like it's trying to run a globally installed > npm...) If it's trying to use a locally installed npm, why isn't is using a > relative path to it? > > > 2. If I change manager/ui/war/node/npm so that NODE_EXE=./node/node > (instead of "node") it succeeds. > > > 3. The failing job is being run by Jenkins, and the Jenkins user has no > node on it's path. But if I run the build as a different user who does, it > works. > > > It seems that the plugin which installs nodejs locally, or some subsequent > part of the build process, isn't referring to them correctly (and thus is > dependent on a globally installed node in order to work). Any insight? For > what it's worth I can build the exact same source, from the same repo, with > the same command, on my mac, which has node and npm installed globally. > > > Thanks, > > Chris > ------------------------------ > *From:* Rachel Yordan > *Sent:* Wednesday, June 15, 2016 1:21:53 PM > *To:* Christopher Stolte > *Cc:* apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] building apiman on Redhat > > Hey Chris, > > When you run `$ npm install` or even `$ node -v` you are using the > globally installed binary as opposed to the local one, even if you are > within the directory, as you can see here: > > npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" > "--color=false" > > The deprecation warning at the end of the build log should not be enough > to cause a build failure. To get a more detailed error regarding the build > failure I'd try using the local binary from within the `war` directory you > were in with `$ node/npm install --color=false`. You can also test that > it's using the correct binary with `$ node/npm -v` or `$ node/node -v`. > What is causing the build to fail could be several things, but I always > recommend starting with a clean slate before each test build -- try running > the following before triggering your build again: > > $ rm -rf node_modules/ > $ npm cache clean > > Feel free to ping me on IRC if that doesn't help you get a better idea of > what's going on. Hope it helps! :) > > Rachel Yord?n > IRC: ryordan > GH: @kahboom > > On Wed, Jun 15, 2016 at 10:59 AM, Christopher Stolte > wrote: > >> Hello, >> >> >> I am trying to build apiman-1.2.6.Final on Redhat. Server details: >> >> >> $ uname -or >> >> 3.10.0-229.el7.x86_64 GNU/Linux >> >> >> $ java -version >> >> openjdk version "1.8.0_91" >> >> >> The build fails at this point: >> >> >> [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install >> node and npm) @ apiman-manager-ui-war --- >> >> [INFO] Found proxies: [] >> >> [INFO] Installing node version v5.6.0 >> >> [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp >> >> [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz >> >> [INFO] No proxies configured >> >> [INFO] No proxy was configured, downloading directly >> >> [INFO] Extracting Node.js files in node_tmp >> >> [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp >> >> [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node >> >> [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp >> >> [INFO] Installed node locally. >> >> [INFO] Installing npm version 3.6.0 >> >> [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz >> >> [INFO] No proxies configured >> >> [INFO] No proxy was configured, downloading directly >> >> [INFO] Extracting NPM files in node/ >> >> [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules >> >> [INFO] Installed NPM locally. >> >> [INFO] >> >> [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- >> >> [INFO] Found proxies: [] >> >> [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war >> >> [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. >> >> >> Node/npm appear to be globally installed: >> >> >> $ npm -v >> >> 2.15.1 >> >> $ node -v >> >> v4.4.3 >> >> >> I then tried to execute that npm command from the stated directory, and >> got this: >> >> >> $ cd manager/ui/war >> >> $ npm install --color=false >> >> npm WARN peerDependencies The peer dependency marked@^0.3.3 included >> from marked-terminal will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN prefer global marked at 0.3.5 should be installed with -g >> >> npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before >> will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 >> as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. >> >> npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included >> from grunt-contrib-cssmin will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN peerDependencies The peer dependency grunt@~0.4.1 included from >> grunt-jekyll will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN peerDependencies The peer dependency grunt@~0.4.5 included from >> grunt-contrib-less will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from >> grunt-contrib-uglify will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from >> grunt-contrib-connect will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer maintained. >> Upgrade to lodash@^4.0.0. >> >> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from >> grunt-contrib-watch will no >> >> npm WARN peerDependencies longer be automatically installed to fulfill >> the peerDependency >> >> npm WARN peerDependencies in npm 3+. Your application will need to depend >> on it explicitly. >> >> npm ERR! Linux 3.10.0-229.el7.x86_64 >> >> npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" >> "--color=false" >> >> npm ERR! node v4.4.3 >> >> npm ERR! npm v2.15.1 >> >> npm ERR! code EBADPLATFORM >> >> npm ERR! notsup Unsupported >> >> npm ERR! notsup Not compatible with your operating system or >> architecture: fsevents at 1.0.8 >> >> npm ERR! notsup Valid OS: darwin >> >> npm ERR! notsup Valid Arch: any >> >> npm ERR! notsup Actual OS: linux >> >> npm ERR! notsup Actual Arch: x64 >> >> npm ERR! Please include the following file with any support request: >> >> npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log >> >> Does anyone have an idea as to what is going on here? I see some threads >> about the maven plugin that installs node/npm locally ( >> https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's >> going on here. I'm especially confused about versions, since the plugin >> installed versions [5.6.0/3.6.0] locally but the above error message is >> referencing the globally installed versions [4.4.3/2.15.1]. >> >> >> Any help much appreciated! >> >> Chris >> >> >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160617/1fecdfc3/attachment-0001.html From cstolte at ebsco.com Fri Jun 17 11:37:58 2016 From: cstolte at ebsco.com (Christopher Stolte) Date: Fri, 17 Jun 2016 15:37:58 +0000 Subject: [Apiman-user] building apiman on Redhat In-Reply-To: References: , Message-ID: Oh jeez. Major egg on my face here...I was just about ready to update this thread, as I have figured out what was going on. It turns out I had inadvertently modified manager/ui/war/pom.xml in a subtle way that -completely- broke it. This was the cause of all my problems.. I'm very sorry to have wasted your time, and I sincerely thank you for your effort in trying to help me out. (On the bright side I understand node, npm, and maven better than when I started!) Just to be clear then - a global install of node/npm is not required, and everything is building correctly for me on CentOS after having reverted my disastrous change. Thank you again - please feel free to throw virtual office supplies at me from across cyberspace... -Chris ________________________________ From: Rachel Yordan Sent: Friday, June 17, 2016 11:16:03 AM To: Christopher Stolte Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] building apiman on Redhat Chris, Apologies for the delayed response, I'm currently working on another project. I also got your PMs on IRC, I'll message you back on there now. But in the meantime, are you running CentOS? This is more of a Jenkins and frontend-maven-plugin issue as opposed to an apiman-specific issue, but I can try my best to help. I think this could possibly be an issue with the fact that your project has a space in the name, as I've had issues in the past related to spaces in the project name. Either way, it doesn't hurt to try building it without spaces! Also, don't forget to undo the changes you've made to node/npm as you don't want it to affect that. 1. It doesn't need to use a relative path because the local Node binary that is being used is responsible for calling `npm install` (locally). Having said that, if you don't have a Node path set, it's going to use the globally installed Node and you try this manually without the frontend-maven-plugin. If you are 100% sure you're not doing that, then there could be a bug in the plugin that handles that: https://github.com/eirslett/frontend-maven-plugin 2, 3. Try building manually as the Jenkins user, so that it's easier to debug. Btw, what error are you getting on the build as the Jenkins user? - Download the jenkins-cli.jar file (http:///jnlpJars/jenkins-cli.jar) and place this jar in the directory from which you are going to run the Jenkins build command. - Switch to the Jenkins user with `sudo su -s /bin/bash jenkins` on the build server. - cd into the `/var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war` directory, or wherever Jenkins is storing the workspace files. - Use the Jenkins CLI to build it manually. You can view the CLI commands available at http:///cli/ ( e.g http://localhost:8080/cli/ ), but it will the build command will be something like this: java -jar jenkins-cli.jar -s http:/// build build-name [-c] [-f] [-p] [-r N] [-s] [-v] [-w] Some of the flags are very useful in this case: -f : Follow the build progress. Like -s only interrupts are not passed through to the build. -p : Specify the build parameters in the key=value format. -v : Prints out the console output of the build. Use with -s I would try adding build parameters to see if it's really an issue with the NODE_EXE var. Absolute worst case scenario, temporarily set the NODE_EXE var for that specific project either via an execute shell script on the Jenkins job configuration settings (can't remember if that's a separate plugin or not), or you can switch to the Jenkins user and set it that way. You shouldn't have to do this though, and if you do, I'd open up a PR in the frontend-maven-plugin repo. Hope this helps! Rachel On Wed, Jun 15, 2016 at 2:47 PM, Christopher Stolte > wrote: Hi Rachel, Thanks for your response. There are a few things here which are confusing me: 1. the build log says "Running 'npm install --color=false' in /var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war" is that correct? (it seems like it's trying to run a globally installed npm...) If it's trying to use a locally installed npm, why isn't is using a relative path to it? 2. If I change manager/ui/war/node/npm so that NODE_EXE=./node/node (instead of "node") it succeeds. 3. The failing job is being run by Jenkins, and the Jenkins user has no node on it's path. But if I run the build as a different user who does, it works. It seems that the plugin which installs nodejs locally, or some subsequent part of the build process, isn't referring to them correctly (and thus is dependent on a globally installed node in order to work). Any insight? For what it's worth I can build the exact same source, from the same repo, with the same command, on my mac, which has node and npm installed globally. Thanks, Chris ________________________________ From: Rachel Yordan > Sent: Wednesday, June 15, 2016 1:21:53 PM To: Christopher Stolte Cc: apiman-user at lists.jboss.org Subject: Re: [Apiman-user] building apiman on Redhat Hey Chris, When you run `$ npm install` or even `$ node -v` you are using the globally installed binary as opposed to the local one, even if you are within the directory, as you can see here: npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" The deprecation warning at the end of the build log should not be enough to cause a build failure. To get a more detailed error regarding the build failure I'd try using the local binary from within the `war` directory you were in with `$ node/npm install --color=false`. You can also test that it's using the correct binary with `$ node/npm -v` or `$ node/node -v`. What is causing the build to fail could be several things, but I always recommend starting with a clean slate before each test build -- try running the following before triggering your build again: $ rm -rf node_modules/ $ npm cache clean Feel free to ping me on IRC if that doesn't help you get a better idea of what's going on. Hope it helps! :) Rachel Yord?n IRC: ryordan GH: @kahboom On Wed, Jun 15, 2016 at 10:59 AM, Christopher Stolte > wrote: Hello, I am trying to build apiman-1.2.6.Final on Redhat. Server details: $ uname -or 3.10.0-229.el7.x86_64 GNU/Linux $ java -version openjdk version "1.8.0_91" The build fails at this point: [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install node and npm) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Installing node version v5.6.0 [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting Node.js files in node_tmp [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp [INFO] Installed node locally. [INFO] Installing npm version 3.6.0 [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz [INFO] No proxies configured [INFO] No proxy was configured, downloading directly [INFO] Extracting NPM files in node/ [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules [INFO] Installed NPM locally. [INFO] [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- [INFO] Found proxies: [] [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. Node/npm appear to be globally installed: $ npm -v 2.15.1 $ node -v v4.4.3 I then tried to execute that npm command from the stated directory, and got this: $ cd manager/ui/war $ npm install --color=false npm WARN peerDependencies The peer dependency marked@^0.3.3 included from marked-terminal will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN prefer global marked at 0.3.5 should be installed with -g npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included from grunt-contrib-cssmin will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.1 included from grunt-jekyll will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.5 included from grunt-contrib-less will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-uglify will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-connect will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer maintained. Upgrade to lodash@^4.0.0. npm WARN peerDependencies The peer dependency grunt@~0.4.0 included from grunt-contrib-watch will no npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly. npm ERR! Linux 3.10.0-229.el7.x86_64 npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--color=false" npm ERR! node v4.4.3 npm ERR! npm v2.15.1 npm ERR! code EBADPLATFORM npm ERR! notsup Unsupported npm ERR! notsup Not compatible with your operating system or architecture: fsevents at 1.0.8 npm ERR! notsup Valid OS: darwin npm ERR! notsup Valid Arch: any npm ERR! notsup Actual OS: linux npm ERR! notsup Actual Arch: x64 npm ERR! Please include the following file with any support request: npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log Does anyone have an idea as to what is going on here? I see some threads about the maven plugin that installs node/npm locally (https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's going on here. I'm especially confused about versions, since the plugin installed versions [5.6.0/3.6.0] locally but the above error message is referencing the globally installed versions [4.4.3/2.15.1]. Any help much appreciated! Chris _______________________________________________ Apiman-user mailing list Apiman-user at lists.jboss.org https://lists.jboss.org/mailman/listinfo/apiman-user -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160617/66180790/attachment-0001.html From ryordan at redhat.com Fri Jun 17 12:17:10 2016 From: ryordan at redhat.com (Rachel Yordan) Date: Fri, 17 Jun 2016 12:17:10 -0400 Subject: [Apiman-user] building apiman on Redhat In-Reply-To: References: Message-ID: No problem Chris! Glad to hear you got it sorted out. *throws virtual office supplies at you* Rachel On Fri, Jun 17, 2016 at 11:37 AM, Christopher Stolte wrote: > Oh jeez. Major egg on my face here...I was just about ready to update this > thread, as I have figured out what was going on. > > > It turns out I had inadvertently modified manager/ui/war/pom.xml in a > subtle way that -completely- broke it. This was the cause of all my > problems.. I'm very sorry to have wasted your time, and I sincerely thank > you for your effort in trying to help me out. (On the bright side I > understand node, npm, and maven better than when I started!) > > > Just to be clear then - a global install of node/npm is not required, and > everything is building correctly for me on CentOS after having reverted my > disastrous change. > > > Thank you again - please feel free to throw virtual office supplies at me > from across cyberspace... > > > -Chris > ------------------------------ > *From:* Rachel Yordan > *Sent:* Friday, June 17, 2016 11:16:03 AM > > *To:* Christopher Stolte > *Cc:* apiman-user at lists.jboss.org > *Subject:* Re: [Apiman-user] building apiman on Redhat > > Chris, > > Apologies for the delayed response, I'm currently working on another > project. I also got your PMs on IRC, I'll message you back on there now. > But in the meantime, are you running CentOS? This is more of a Jenkins and > frontend-maven-plugin issue as opposed to an apiman-specific issue, but I > can try my best to help. > > I think this could possibly be an issue with the fact that your project > has a space in the name, as I've had issues in the past related to spaces > in the project name. Either way, it doesn't hurt to try building it without > spaces! Also, don't forget to undo the changes you've made to node/npm as > you don't want it to affect that. > > 1. It doesn't need to use a relative path because the local Node binary > that is being used is responsible for calling `npm install` (locally). > Having said that, if you don't have a Node path set, it's going to use the > globally installed Node and you try this manually without the > frontend-maven-plugin. If you are 100% sure you're not doing that, then > there could be a bug in the plugin that handles that: > https://github.com/eirslett/frontend-maven-plugin > > 2, 3. Try building manually as the Jenkins user, so that it's easier to > debug. Btw, what error are you getting on the build as the Jenkins user? > > - Download the jenkins-cli.jar file (http:// server>/jnlpJars/jenkins-cli.jar) and place this jar in the directory from > which you are going to run the Jenkins build command. > - Switch to the Jenkins user with `sudo su -s /bin/bash jenkins` on the > build server. > - cd into the `/var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/ > war` directory, or wherever Jenkins is storing the workspace files. > - Use the Jenkins CLI to build it manually. You can view the CLI commands > available at http:///cli/ ( e.g > http://localhost:8080/cli/ ), but it will the build command will be > something like this: java -jar jenkins-cli.jar -s http:// server>/ build build-name [-c] [-f] [-p] [-r N] [-s] [-v] [-w] > > Some of the flags are very useful in this case: > -f : Follow the build progress. Like -s only interrupts are not passed > through to the build. > -p : Specify the build parameters in the key=value format. > -v : Prints out the console output of the build. Use with -s > > I would try adding build parameters to see if it's really an issue with > the NODE_EXE var. Absolute worst case scenario, temporarily set the > NODE_EXE var for that specific project either via an execute shell script > on the Jenkins job configuration settings (can't remember if that's a > separate plugin or not), or you can switch to the Jenkins user and set it > that way. You shouldn't have to do this though, and if you do, I'd open up > a PR in the frontend-maven-plugin repo. > > Hope this helps! > > Rachel > > > > On Wed, Jun 15, 2016 at 2:47 PM, Christopher Stolte > wrote: > >> Hi Rachel, >> >> >> Thanks for your response. There are a few things here which are >> confusing me: >> >> >> 1. the build log says "Running 'npm install --color=false' in >> /var/lib/jenkins/jobs/Upgrade APIMAN/workspace/manager/ui/war" >> >> is that correct? (it seems like it's trying to run a globally installed >> npm...) If it's trying to use a locally installed npm, why isn't is using a >> relative path to it? >> >> >> 2. If I change manager/ui/war/node/npm so that NODE_EXE=./node/node >> (instead of "node") it succeeds. >> >> >> 3. The failing job is being run by Jenkins, and the Jenkins user has no >> node on it's path. But if I run the build as a different user who does, it >> works. >> >> >> It seems that the plugin which installs nodejs locally, or some >> subsequent part of the build process, isn't referring to them correctly >> (and thus is dependent on a globally installed node in order to work). Any >> insight? For what it's worth I can build the exact same source, from the >> same repo, with the same command, on my mac, which has node and npm >> installed globally. >> >> >> Thanks, >> >> Chris >> ------------------------------ >> *From:* Rachel Yordan >> *Sent:* Wednesday, June 15, 2016 1:21:53 PM >> *To:* Christopher Stolte >> *Cc:* apiman-user at lists.jboss.org >> *Subject:* Re: [Apiman-user] building apiman on Redhat >> >> Hey Chris, >> >> When you run `$ npm install` or even `$ node -v` you are using the >> globally installed binary as opposed to the local one, even if you are >> within the directory, as you can see here: >> >> npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" >> "--color=false" >> >> The deprecation warning at the end of the build log should not be enough >> to cause a build failure. To get a more detailed error regarding the build >> failure I'd try using the local binary from within the `war` directory you >> were in with `$ node/npm install --color=false`. You can also test that >> it's using the correct binary with `$ node/npm -v` or `$ node/node -v`. >> What is causing the build to fail could be several things, but I always >> recommend starting with a clean slate before each test build -- try running >> the following before triggering your build again: >> >> $ rm -rf node_modules/ >> $ npm cache clean >> >> Feel free to ping me on IRC if that doesn't help you get a better idea of >> what's going on. Hope it helps! :) >> >> Rachel Yord?n >> IRC: ryordan >> GH: @kahboom >> >> On Wed, Jun 15, 2016 at 10:59 AM, Christopher Stolte >> wrote: >> >>> Hello, >>> >>> >>> I am trying to build apiman-1.2.6.Final on Redhat. Server details: >>> >>> >>> $ uname -or >>> >>> 3.10.0-229.el7.x86_64 GNU/Linux >>> >>> >>> $ java -version >>> >>> openjdk version "1.8.0_91" >>> >>> >>> The build fails at this point: >>> >>> >>> [INFO] --- frontend-maven-plugin:0.0.27:install-node-and-npm (install >>> node and npm) @ apiman-manager-ui-war --- >>> >>> [INFO] Found proxies: [] >>> >>> [INFO] Installing node version v5.6.0 >>> >>> [INFO] Creating temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp >>> >>> [INFO] Downloading Node.js from https://nodejs.org/dist/v5.6.0/node-v5.6.0-linux-x64.tar.gz to /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz >>> >>> [INFO] No proxies configured >>> >>> [INFO] No proxy was configured, downloading directly >>> >>> [INFO] Extracting Node.js files in node_tmp >>> >>> [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/node_tmp/node.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node_tmp >>> >>> [INFO] Moving node binary to /home/cloud-user/apiman-build/manager/ui/war/node/node >>> >>> [INFO] Deleting temporary directory /home/cloud-user/apiman-build/manager/ui/war/node_tmp >>> >>> [INFO] Installed node locally. >>> >>> [INFO] Installing npm version 3.6.0 >>> >>> [INFO] Downloading NPM from http://registry.npmjs.org/npm/-/npm-3.6.0.tgz to /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz >>> >>> [INFO] No proxies configured >>> >>> [INFO] No proxy was configured, downloading directly >>> >>> [INFO] Extracting NPM files in node/ >>> >>> [INFO] Unpacking /home/cloud-user/apiman-build/manager/ui/war/npm.tar.gz into /home/cloud-user/apiman-build/manager/ui/war/node/node_modules >>> >>> [INFO] Installed NPM locally. >>> >>> [INFO] >>> >>> [INFO] --- frontend-maven-plugin:0.0.27:npm (npm install) @ apiman-manager-ui-war --- >>> >>> [INFO] Found proxies: [] >>> >>> [INFO] Running 'npm install --color=false' in /home/cloud-user/apiman-build/manager/ui/war >>> >>> [ERROR] npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. >>> >>> >>> Node/npm appear to be globally installed: >>> >>> >>> $ npm -v >>> >>> 2.15.1 >>> >>> $ node -v >>> >>> v4.4.3 >>> >>> >>> I then tried to execute that npm command from the stated directory, and >>> got this: >>> >>> >>> $ cd manager/ui/war >>> >>> $ npm install --color=false >>> >>> npm WARN peerDependencies The peer dependency marked@^0.3.3 included >>> from marked-terminal will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN prefer global marked at 0.3.5 should be installed with -g >>> >>> npm WARN deprecated graceful-fs at 1.2.3: graceful-fs v3.0.0 and before >>> will fail on node releases >= v7.0. Please update to graceful-fs@^4.0.0 >>> as soon as possible. Use 'npm ls graceful-fs' to find it in the tree. >>> >>> npm WARN peerDependencies The peer dependency grunt@>=0.4.0 included >>> from grunt-contrib-cssmin will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN peerDependencies The peer dependency grunt@~0.4.1 included >>> from grunt-jekyll will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN peerDependencies The peer dependency grunt@~0.4.5 included >>> from grunt-contrib-less will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included >>> from grunt-contrib-uglify will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included >>> from grunt-contrib-connect will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm WARN deprecated lodash at 2.4.1: lodash@<3.0.0 is no longer >>> maintained. Upgrade to lodash@^4.0.0. >>> >>> npm WARN peerDependencies The peer dependency grunt@~0.4.0 included >>> from grunt-contrib-watch will no >>> >>> npm WARN peerDependencies longer be automatically installed to fulfill >>> the peerDependency >>> >>> npm WARN peerDependencies in npm 3+. Your application will need to >>> depend on it explicitly. >>> >>> npm ERR! Linux 3.10.0-229.el7.x86_64 >>> >>> npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" >>> "--color=false" >>> >>> npm ERR! node v4.4.3 >>> >>> npm ERR! npm v2.15.1 >>> >>> npm ERR! code EBADPLATFORM >>> >>> npm ERR! notsup Unsupported >>> >>> npm ERR! notsup Not compatible with your operating system or >>> architecture: fsevents at 1.0.8 >>> >>> npm ERR! notsup Valid OS: darwin >>> >>> npm ERR! notsup Valid Arch: any >>> >>> npm ERR! notsup Actual OS: linux >>> >>> npm ERR! notsup Actual Arch: x64 >>> >>> npm ERR! Please include the following file with any support request: >>> >>> npm ERR! /home/cloud-user/apiman-build/manager/ui/war/npm-debug.log >>> >>> Does anyone have an idea as to what is going on here? I see some threads >>> about the maven plugin that installs node/npm locally ( >>> https://issues.jboss.org/browse/APIMAN-771), but it isn't quite what's >>> going on here. I'm especially confused about versions, since the plugin >>> installed versions [5.6.0/3.6.0] locally but the above error message is >>> referencing the globally installed versions [4.4.3/2.15.1]. >>> >>> >>> Any help much appreciated! >>> >>> Chris >>> >>> >>> >>> >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160617/a819cf4e/attachment-0001.html From ejlp12 at gmail.com Wed Jun 22 19:40:06 2016 From: ejlp12 at gmail.com (ejlp ejlp) Date: Thu, 23 Jun 2016 06:40:06 +0700 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) Message-ID: Hi, I was trying to use Log Header policy but no logging message shown in Gatway's console or server.log. I am using JBoss EAP 7.0 and Apiman 1.2.6.Final This is what I've done in Gateway node: * Use extracted war of apiman-gateway-api.war and apiman-gateway.war * Put apiman-common-logging-log4j2-1.2.6.Final.jar into /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ and /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ * Remove following line from apiman.properties apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory and put this line: apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory * Restart JBoss EAP I got following stacktrace when EAP started: 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 64) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) at org.jboss.threads.JBossThread.run(JBossThread.java:320) Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) ... 6 more Caused by: java.lang.RuntimeException: java.lang.NullPointerException at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) ... 8 more Caused by: java.lang.NullPointerException at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) ... 15 more 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "apiman-gateway-api.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException Caused by: java.lang.RuntimeException: java.lang.RuntimeException: java.lang.NullPointerException Caused by: java.lang.RuntimeException: java.lang.NullPointerException Caused by: java.lang.NullPointerException"}} From Ashish.Patel at futureretail.in Thu Jun 23 01:18:11 2016 From: Ashish.Patel at futureretail.in (Ashish Patel) Date: Thu, 23 Jun 2016 10:48:11 +0530 Subject: [Apiman-user] Red Hat acquire 3Scale Message-ID: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E99641E@DC-SRV-MBX-08> Got interesting news this morning... How will it impact APIMan ? Any idea ? We are putting lot of weight behind deploying Apiman in production and any insight on this would be very valuable. https://www.redhat.com/en/about/blog/red-hat-and-api-economy?sc_cid=7016000000154B7AAI Thanks & Regards, Ashish Patel "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein. ________________________________ Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160623/1c95a8ba/attachment.html From eric.wittmann at redhat.com Thu Jun 23 08:26:55 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jun 2016 08:26:55 -0400 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: References: Message-ID: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> You are just *slightly* off in your apiman.properties configuration! And it's understandable, as you'll see shortly. :) You have modified "apiman-gateway.logger-factory" to have the following value: io.apiman.common.logging.log4j2.Log4j2LoggerFactory But instead it should be this: io.apiman.common.logging.slf4j.Log4j2LoggerFactory -Eric On 6/22/2016 7:40 PM, ejlp ejlp wrote: > Hi, > > I was trying to use Log Header policy but no logging message shown in > Gatway's console or server.log. > I am using JBoss EAP 7.0 and Apiman 1.2.6.Final > > This is what I've done in Gateway node: > > * Use extracted war of apiman-gateway-api.war and apiman-gateway.war > * Put apiman-common-logging-log4j2-1.2.6.Final.jar into > /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ > and /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ > * Remove following line from apiman.properties > > apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory > > and put this line: > > apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory > > * Restart JBoss EAP > > I got following stacktrace when EAP started: > > 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread > Pool -- 64) MSC000001: Failed to start service > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.NullPointerException > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > Caused by: java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.NullPointerException > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > ... 6 more > Caused by: java.lang.RuntimeException: java.lang.NullPointerException > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) > at io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) > at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) > at io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) > at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > ... 8 more > Caused by: java.lang.NullPointerException > at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) > ... 15 more > > 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] > (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") > failed - address: ([("deployment" => "apiman-gateway-api.war")]) - > failure description: {"WFLYCTL0080: Failed services" => > {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" > => "org.jboss.msc.service.StartException in service > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.NullPointerException > Caused by: java.lang.RuntimeException: java.lang.RuntimeException: > java.lang.NullPointerException > Caused by: java.lang.RuntimeException: java.lang.NullPointerException > Caused by: java.lang.NullPointerException"}} > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Thu Jun 23 09:07:32 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jun 2016 09:07:32 -0400 Subject: [Apiman-user] Red Hat acquire 3Scale In-Reply-To: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E99641E@DC-SRV-MBX-08> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E99641E@DC-SRV-MBX-08> Message-ID: <5b81fe26-2cc7-194d-08d3-6c9edab9578b@redhat.com> Hi Ashish. I'll be making a statement on this today. Stay tuned! :) -Eric On 6/23/2016 1:18 AM, Ashish Patel wrote: > Got interesting news this morning... > > > > How will it impact APIMan ? Any idea ? We are putting lot of weight > behind deploying Apiman in production and any insight on this would be > very valuable. > > > > https://www.redhat.com/en/about/blog/red-hat-and-api-economy?sc_cid=7016000000154B7AAI > > > > Thanks & Regards, > > Ashish Patel > > > > "Scientists investigate that which already is;Engineers create that > which has never been." - Albert Einstein. > > > > > ------------------------------------------------------------------------ > Disclaimer: This message may contain privileged and confidential > information and is solely for the use of intended recipient. The views > expressed in this email are those of the sender and not Future Group's. > The recipient should check this email and attachments for the presence > of viruses. Future Group accepts no liability for any damage caused by > any virus transmitted by this email. Future Group may monitor and record > all emails. > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From ah at tradeworks.io Thu Jun 23 09:23:00 2016 From: ah at tradeworks.io (Anton Hughes) Date: Thu, 23 Jun 2016 15:23:00 +0200 Subject: [Apiman-user] Red Hat acquire 3Scale In-Reply-To: <5b81fe26-2cc7-194d-08d3-6c9edab9578b@redhat.com> References: <7F9CC9E7FDAD3C4E9B251D35B702CF51314E99641E@DC-SRV-MBX-08> <5b81fe26-2cc7-194d-08d3-6c9edab9578b@redhat.com> Message-ID: Thanks Eric On 23 June 2016 at 15:07, Eric Wittmann wrote: > I'll be making a statement on this today. Stay tuned! :) > Am also looking forward to hearing how APIMan and 3Scale will make a beautiful team! -- Anton Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160623/c62a6164/attachment-0001.html From eric.wittmann at redhat.com Thu Jun 23 13:58:53 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 23 Jun 2016 13:58:53 -0400 Subject: [Apiman-user] Red Hat has acquired 3scale! Message-ID: <3a891965-c827-bb70-bd83-afbf21908bbb@redhat.com> Hey everyone. I'm sure that by now many of you have heard about Red Hat's acquisition of 3scale, a commercial vendor of API Management software. If you're wondering how this impacts apiman, I have written a short blog post on the topic: http://www.apiman.io/blog/apiman/3scale/2016/06/22/redhat-3scale-apiman.html It's still quite early, but I've included as much information as I know. :) -Eric From ejlp12 at gmail.com Thu Jun 23 18:41:39 2016 From: ejlp12 at gmail.com (ejlp ejlp) Date: Fri, 24 Jun 2016 05:41:39 +0700 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> Message-ID: Hi Eric, Thanks for the answer. The package/class name was copied from http://www.apiman.io/latest/developer-guide.html section 4.2.2.2 I have changed it and now I got following response: {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: org/apache/logging/log4j/LogManager\n\tat io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat io.apiman.gateway.engine.es.ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat io.apiman.gateway.engine.es.ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown Source)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown Source)\n\tat io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown Source)\n\tat io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown Source)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat java.lang.Thread.run(Thread.java:745)\nCaused by: java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager from [Module \"deployment.apiman-gateway.war:main\" from Service Module Loader]\n\tat org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... 70 more\n"} On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann wrote: > You are just *slightly* off in your apiman.properties configuration! And > it's understandable, as you'll see shortly. :) > > You have modified "apiman-gateway.logger-factory" to have the following > value: > > io.apiman.common.logging.log4j2.Log4j2LoggerFactory > > But instead it should be this: > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory > > -Eric > > > On 6/22/2016 7:40 PM, ejlp ejlp wrote: >> >> Hi, >> >> I was trying to use Log Header policy but no logging message shown in >> Gatway's console or server.log. >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final >> >> This is what I've done in Gateway node: >> >> * Use extracted war of apiman-gateway-api.war and apiman-gateway.war >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into >> /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ >> and /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ >> * Remove following line from apiman.properties >> >> >> apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory >> >> and put this line: >> >> >> apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory >> >> * Restart JBoss EAP >> >> I got following stacktrace when EAP started: >> >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread >> Pool -- 64) MSC000001: Failed to start service >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> java.lang.RuntimeException: java.lang.RuntimeException: >> java.lang.NullPointerException >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) >> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> at java.lang.Thread.run(Thread.java:745) >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: >> java.lang.NullPointerException >> at >> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) >> at >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >> ... 6 more >> Caused by: java.lang.RuntimeException: java.lang.NullPointerException >> at >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) >> at >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) >> at >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) >> at >> io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) >> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) >> at >> io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) >> at >> io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) >> at >> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) >> ... 8 more >> Caused by: java.lang.NullPointerException >> at >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) >> ... 15 more >> >> 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] >> (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") >> failed - address: ([("deployment" => "apiman-gateway-api.war")]) - >> failure description: {"WFLYCTL0080: Failed services" => >> >> {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" >> => "org.jboss.msc.service.StartException in service >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> java.lang.RuntimeException: java.lang.RuntimeException: >> java.lang.NullPointerException >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: >> java.lang.NullPointerException >> Caused by: java.lang.RuntimeException: java.lang.NullPointerException >> Caused by: java.lang.NullPointerException"}} >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > From ejlp12 at gmail.com Thu Jun 23 22:58:16 2016 From: ejlp12 at gmail.com (ejlp ejlp) Date: Fri, 24 Jun 2016 09:58:16 +0700 Subject: [Apiman-user] Red Hat has acquired 3scale! In-Reply-To: <3a891965-c827-bb70-bd83-afbf21908bbb@redhat.com> References: <3a891965-c827-bb70-bd83-afbf21908bbb@redhat.com> Message-ID: I hope this will bring goodness for both.. I've tried 3scale, it has some nice capabilities e.g. more granular metric and policy, and it has billing capability that currently APIMan doesn't have yet. But I like APIMan because its flexibility to create plug-in, it has so many policies (rules) that already provided, policies can be added in API definition, plan (contract) and event client app definition. In 3scale, AFAIK, we have to manually doing LUA scripting in the NGINX for creating policy, even just for simple policy e.g. IP address white list. And I like APIMan since it use Java :-) Keep up a good work guys.. On Jun 24, 2016 12:59 AM, "Eric Wittmann" wrote: > Hey everyone. I'm sure that by now many of you have heard about Red > Hat's acquisition of 3scale, a commercial vendor of API Management > software. If you're wondering how this impacts apiman, I have written a > short blog post on the topic: > > > http://www.apiman.io/blog/apiman/3scale/2016/06/22/redhat-3scale-apiman.html > > It's still quite early, but I've included as much information as I know. :) > > -Eric > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160624/8f7e4c9e/attachment.html From marc.savy at redhat.com Fri Jun 24 05:10:41 2016 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 24 Jun 2016 10:10:41 +0100 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> Message-ID: You will need log4j2 onto your classpath. It was recently removed as an explicit dependency, I believe. On 23 June 2016 at 23:41, ejlp ejlp wrote: > Hi Eric, > > Thanks for the answer. The package/class name was copied from > http://www.apiman.io/latest/developer-guide.html section 4.2.2.2 > > I have changed it and now I got following response: > > > {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: > org/apache/logging/log4j/LogManager\n\tat > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat > > io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat > > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat > > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat > > io.apiman.gateway.engine.es.ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat > > io.apiman.gateway.engine.es.ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat > > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat > > io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat > > io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat > > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat > > io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat > > io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat > > io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat > > io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat > > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat > > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat > > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat > > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat > > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat > > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat > java.lang.Thread.run(Thread.java:745)\nCaused by: > java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager > from [Module \"deployment.apiman-gateway.war:main\" from Service > Module Loader]\n\tat > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... > 70 more\n"} > > On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann > wrote: > > You are just *slightly* off in your apiman.properties configuration! And > > it's understandable, as you'll see shortly. :) > > > > You have modified "apiman-gateway.logger-factory" to have the following > > value: > > > > io.apiman.common.logging.log4j2.Log4j2LoggerFactory > > > > But instead it should be this: > > > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory > > > > -Eric > > > > > > On 6/22/2016 7:40 PM, ejlp ejlp wrote: > >> > >> Hi, > >> > >> I was trying to use Log Header policy but no logging message shown in > >> Gatway's console or server.log. > >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final > >> > >> This is what I've done in Gateway node: > >> > >> * Use extracted war of apiman-gateway-api.war and apiman-gateway.war > >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into > >> /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ > >> and /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ > >> * Remove following line from apiman.properties > >> > >> > >> > apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory > >> > >> and put this line: > >> > >> > >> > apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory > >> > >> * Restart JBoss EAP > >> > >> I got following stacktrace when EAP started: > >> > >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread > >> Pool -- 64) MSC000001: Failed to start service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> org.jboss.msc.service.StartException in service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > >> at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) > >> at > >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > >> at > >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > >> at java.lang.Thread.run(Thread.java:745) > >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) > >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > >> ... 6 more > >> Caused by: java.lang.RuntimeException: java.lang.NullPointerException > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) > >> at > >> > io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) > >> at io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) > >> at > >> > io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) > >> at > >> > io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > >> at > >> > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > >> ... 8 more > >> Caused by: java.lang.NullPointerException > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) > >> ... 15 more > >> > >> 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] > >> (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") > >> failed - address: ([("deployment" => "apiman-gateway-api.war")]) - > >> failure description: {"WFLYCTL0080: Failed services" => > >> > >> > {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" > >> => "org.jboss.msc.service.StartException in service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: > java.lang.NullPointerException > >> Caused by: java.lang.NullPointerException"}} > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/apiman-user > >> > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160624/5d7d43b1/attachment-0001.html From eric.wittmann at redhat.com Fri Jun 24 07:35:40 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 24 Jun 2016 07:35:40 -0400 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> Message-ID: <4c28eb00-7b40-fe9b-71e0-3f5cb715d6d6@redhat.com> He's using 1.2.6.Final, though - so that dependency change wouldn't be affecting him. I'll write up some jiras for these issues (documentation + classnotfound). -Eric On 6/24/2016 5:10 AM, Marc Savy wrote: > You will need log4j2 onto your classpath. > > It was recently removed as an explicit dependency, I believe. > > On 23 June 2016 at 23:41, ejlp ejlp > wrote: > > Hi Eric, > > Thanks for the answer. The package/class name was copied from > http://www.apiman.io/latest/developer-guide.html section 4.2.2.2 > > I have changed it and now I got following response: > > {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: > org/apache/logging/log4j/LogManager\n\tat > io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat > io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat > io.apiman.gateway.engine.es.ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat > io.apiman.gateway.engine.es.ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat > io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat > io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat > io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat > io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown > Source)\n\tat > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat > io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat > io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat > io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat > io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat > java.lang.Thread.run(Thread.java:745)\nCaused by: > java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager > from [Module \"deployment.apiman-gateway.war:main\" from Service > Module Loader]\n\tat > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... > 70 more\n"} > > On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann > > wrote: > > You are just *slightly* off in your apiman.properties > configuration! And > > it's understandable, as you'll see shortly. :) > > > > You have modified "apiman-gateway.logger-factory" to have the > following > > value: > > > > io.apiman.common.logging.log4j2.Log4j2LoggerFactory > > > > But instead it should be this: > > > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory > > > > -Eric > > > > > > On 6/22/2016 7:40 PM, ejlp ejlp wrote: > >> > >> Hi, > >> > >> I was trying to use Log Header policy but no logging message shown in > >> Gatway's console or server.log. > >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final > >> > >> This is what I've done in Gateway node: > >> > >> * Use extracted war of apiman-gateway-api.war and apiman-gateway.war > >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into > >> > /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ > >> and > /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ > >> * Remove following line from apiman.properties > >> > >> > >> > apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory > >> > >> and put this line: > >> > >> > >> > apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory > >> > >> * Restart JBoss EAP > >> > >> I got following stacktrace when EAP started: > >> > >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread > >> Pool -- 64) MSC000001: Failed to start service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> org.jboss.msc.service.StartException in service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > >> at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) > >> at > >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > >> at > >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > >> at java.lang.Thread.run(Thread.java:745) > >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) > >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > >> at > >> > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > >> ... 6 more > >> Caused by: java.lang.RuntimeException: java.lang.NullPointerException > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) > >> at > >> > io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) > >> at > io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) > >> at > >> > io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) > >> at > >> > io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > >> at > >> > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > >> ... 8 more > >> Caused by: java.lang.NullPointerException > >> at > >> > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) > >> ... 15 more > >> > >> 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] > >> (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") > >> failed - address: ([("deployment" => "apiman-gateway-api.war")]) - > >> failure description: {"WFLYCTL0080: Failed services" => > >> > >> > {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" > >> => "org.jboss.msc.service.StartException in service > >> > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: > java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: > java.lang.NullPointerException > >> Caused by: java.lang.NullPointerException"}} > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/apiman-user > >> > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > From eric.wittmann at redhat.com Fri Jun 24 07:37:09 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 24 Jun 2016 07:37:09 -0400 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: <4c28eb00-7b40-fe9b-71e0-3f5cb715d6d6@redhat.com> References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> <4c28eb00-7b40-fe9b-71e0-3f5cb715d6d6@redhat.com> Message-ID: <7bb70701-5033-3acb-1448-32e81577c8fd@redhat.com> Here are two new jira issues for tracking purposes: https://issues.jboss.org/browse/APIMAN-1199 https://issues.jboss.org/browse/APIMAN-1200 -Eric On 6/24/2016 7:35 AM, Eric Wittmann wrote: > He's using 1.2.6.Final, though - so that dependency change wouldn't be > affecting him. > > I'll write up some jiras for these issues (documentation + classnotfound). > > -Eric > > On 6/24/2016 5:10 AM, Marc Savy wrote: >> You will need log4j2 onto your classpath. >> >> It was recently removed as an explicit dependency, I believe. >> >> On 23 June 2016 at 23:41, ejlp ejlp > > wrote: >> >> Hi Eric, >> >> Thanks for the answer. The package/class name was copied from >> http://www.apiman.io/latest/developer-guide.html section 4.2.2.2 >> >> I have changed it and now I got following response: >> >> {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: >> org/apache/logging/log4j/LogManager\n\tat >> io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat >> io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat >> io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat >> io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat >> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >> io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat >> io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat >> io.apiman.gateway.engine.es.ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat >> io.apiman.gateway.engine.es.ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat >> io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat >> io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat >> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >> io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat >> io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat >> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown >> Source)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown >> Source)\n\tat >> io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat >> io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat >> io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat >> io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown >> Source)\n\tat >> io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat >> io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat >> io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown >> Source)\n\tat >> io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat >> io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat >> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat >> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat >> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat >> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat >> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat >> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat >> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat >> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat >> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat >> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat >> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat >> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat >> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat >> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat >> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat >> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat >> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat >> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat >> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat >> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat >> java.lang.Thread.run(Thread.java:745)\nCaused by: >> java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager >> from [Module \"deployment.apiman-gateway.war:main\" from Service >> Module Loader]\n\tat >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... >> 70 more\n"} >> >> On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann >> > wrote: >> > You are just *slightly* off in your apiman.properties >> configuration! And >> > it's understandable, as you'll see shortly. :) >> > >> > You have modified "apiman-gateway.logger-factory" to have the >> following >> > value: >> > >> > io.apiman.common.logging.log4j2.Log4j2LoggerFactory >> > >> > But instead it should be this: >> > >> > io.apiman.common.logging.slf4j.Log4j2LoggerFactory >> > >> > -Eric >> > >> > >> > On 6/22/2016 7:40 PM, ejlp ejlp wrote: >> >> >> >> Hi, >> >> >> >> I was trying to use Log Header policy but no logging message shown in >> >> Gatway's console or server.log. >> >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final >> >> >> >> This is what I've done in Gateway node: >> >> >> >> * Use extracted war of apiman-gateway-api.war and apiman-gateway.war >> >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into >> >> >> /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ >> >> and >> /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ >> >> * Remove following line from apiman.properties >> >> >> >> >> >> >> apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory >> >> >> >> and put this line: >> >> >> >> >> >> >> apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory >> >> >> >> * Restart JBoss EAP >> >> >> >> I got following stacktrace when EAP started: >> >> >> >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService Thread >> >> Pool -- 64) MSC000001: Failed to start service >> >> >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> >> org.jboss.msc.service.StartException in service >> >> >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> >> java.lang.RuntimeException: java.lang.RuntimeException: >> >> java.lang.NullPointerException >> >> at >> >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) >> >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >> >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> >> at >> >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >> >> at >> >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >> >> at java.lang.Thread.run(Thread.java:745) >> >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >> >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: >> >> java.lang.NullPointerException >> >> at >> >> >> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) >> >> at >> >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) >> >> at >> >> >> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >> >> ... 6 more >> >> Caused by: java.lang.RuntimeException: java.lang.NullPointerException >> >> at >> >> >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) >> >> at >> >> >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) >> >> at >> >> >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) >> >> at >> >> >> io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) >> >> at >> io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) >> >> at >> >> >> io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) >> >> at >> >> >> io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) >> >> at >> >> >> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) >> >> ... 8 more >> >> Caused by: java.lang.NullPointerException >> >> at >> >> >> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) >> >> ... 15 more >> >> >> >> 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] >> >> (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") >> >> failed - address: ([("deployment" => "apiman-gateway-api.war")]) - >> >> failure description: {"WFLYCTL0080: Failed services" => >> >> >> >> >> {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" >> >> => "org.jboss.msc.service.StartException in service >> >> >> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >> >> java.lang.RuntimeException: java.lang.RuntimeException: >> >> java.lang.NullPointerException >> >> Caused by: java.lang.RuntimeException: >> java.lang.RuntimeException: >> >> java.lang.NullPointerException >> >> Caused by: java.lang.RuntimeException: >> java.lang.NullPointerException >> >> Caused by: java.lang.NullPointerException"}} >> >> _______________________________________________ >> >> Apiman-user mailing list >> >> Apiman-user at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> >> > >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Fri Jun 24 07:43:10 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 24 Jun 2016 07:43:10 -0400 Subject: [Apiman-user] Red Hat has acquired 3scale! In-Reply-To: References: <3a891965-c827-bb70-bd83-afbf21908bbb@redhat.com> Message-ID: <49bec847-f0d3-cea3-cc1f-8a9c90b10906@redhat.com> Thanks for this note, it is much appreciated. It's really helpful to know what the pros and cons are for each project, from the perspective of someone outside them! :) -Eric On 6/23/2016 10:58 PM, ejlp ejlp wrote: > I hope this will bring goodness for both.. > > I've tried 3scale, it has some nice capabilities e.g. more granular > metric and policy, and it has billing capability that currently APIMan > doesn't have yet. > > But I like APIMan because its flexibility to create plug-in, it has so > many policies (rules) that already provided, policies can be added in > API definition, plan (contract) and event client app definition. In > 3scale, AFAIK, we have to manually doing LUA scripting in the NGINX > for creating policy, even just for simple policy e.g. IP address white > list. > > And I like APIMan since it use Java :-) > > Keep up a good work guys.. > > On Jun 24, 2016 12:59 AM, "Eric Wittmann" > wrote: > > Hey everyone. I'm sure that by now many of you have heard about Red > Hat's acquisition of 3scale, a commercial vendor of API Management > software. If you're wondering how this impacts apiman, I have written a > short blog post on the topic: > > http://www.apiman.io/blog/apiman/3scale/2016/06/22/redhat-3scale-apiman.html > > It's still quite early, but I've included as much information as I > know. :) > > -Eric > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Fri Jun 24 08:24:34 2016 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 24 Jun 2016 13:24:34 +0100 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: <7bb70701-5033-3acb-1448-32e81577c8fd@redhat.com> References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> <4c28eb00-7b40-fe9b-71e0-3f5cb715d6d6@redhat.com> <7bb70701-5033-3acb-1448-32e81577c8fd@redhat.com> Message-ID: I wonder what the nicest strategy for this kind of stuff is, where we have support for multiple loggers but don't want to ship the jars by default. Maybe we need to have a lib folder or something that we deploy automatically? Or just instructions as to where to put those jar(s) so they're on the class-path. On 24 June 2016 at 12:37, Eric Wittmann wrote: > Here are two new jira issues for tracking purposes: > > https://issues.jboss.org/browse/APIMAN-1199 > https://issues.jboss.org/browse/APIMAN-1200 > > -Eric > > > On 6/24/2016 7:35 AM, Eric Wittmann wrote: > >> He's using 1.2.6.Final, though - so that dependency change wouldn't be >> affecting him. >> >> I'll write up some jiras for these issues (documentation + classnotfound). >> >> -Eric >> >> On 6/24/2016 5:10 AM, Marc Savy wrote: >> >>> You will need log4j2 onto your classpath. >>> >>> It was recently removed as an explicit dependency, I believe. >>> >>> On 23 June 2016 at 23:41, ejlp ejlp >> > wrote: >>> >>> Hi Eric, >>> >>> Thanks for the answer. The package/class name was copied from >>> http://www.apiman.io/latest/developer-guide.html section 4.2.2.2 >>> >>> I have changed it and now I got following response: >>> >>> >>> {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: >>> org/apache/logging/log4j/LogManager\n\tat >>> >>> io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat >>> >>> io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat >>> >>> io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat >>> >>> io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat >>> >>> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >>> >>> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >>> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >>> >>> io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat >>> >>> io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat >>> io.apiman.gateway.engine.es >>> .ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat >>> io.apiman.gateway.engine.es >>> .ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat >>> >>> io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat >>> >>> io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat >>> >>> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >>> >>> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >>> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >>> >>> io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat >>> >>> io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat >>> >>> io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat >>> >>> io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat >>> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown >>> Source)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown >>> Source)\n\tat >>> >>> io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat >>> >>> io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat >>> >>> io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat >>> >>> io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown >>> Source)\n\tat >>> >>> io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat >>> >>> io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat >>> >>> io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown >>> Source)\n\tat >>> >>> io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat >>> >>> io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat >>> io.apiman.gateway.engine.es >>> .CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat >>> >>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat >>> >>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat >>> >>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat >>> >>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat >>> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat >>> >>> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat >>> >>> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>> >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat >>> >>> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> >>> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat >>> >>> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> >>> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat >>> >>> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat >>> >>> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat >>> >>> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat >>> >>> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat >>> >>> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> >>> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat >>> >>> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat >>> >>> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat >>> >>> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat >>> >>> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat >>> java.lang.Thread.run(Thread.java:745)\nCaused by: >>> java.lang.ClassNotFoundException: org.apache.logging.log4j.LogManager >>> from [Module \"deployment.apiman-gateway.war:main\" from Service >>> Module Loader]\n\tat >>> >>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat >>> >>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat >>> >>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat >>> >>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... >>> 70 more\n"} >>> >>> On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann >>> > wrote: >>> > You are just *slightly* off in your apiman.properties >>> configuration! And >>> > it's understandable, as you'll see shortly. :) >>> > >>> > You have modified "apiman-gateway.logger-factory" to have the >>> following >>> > value: >>> > >>> > io.apiman.common.logging.log4j2.Log4j2LoggerFactory >>> > >>> > But instead it should be this: >>> > >>> > io.apiman.common.logging.slf4j.Log4j2LoggerFactory >>> > >>> > -Eric >>> > >>> > >>> > On 6/22/2016 7:40 PM, ejlp ejlp wrote: >>> >> >>> >> Hi, >>> >> >>> >> I was trying to use Log Header policy but no logging message >>> shown in >>> >> Gatway's console or server.log. >>> >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final >>> >> >>> >> This is what I've done in Gateway node: >>> >> >>> >> * Use extracted war of apiman-gateway-api.war and >>> apiman-gateway.war >>> >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into >>> >> >>> >>> /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ >>> >> and >>> /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ >>> >> * Remove following line from apiman.properties >>> >> >>> >> >>> >> >>> >>> apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory >>> >> >>> >> and put this line: >>> >> >>> >> >>> >> >>> >>> apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory >>> >> >>> >> * Restart JBoss EAP >>> >> >>> >> I got following stacktrace when EAP started: >>> >> >>> >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] (ServerService >>> Thread >>> >> Pool -- 64) MSC000001: Failed to start service >>> >> >>> >>> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >>> >> org.jboss.msc.service.StartException in service >>> >> >>> >>> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >>> >> java.lang.RuntimeException: java.lang.RuntimeException: >>> >> java.lang.NullPointerException >>> >> at >>> >> >>> >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) >>> >> at >>> >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) >>> >> at java.util.concurrent.FutureTask.run(FutureTask.java:266) >>> >> at >>> >> >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) >>> >> at >>> >> >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) >>> >> at java.lang.Thread.run(Thread.java:745) >>> >> at org.jboss.threads.JBossThread.run(JBossThread.java:320) >>> >> Caused by: java.lang.RuntimeException: java.lang.RuntimeException: >>> >> java.lang.NullPointerException >>> >> at >>> >> >>> >>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) >>> >> at >>> >> >>> >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) >>> >> at >>> >> >>> >>> org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) >>> >> ... 6 more >>> >> Caused by: java.lang.RuntimeException: >>> java.lang.NullPointerException >>> >> at >>> >> >>> >>> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) >>> >> at >>> >> >>> >>> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) >>> >> at >>> >> >>> >>> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) >>> >> at >>> >> >>> >>> io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) >>> >> at >>> io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) >>> >> at >>> >> >>> >>> io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) >>> >> at >>> >> >>> >>> io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) >>> >> at >>> >> >>> >>> io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) >>> >> ... 8 more >>> >> Caused by: java.lang.NullPointerException >>> >> at >>> >> >>> >>> io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) >>> >> ... 15 more >>> >> >>> >> 05:58:00,695 ERROR [org.jboss.as.controller.management-operation] >>> >> (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") >>> >> failed - address: ([("deployment" => "apiman-gateway-api.war")]) - >>> >> failure description: {"WFLYCTL0080: Failed services" => >>> >> >>> >> >>> >>> {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" >>> >> => "org.jboss.msc.service.StartException in service >>> >> >>> >>> jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: >>> >> java.lang.RuntimeException: java.lang.RuntimeException: >>> >> java.lang.NullPointerException >>> >> Caused by: java.lang.RuntimeException: >>> java.lang.RuntimeException: >>> >> java.lang.NullPointerException >>> >> Caused by: java.lang.RuntimeException: >>> java.lang.NullPointerException >>> >> Caused by: java.lang.NullPointerException"}} >>> >> _______________________________________________ >>> >> Apiman-user mailing list >>> >> Apiman-user at lists.jboss.org >>> >> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >> >>> > >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user >>> >>> >>> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160624/f6550983/attachment-0001.html From eric.wittmann at redhat.com Fri Jun 24 09:13:29 2016 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 24 Jun 2016 09:13:29 -0400 Subject: [Apiman-user] How to set apiman logging (NullPointerException when using Log4j2LoggerFactory) In-Reply-To: References: <0b049b21-1889-5494-4dfc-3946356e69a7@redhat.com> <4c28eb00-7b40-fe9b-71e0-3f5cb715d6d6@redhat.com> <7bb70701-5033-3acb-1448-32e81577c8fd@redhat.com> Message-ID: <473f8b07-f21f-1400-f819-3840098419a0@redhat.com> Perhaps it would be better to release individual logger implementations as plugins, which would allow us to package the necessary libraries in the plugin, sandboxing them from the rest of apiman. -Eric On 6/24/2016 8:24 AM, Marc Savy wrote: > I wonder what the nicest strategy for this kind of stuff is, where we > have support for multiple loggers but don't want to ship the jars by > default. Maybe we need to have a lib folder or something that we deploy > automatically? Or just instructions as to where to put those jar(s) so > they're on the class-path. > > On 24 June 2016 at 12:37, Eric Wittmann > wrote: > > Here are two new jira issues for tracking purposes: > > https://issues.jboss.org/browse/APIMAN-1199 > https://issues.jboss.org/browse/APIMAN-1200 > > -Eric > > > On 6/24/2016 7:35 AM, Eric Wittmann wrote: > > He's using 1.2.6.Final, though - so that dependency change > wouldn't be > affecting him. > > I'll write up some jiras for these issues (documentation + > classnotfound). > > -Eric > > On 6/24/2016 5:10 AM, Marc Savy wrote: > > You will need log4j2 onto your classpath. > > It was recently removed as an explicit dependency, I believe. > > On 23 June 2016 at 23:41, ejlp ejlp > >> wrote: > > Hi Eric, > > Thanks for the answer. The package/class name was copied > from > http://www.apiman.io/latest/developer-guide.html section > 4.2.2.2 > > I have changed it and now I got following response: > > > {"responseCode":500,"message":"org/apache/logging/log4j/LogManager","trace":"java.lang.NoClassDefFoundError: > org/apache/logging/log4j/LogManager\n\tat > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory.createLogger(Log4j2LoggerFactory.java:35)\n\tat > > io.apiman.gateway.engine.policy.PolicyContextImpl.getLogger(PolicyContextImpl.java:115)\n\tat > > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:75)\n\tat > > io.apiman.plugins.log_policy.LogHeadersPolicy.doApply(LogHeadersPolicy.java:36)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:104)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy$1.handle(RateLimitingPolicy.java:91)\n\tat > io.apiman.gateway.engine.es > .ESRateLimiterComponent.updateBucketAndReturn(ESRateLimiterComponent.java:115)\n\tat > io.apiman.gateway.engine.es > .ESRateLimiterComponent.accept(ESRateLimiterComponent.java:83)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:91)\n\tat > > io.apiman.gateway.engine.policies.RateLimitingPolicy.doApply(RateLimitingPolicy.java:45)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:80)\n\tat > > io.apiman.gateway.engine.policies.BasicAuthenticationPolicy.doApply(BasicAuthenticationPolicy.java:45)\n\tat > > io.apiman.gateway.engine.policies.AbstractMappedPolicy.apply(AbstractMappedPolicy.java:70)\n\tat > > io.apiman.gateway.engine.policy.RequestChain.applyPolicy(RequestChain.java:68)\n\tat > > io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:148)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:271)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$110/1594790599.handle(Unknown > Source)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$loadPolicies$7(ApiRequestExecutorImpl.java:631)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$112/863872294.handle(Unknown > Source)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:192)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl$1.handle(PolicyFactoryImpl.java:170)\n\tat > > io.apiman.gateway.engine.impl.DefaultPluginRegistry.lambda$loadPlugin$18(DefaultPluginRegistry.java:185)\n\tat > > io.apiman.gateway.engine.impl.DefaultPluginRegistry$$Lambda$113/366500518.handle(Unknown > Source)\n\tat > > io.apiman.gateway.engine.impl.DefaultPluginRegistry.loadPlugin(DefaultPluginRegistry.java:234)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl.doLoadFromPlugin(PolicyFactoryImpl.java:170)\n\tat > > io.apiman.gateway.engine.policy.PolicyFactoryImpl.loadPolicy(PolicyFactoryImpl.java:109)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:603)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$6(ApiRequestExecutorImpl.java:391)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$$Lambda$111/1559374006.handle(Unknown > Source)\n\tat > > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:172)\n\tat > > io.apiman.gateway.engine.impl.SecureRegistryWrapper$3.handle(SecureRegistryWrapper.java:154)\n\tat > io.apiman.gateway.engine.es > .CachingESRegistry.getContract(CachingESRegistry.java:101)\n\tat > > io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat > > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:357)\n\tat > > io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat > > io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat > > javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat > > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat > > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat > > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat > > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat > > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat > > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat > > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat > > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat > > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat > > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:285)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:264)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat > > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:175)\n\tat > > io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat > > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:792)\n\tat > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat > java.lang.Thread.run(Thread.java:745)\nCaused by: > java.lang.ClassNotFoundException: > org.apache.logging.log4j.LogManager > from [Module \"deployment.apiman-gateway.war:main\" from > Service > Module Loader]\n\tat > > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)\n\tat > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)\n\tat > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)\n\tat > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)\n\t... > 70 more\n"} > > On Thu, Jun 23, 2016 at 7:26 PM, Eric Wittmann > > >> wrote: > > You are just *slightly* off in your apiman.properties > configuration! And > > it's understandable, as you'll see shortly. :) > > > > You have modified "apiman-gateway.logger-factory" to > have the > following > > value: > > > > io.apiman.common.logging.log4j2.Log4j2LoggerFactory > > > > But instead it should be this: > > > > io.apiman.common.logging.slf4j.Log4j2LoggerFactory > > > > -Eric > > > > > > On 6/22/2016 7:40 PM, ejlp ejlp wrote: > >> > >> Hi, > >> > >> I was trying to use Log Header policy but no logging > message shown in > >> Gatway's console or server.log. > >> I am using JBoss EAP 7.0 and Apiman 1.2.6.Final > >> > >> This is what I've done in Gateway node: > >> > >> * Use extracted war of apiman-gateway-api.war and > apiman-gateway.war > >> * Put apiman-common-logging-log4j2-1.2.6.Final.jar into > >> > > /standalone/deployment/apiman-gateway-api.war/WEB-INF/lib/ > >> and > > /standalone/deployment/apiman-gateway.war/WEB-INF/lib/ > >> * Remove following line from apiman.properties > >> > >> > >> > > apiman-gateway.logger-factory=io.apiman.common.logging.impl.NoOpLoggerFactory > >> > >> and put this line: > >> > >> > >> > > apiman-gateway.logger-factory=io.apiman.common.logging.log4j2.Log4j2LoggerFactory > >> > >> * Restart JBoss EAP > >> > >> I got following stacktrace when EAP started: > >> > >> 05:58:00,693 ERROR [org.jboss.msc.service.fail] > (ServerService Thread > >> Pool -- 64) MSC000001: Failed to start service > >> > > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> org.jboss.msc.service.StartException in service > >> > > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85) > >> at > > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > >> at > java.util.concurrent.FutureTask.run(FutureTask.java:266) > >> at > >> > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > >> at > >> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > >> at java.lang.Thread.run(Thread.java:745) > >> at > org.jboss.threads.JBossThread.run(JBossThread.java:320) > >> Caused by: java.lang.RuntimeException: > java.lang.RuntimeException: > >> java.lang.NullPointerException > >> at > >> > > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:231) > >> at > >> > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100) > >> at > >> > > org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > >> ... 6 more > >> Caused by: java.lang.RuntimeException: > java.lang.NullPointerException > >> at > >> > > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:179) > >> at > >> > > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:163) > >> at > >> > > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createLoggerFactory(ConfigDrivenEngineFactory.java:152) > >> at > >> > > io.apiman.gateway.engine.impl.AbstractEngineFactory.createEngine(AbstractEngineFactory.java:60) > >> at > > io.apiman.gateway.platforms.war.WarGateway.init(WarGateway.java:55) > >> at > >> > > io.apiman.gateway.platforms.war.listeners.WarGatewayBootstrapper.contextInitialized(WarGatewayBootstrapper.java:42) > >> at > >> > > io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187) > >> at > >> > > io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198) > >> ... 8 more > >> Caused by: java.lang.NullPointerException > >> at > >> > > io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:175) > >> ... 15 more > >> > >> 05:58:00,695 ERROR > [org.jboss.as.controller.management-operation] > >> (DeploymentScanner-threads - 1) WFLYCTL0013: > Operation ("deploy") > >> failed - address: ([("deployment" => > "apiman-gateway-api.war")]) - > >> failure description: {"WFLYCTL0080: Failed services" => > >> > >> > > {"jboss.undertow.deployment.default-server.default-host./apiman-gateway-api" > >> => "org.jboss.msc.service.StartException in service > >> > > jboss.undertow.deployment.default-server.default-host./apiman-gateway-api: > >> java.lang.RuntimeException: java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: > java.lang.RuntimeException: > >> java.lang.NullPointerException > >> Caused by: java.lang.RuntimeException: > java.lang.NullPointerException > >> Caused by: java.lang.NullPointerException"}} > >> _______________________________________________ > >> Apiman-user mailing list > >> Apiman-user at lists.jboss.org > > > > >> https://lists.jboss.org/mailman/listinfo/apiman-user > >> > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/apiman-user > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > > From tomas.zuklys at gmail.com Thu Jun 30 01:58:59 2016 From: tomas.zuklys at gmail.com (=?UTF-8?Q?Tomas_=C5=BDuklys?=) Date: Thu, 30 Jun 2016 08:58:59 +0300 Subject: [Apiman-user] LIVE APIMAN deployments and Performance Message-ID: Hi APIMAN Gurus, Disregarding recent Red Hat announcement on 3scale acquisition and knowing that Red Hat will now be working on merging the 3scale and apiman technologies, we are still thinking of APIMAN as the main candidate for API management (Policy Enforcement) solution. Do you know any LIVE deployments of APIMAN with scale larger than 200 TPS per node? Any idea how many APIMAN LIVE deployments are there? Could you point me to some performance benchmarks of APIMAN, are there any? Is APIMAN stable enough for going to PRODUCTION? Thanks in advance! Best regards, Tomas Zuklys -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160630/7a0f7a70/attachment.html