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>
<Context>/resource</Context>
<Provider>admin</Provider>
<Endpoint>http://localhost:9763/resource</Endpoint>
<Version>1.0.0</Version>
</API>
</StartupAPIPublisher>
For the External APIM case, above configuration can be configured in the
external API Manager instance.
Thanks,
Lakmali
On 26 July 2013 10:45, Lakmali Baminiwatta <[email protected]> wrote:
> Hi all,
>
>
> On 26 July 2013 06:25, Vijitha Kumara <[email protected]> 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
> Publisher API. So for that API Publisher app should be available. I wrote a
> ServerStartupHandler implementation whose invoke() method is activated once
> the server has started. But when the process hits this invoke() method,
> login to the publisher-app/mgt-console is failing. These issues are
> discussed in *'[DEV]OSGI bundles startup order'. *
>
> So proceding with this, we have two other alternative approaches,
>
> 1. Go for a new Admin page where the Product's internal APIs are listed
> and and administrative user has the option of creating/publishing them.
> 2. When the API mgt is enabled in embedded mode, create the API by
> creating the registry artifact & database entry at the server startup. If
> API mgt is enable in external mode call the jaggery endpoint (Publisher
> API)for creating the API.
>
> Please advice.
>
> Thanks,
> Lakmali
>
>
>
> Regards,
>> Vijitha.
>>
>>
>> On Tue, Jul 23, 2013 at 7:25 AM, Vijitha Kumara <[email protected]> wrote:
>>
>>> Hi All,
>>>
>>> On Fri, Jul 19, 2013 at 3:48 PM, Senaka Fernando <[email protected]>wrote:
>>>
>>>> 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
>>>> option #2.
>>>>
>>>
>>> In addition can we also make this configurable that is embedded or
>>> external APIM? So that the user can set the appropriate URL for the latter
>>> and the APIM component can lookup and publish if that is the case. Or an
>>> optional config param only for an external APIM as we can use the default
>>> URL in case with an embedded APIM.
>>>
>>> Also we need to make sure all possible basic use cases are covered (when
>>> getting started) and user friendly specially when it is an OOTB feature.
>>>
>>>
>>>
>>> Regards,
>>> Vijitha.
>>>
>>>
>>>>
>>>> Thanks,
>>>> Senaka.
>>>>
>>>>
>>>> On Fri, Jul 19, 2013 at 3:39 PM, Sriragu Arudsothy <[email protected]>wrote:
>>>>
>>>>> 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 under the same tenant.
>>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jul 19, 2013 at 3:20 PM, Nuwan Dias <[email protected]> wrote:
>>>>>
>>>>>> On Fri, Jul 19, 2013 at 2:59 PM, Senaka Fernando <[email protected]>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
>>>>>>> needs to happen when the tenant gets loaded. That's the standard pattern
>>>>>>> which is followed by all deployers. I believe API Mgt needs a similar
>>>>>>> concept here.
>>>>>>>
>>>>>>> Understood. There is however another problem that will arise if
>>>>>> we're going to create APIs at server startup. See explanation below.
>>>>>>
>>>>>> There are two ways that we can create the API.
>>>>>> 1) Create the registry artifact and database entry.
>>>>>> 2) Call the jaggery REST endpoint for creating the API.
>>>>>>
>>>>>> Both options will work with embedded API Management. But option 1
>>>>>> will not work with external API Management since we do not know the
>>>>>> details
>>>>>> of the API registry and DB. So when going with external API Management,
>>>>>> we
>>>>>> will have to go with option 2. Therefore it would be better to stick to
>>>>>> option 2 for both cases since it'll be cleaner and have less
>>>>>> complexity. For option 2 to work, the server should already be started.
>>>>>> Therefore creating APIs at server startup in this manner would not be
>>>>>> possible AFAIK.
>>>>>>
>>>>>> Thanks,
>>>>>> NuwanD.
>>>>>>
>>>>>> Thanks,
>>>>>>> Senaka.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jul 19, 2013 at 2:48 PM, Nuwan Dias <[email protected]> wrote:
>>>>>>>
>>>>>>>> On Fri, Jul 19, 2013 at 12:35 PM, Lakmali Baminiwatta <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>> Hi Nuwan,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 19 July 2013 12:19, Nuwan Dias <[email protected]> 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 that it works
>>>>>>>>>> even with external API Management. When the API is added to the
>>>>>>>>>> registry,
>>>>>>>>>> it will be visible on the publisher (external). And when the admin
>>>>>>>>>> goes and
>>>>>>>>>> publishes it, the API will then be deployed onto the Store and
>>>>>>>>>> Gateway.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1. Agree.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Lakmali
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> NuwanD.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jul 19, 2013 at 12:10 PM, Lakmali Baminiwatta <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> We have completed the implementation of the Embedded APIM
>>>>>>>>>>> functionality, to manage GREG Rest APIs. We need to clarify how are
>>>>>>>>>>> we
>>>>>>>>>>> going to publish the GREG Rest API. Publishing the API includes
>>>>>>>>>>> following
>>>>>>>>>>> tasks,
>>>>>>>>>>>
>>>>>>>>>>> - Add the API artifact to the registry
>>>>>>>>>>> - Add the API to the APIM database
>>>>>>>>>>>
>>>>>>>>>>> So we have three options to publish the API.
>>>>>>>>>>>
>>>>>>>>>>> 1. Admin manually create the API and publish through API
>>>>>>>>>>> Publisher app. (This is what we do at the moment)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Since we're publishing internal Product APIs here, this would not
>>>>>>>> be a good option since users will not know what to publish and what
>>>>>>>> information to enter.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> 2. Publish the API at the server startup.
>>>>>>>>>>> But since this is a one time operation, there
>>>>>>>>>>> will be an overhead at each server startup, in checking whether the
>>>>>>>>>>> API has
>>>>>>>>>>> already published.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Yes, as mentioned it would be an overhead to check whether the
>>>>>>>> necessary APIs have been published at server startup.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> 3. Publish the API at the GREG pack build time.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> This will work with embedded API Management but this is not a
>>>>>>>> solution when going with External API Management.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> What would be the best option to procede with?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> Looking at the given options what I feel best is to have some kind
>>>>>>>> of an Admin page where the Product's internal APIs are listed and and
>>>>>>>> administrative user has the option of publishing them. Since we're
>>>>>>>> talking
>>>>>>>> about internal production APIs, it would also be fine to publish them
>>>>>>>> directly rather than it first being in a created state.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> NuwanD.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Lakmali
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Lakmali Baminiwatta*
>>>>>>>>>>> *
>>>>>>>>>>> Software Engineer
>>>>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>> mobile: +94 71 2335936
>>>>>>>>>>> blog : lakmali.com
>>>>>>>>>>> *
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Dev mailing list
>>>>>>>>>>> [email protected]
>>>>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Nuwan Dias
>>>>>>>>>>
>>>>>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>>>>>>>>>> email : [email protected]
>>>>>>>>>> Phone : +94 777 775 729
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Lakmali Baminiwatta*
>>>>>>>>> *
>>>>>>>>> Software Engineer
>>>>>>>>> WSO2, Inc.: http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>> mobile: +94 71 2335936
>>>>>>>>> blog : lakmali.com
>>>>>>>>> *
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Nuwan Dias
>>>>>>>>
>>>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>>>>>>>> email : [email protected]
>>>>>>>> Phone : +94 777 775 729
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> * <http://us13.wso2con.com/>
>>>>>>> *
>>>>>>> *
>>>>>>> *
>>>>>>> *Senaka Fernando*
>>>>>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com*
>>>>>>> Member; Apache Software Foundation; http://apache.org
>>>>>>>
>>>>>>> E-mail: senaka AT wso2.com
>>>>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>>>>>> Linked-In: http://linkedin.com/in/senakafernando
>>>>>>>
>>>>>>> *Lean . Enterprise . Middleware
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nuwan Dias
>>>>>>
>>>>>> Senior Software Engineer - WSO2, Inc. http://wso2.com
>>>>>> email : [email protected]
>>>>>> Phone : +94 777 775 729
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [email protected]
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> * <http://us13.wso2con.com/>
>>>> *
>>>> *
>>>> *
>>>> *Senaka Fernando*
>>>> Senior Technical Lead; WSO2 Inc.; http://wso2.com*
>>>> Member; Apache Software Foundation; http://apache.org
>>>>
>>>> E-mail: senaka AT wso2.com
>>>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818
>>>> Linked-In: http://linkedin.com/in/senakafernando
>>>>
>>>> *Lean . Enterprise . Middleware
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> [email protected]
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Vijitha Kumara
>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/
>>> email: [email protected]
>>>
>>>
>>> Lean . Enterprise . Middleware
>>>
>>
>>
>>
>> --
>> Vijitha Kumara
>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/
>> email: [email protected]
>>
>>
>> Lean . Enterprise . Middleware
>>
>
>
>
> --
> Lakmali Baminiwatta*
> *
> Software Engineer
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> mobile: +94 71 2335936
> blog : lakmali.com
> *
> *
>
--
Lakmali Baminiwatta*
*
Software Engineer
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile: +94 71 2335936
blog : lakmali.com
*
*
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
