Hi Sumedha, Lakmali,
+1 for the fix. However, small suggestion to make the endpoint optional, if
somebody wanted to automatically register G-Reg's resource API in a remote
AM instance or if they have a proxy/LB in front of G-Reg. Lakmali, I'm
assuming that this is possible, if not, that's an
Hi,
On 5 August 2013 11:43, Senaka Fernando sen...@wso2.com wrote:
Hi Sumedha, Lakmali,
+1 for the fix. However, small suggestion to make the endpoint optional,
if somebody wanted to automatically register G-Reg's resource API in a
remote AM instance or if they have a proxy/LB in front of
Hi,
For adding the API while server startup, new configuration has added to the
api-manager.xml. By enabling this configuration in Greg, new API will be
added to the Publisher in CREATED state.
StartupAPIPublisher
!--Define many API elements as below to publish many APIs --
API
On Sun, Aug 4, 2013 at 6:21 PM, Lakmali Baminiwatta lakm...@wso2.comwrote:
Hi,
For adding the API while server startup, new configuration has added to
the api-manager.xml. By enabling this configuration in Greg, new API will
be added to the Publisher in CREATED state.
StartupAPIPublisher
Please update the status on this as we need to finalize the work for the
release. Note what is supported for this release and what's pending etc...
Regards,
Vijitha.
On Tue, Jul 23, 2013 at 7:25 AM, Vijitha Kumara viji...@wso2.com wrote:
Hi All,
On Fri, Jul 19, 2013 at 3:48 PM, Senaka
Hi all,
On 26 July 2013 06:25, Vijitha Kumara viji...@wso2.com wrote:
Please update the status on this as we need to finalize the work for the
release. Note what is supported for this release and what's pending etc...
I was working on publishing the API at the server startup by calling the
Hi,
I think the API should initially be in a created state rather than being in
a published state. The admin or whoever responsible should publish it
through the publisher.
We also need to make this a generic solution so that it works even with
external API Management. When the API is added to
Hi Nuwan,
On 19 July 2013 12:19, Nuwan Dias nuw...@wso2.com wrote:
Hi,
I think the API should initially be in a created state rather than being
in a published state. The admin or whoever responsible should publish it
through the publisher.
We also need to make this a generic solution so
On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta lakm...@wso2.comwrote:
Hi Nuwan,
On 19 July 2013 12:19, Nuwan Dias nuw...@wso2.com wrote:
Hi,
I think the API should initially be in a created state rather than being
in a published state. The admin or whoever responsible should
Hi all,
I think its best to publish the API at server start-up. This is because the
DB can be cleaned at start-up etc, and asking someone to add the whole
thing manually is also not so usable. However, I think what Nuwan suggests
is also good, because the admin needs to decide as to whether these
Hi Nuwan,
I think the check at start-up is not going to be very expensive. During
server start-up we do several checks for services too. It will become
expensive if you try to do the same for all tenants of course. Such needs
to happen when the tenant gets loaded. That's the standard pattern
On Fri, Jul 19, 2013 at 2:59 PM, Senaka Fernando sen...@wso2.com wrote:
Hi Nuwan,
I think the check at start-up is not going to be very expensive. During
server start-up we do several checks for services too. It will become
expensive if you try to do the same for all tenants of course. Such
Hi Nuwan,
I agree to you. I also have done the second option calling
jaggery REST endpoint to publish the REST API. I tested using a menu item
click on it will publish the REST API after Greg server start up. User who
has certain permission may publish the REST API if not published
Hi Nuwan,
I believe that you should be able to determine the availability of the
required components using @scr annotations isn't it? Before looking into
other options such as onLogin, I think its best to experiment with that
possibility which would make it possible for us to easily make use of
14 matches
Mail list logo
