Re: [Dev] Getting exception while using andes-client lib as JMS client for API Manager 3.0.

[Thusitha Thilina Dayaratne]

Are we registering the service manually or are we going to use the SPIfly
to achieve the same purpose?

Thanks
Thusitha

On Mon, Aug 21, 2017 at 10:00 PM, Abimaran Kugathasan 
wrote:

> Hi Asanka,
>
> As I checked offline with Niranjan, this SPI service introduced in C5. I'm
> checking on this further.
>
> On Mon, Aug 21, 2017 at 11:03 AM, Asanka Abeyweera 
> wrote:
>
>> Hi Abimaran and all,
>>
>> Is the requirement to expose as SPI service something introduced in
>> Carbon 5? I am curious on how it worked with APIM 2.1.0. Can't we do the
>> same thing?
>>
>> On Mon, Aug 21, 2017 at 10:48 AM, Abimaran Kugathasan 
>> wrote:
>>
>>> Hi,
>>>
>>> We are embedding Message Broker feature into API Manager 3.0 core, now
>>> API Manager will function as both MB server and client to manage its
>>> artifacts such as API, application, subscription, throttling etc between
>>> its nodes and Gateway. andes-client [1] will function as JMS client for
>>> embedded MB.
>>>
>>> I'm getting the following exception [3] while starting API Manager. When
>>> I check the OSGi console for available services with 'ls', I don't see any
>>> services from andes-client, but andes-client bundle is active. Please find
>>> the half committed PR [2].
>>>
>>> I learned that, on top of wrapping a library as OSGI bundle, we have to
>>> expose them as SPI services too. So the issue here is, andes-client library
>>> isn't exposing any SPI service to consume by carbon-jndi.
>>>
>>> Carbon team please confirm.
>>>
>>> [1]: https://github.com/wso2/andes/blob/v3.2.22/modules/orbi
>>> t/andes-client/pom.xml
>>> [2]: https://github.com/wso2/carbon-apimgt/pull/4421
>>> [3]:
>>> [2017-08-21 09:28:17,041] ERROR 
>>> {org.wso2.carbon.apimgt.core.util.BrokerUtil}
>>> - Could not create a JMS client connection from the class
>>> javax.naming.NoInitialContextException: Cannot find the
>>> InitialContextFactory org.wso2.andes.jndi.Properties
>>> FileInitialContextFactory.
>>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.la
>>> mbda$getInitialContextInternal$28(JNDIContextManagerImpl.java:118)
>>> at java.util.Optional.orElseThrow(Optional.java:290)
>>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.ge
>>> tInitialContextInternal(JNDIContextManagerImpl.java:118)
>>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.ne
>>> wInitialContext(JNDIContextManagerImpl.java:68)
>>> at org.wso2.carbon.jndi.internal.osgi.factory.DefaultContextFac
>>> tory.lambda$getInitialContext$21(DefaultContextFactory.java:68)
>>> at org.wso2.carbon.jndi.internal.util.LambdaExceptionUtils.lamb
>>> da$rethrowFunction$2(LambdaExceptionUtils.java:120)
>>> at java.util.Optional.map(Optional.java:215)
>>> at org.wso2.carbon.jndi.internal.osgi.factory.DefaultContextFac
>>> tory.getInitialContext(DefaultContextFactory.java:68)
>>> at javax.naming.spi.NamingManager.getInitialContext(NamingManag
>>> er.java:684)
>>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext
>>> .java:313)
>>> at javax.naming.InitialContext.init(InitialContext.java:244)
>>> at javax.naming.InitialContext.(InitialContext.java:216)
>>> at org.wso2.carbon.apimgt.core.impl.BrokerImpl.(BrokerImp
>>> l.java:59)
>>> at org.wso2.carbon.apimgt.core.internal.BundleActivator.start(B
>>> undleActivator.java:70)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>>> ssorImpl.java:62)
>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>> thodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>> at org.eclipse.equinox.internal.ds.model.ServiceComponent.activ
>>> ate(ServiceComponent.java:235)
>>> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.a
>>> ctivate(ServiceComponentProp.java:146)
>>> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.b
>>> uild(ServiceComponentProp.java:345)
>>> at org.eclipse.equinox.internal.ds.InstanceProcess.buildCompone
>>> nt(InstanceProcess.java:620)
>>> at org.eclipse.equinox.internal.ds.InstanceProcess.buildCompone
>>> nts(InstanceProcess.java:197)
>>> at org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolve
>>> r.java:343)
>>> at org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SC
>>> RManager.java:222)
>>> at org.eclipse.osgi.internal.serviceregistry.FilteredServiceLis
>>> tener.serviceChanged(FilteredServiceListener.java:109)
>>> at org.eclipse.osgi.internal.framework.BundleContextImpl.dispat
>>> chEvent(BundleContextImpl.java:915)
>>> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEve
>>> nt(EventManager.java:230)
>>> at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEv
>>> entSynchronous(ListenerQueue.java:148)
>>> at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.pu
>>> blishServiceEventPrivileged(ServiceRegistry.java:862)
>>> at 

Re: [Dev] [CEP] GSoC Project - Siddhi Extension Doc Auto Generation

[Sriskandarajah Suhothayan]

Thanks for the improvement.

Suho

On Mon, Aug 21, 2017 at 8:14 PM, Nadun De Silva  wrote:

> Hi,
>
> I have made the necessary changes to update the README.md as well as the
> documentation home page using the relevant headings as mentioned.
>
> Please find the changes in the PR I created. [1]
>
> This includes the following changes.
>
>- Updating the README.md file if the following headings are found.
>(The same changes that were done to the home page of the documentation
>based on the home page template)
>   - ## Features
>   - ## Latest API Docs
>- Committing and pushing to GitHub the changes made to the
>README.md file when *release:prepare* goal is run.
>
> [1] https://github.com/wso2/siddhi/pull/493
>
> Thank you!
>
> Regards,
> Nadun De Silva
>
> On Fri, Aug 18, 2017 at 12:11 PM, Chathurika Amarathunga <
> chathuri...@wso2.com> wrote:
>
>> Hi Nadun,
>>
>> Currently, It is updated the descriptions under "Feature" & "latest API
>> docs"  headings only in site when we prepare the 'README.md' as you
>> mentioned. It is not updated the description in the 'README.md' under those
>> headings. Could you please, make it updated on both 'Index.md' and
>> 'README.md' files.
>>
>> Thank you.
>>
>> Regards,
>> Chathurika Amarathunga.
>>
>> --
>> *Chathurika Amarathunga*
>> Software Engineer - WSO2
>>
>> Email: chathuri...@wso2.com
>> Mobile: +94783886224 <078%20388%206224>
>> 
>>
>
>
>
> --
>
> [image: profile_pic.jpg]
>
> Nadun De Silva
>
> Undergraduate of Computer Science and Engineering
>
> University of Moratuwa
>
> [image: GitHub.png]  [image:
> LinkedIn.png]  [image:
> Facebook.png] 
>
> Mobile:
>
> (+94) 77 8 222 607
>
> Email:
>
> nadun...@gmail.com
>



-- 

*S. Suhothayan*
Associate Director / Architect
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [ESB 4.8.1] Respond with arrays in JSON and XML formats

[Sudharma Subasinghe]

Hi Lahiru,

You can try the script mediator to build the expected response which is
better than duplicating XSLTs.

Thanks
Sudharma

On Mon, Aug 21, 2017 at 9:15 PM, Lahiru Sandaruwan  wrote:

> Hi,
>
> I want to change the responding content type based on Accept header(JSON
> or XML), sent in the request. My concern is the wrapping element of arrays.
> For example,
>
> Required Json response,
>
> [
> {
> "aaa" : "23432",
> "bbb" : "234",
> "ccc" : "asdfas"
> },
> {
> "aaa" : "23432",
> "bbb" : "234",
> "ccc" : "asdfas"
> },
> {
> "aaa" : "23432",
> "bbb" : "234",
> "ccc" : "asdfas"
> }
> ]
>
> Required XML response,
>
> 
> 
> 2342344
> 23432432432
> asdasdasd
> 
> 
> 234324
> 32432
> asdfasdf
> 
> 
> 234
> 34234
> asdf
> 
> 
>
> If I build local message with jsonArray and jsonElement as below, I could
> get the JSON response correctly. But XML response would be wrong, as it is
> not wrapped with accounts and account tags.
>
> 
> 
> 2342344
> 23432432432
> asdasdasd
> 
> 
> 234324
> 32432
> asdfasdf
> 
> 
> 234
> 34234
> asdf
> 
> 
>
> I'm building this message using a XSLT. I can think of using 2 XSLTs for
> two types. But that will duplicate XSLT just for this. Is there a better
> approach?
>
> Thanks.
> --
> --
>
> Lahiru Sandaruwan
> Associate Technical Lead,
> WSO2 Inc., http://wso2.com
>
> lean.enterprise.middleware
>
> m: +94773325954 <+94%2077%20332%205954>
> e: lahi...@wso2.com b: https://medium.com/@lahirugmg
> in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>


-- 
Sudharma Subasinghe,
Software Engineer,
WSO2 Inc.
Email: sudhar...@wso2.com 
Mobile : +94 710 565 157 <%2B94%20718%20210%20200>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Getting exception while using andes-client lib as JMS client for API Manager 3.0.

[Abimaran Kugathasan]

Hi Asanka,

As I checked offline with Niranjan, this SPI service introduced in C5. I'm
checking on this further.

On Mon, Aug 21, 2017 at 11:03 AM, Asanka Abeyweera 
wrote:

> Hi Abimaran and all,
>
> Is the requirement to expose as SPI service something introduced in
> Carbon 5? I am curious on how it worked with APIM 2.1.0. Can't we do the
> same thing?
>
> On Mon, Aug 21, 2017 at 10:48 AM, Abimaran Kugathasan 
> wrote:
>
>> Hi,
>>
>> We are embedding Message Broker feature into API Manager 3.0 core, now
>> API Manager will function as both MB server and client to manage its
>> artifacts such as API, application, subscription, throttling etc between
>> its nodes and Gateway. andes-client [1] will function as JMS client for
>> embedded MB.
>>
>> I'm getting the following exception [3] while starting API Manager. When
>> I check the OSGi console for available services with 'ls', I don't see any
>> services from andes-client, but andes-client bundle is active. Please find
>> the half committed PR [2].
>>
>> I learned that, on top of wrapping a library as OSGI bundle, we have to
>> expose them as SPI services too. So the issue here is, andes-client library
>> isn't exposing any SPI service to consume by carbon-jndi.
>>
>> Carbon team please confirm.
>>
>> [1]: https://github.com/wso2/andes/blob/v3.2.22/modules/orbi
>> t/andes-client/pom.xml
>> [2]: https://github.com/wso2/carbon-apimgt/pull/4421
>> [3]:
>> [2017-08-21 09:28:17,041] ERROR {org.wso2.carbon.apimgt.core.util.BrokerUtil}
>> - Could not create a JMS client connection from the class
>> javax.naming.NoInitialContextException: Cannot find the
>> InitialContextFactory org.wso2.andes.jndi.Properties
>> FileInitialContextFactory.
>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.la
>> mbda$getInitialContextInternal$28(JNDIContextManagerImpl.java:118)
>> at java.util.Optional.orElseThrow(Optional.java:290)
>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.ge
>> tInitialContextInternal(JNDIContextManagerImpl.java:118)
>> at org.wso2.carbon.jndi.internal.osgi.JNDIContextManagerImpl.ne
>> wInitialContext(JNDIContextManagerImpl.java:68)
>> at org.wso2.carbon.jndi.internal.osgi.factory.DefaultContextFac
>> tory.lambda$getInitialContext$21(DefaultContextFactory.java:68)
>> at org.wso2.carbon.jndi.internal.util.LambdaExceptionUtils.lamb
>> da$rethrowFunction$2(LambdaExceptionUtils.java:120)
>> at java.util.Optional.map(Optional.java:215)
>> at org.wso2.carbon.jndi.internal.osgi.factory.DefaultContextFac
>> tory.getInitialContext(DefaultContextFactory.java:68)
>> at javax.naming.spi.NamingManager.getInitialContext(NamingManag
>> er.java:684)
>> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
>> at javax.naming.InitialContext.init(InitialContext.java:244)
>> at javax.naming.InitialContext.(InitialContext.java:216)
>> at org.wso2.carbon.apimgt.core.impl.BrokerImpl.(BrokerImpl.java:59)
>> at org.wso2.carbon.apimgt.core.internal.BundleActivator.start(
>> BundleActivator.java:70)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
>> ssorImpl.java:62)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.eclipse.equinox.internal.ds.model.ServiceComponent.activ
>> ate(ServiceComponent.java:235)
>> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.a
>> ctivate(ServiceComponentProp.java:146)
>> at org.eclipse.equinox.internal.ds.model.ServiceComponentProp.b
>> uild(ServiceComponentProp.java:345)
>> at org.eclipse.equinox.internal.ds.InstanceProcess.buildCompone
>> nt(InstanceProcess.java:620)
>> at org.eclipse.equinox.internal.ds.InstanceProcess.buildCompone
>> nts(InstanceProcess.java:197)
>> at org.eclipse.equinox.internal.ds.Resolver.getEligible(Resolve
>> r.java:343)
>> at org.eclipse.equinox.internal.ds.SCRManager.serviceChanged(SC
>> RManager.java:222)
>> at org.eclipse.osgi.internal.serviceregistry.FilteredServiceLis
>> tener.serviceChanged(FilteredServiceListener.java:109)
>> at org.eclipse.osgi.internal.framework.BundleContextImpl.dispat
>> chEvent(BundleContextImpl.java:915)
>> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEve
>> nt(EventManager.java:230)
>> at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEv
>> entSynchronous(ListenerQueue.java:148)
>> at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.pu
>> blishServiceEventPrivileged(ServiceRegistry.java:862)
>> at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.pu
>> blishServiceEvent(ServiceRegistry.java:801)
>> at org.eclipse.osgi.internal.serviceregistry.ServiceRegistratio
>> nImpl.register(ServiceRegistrationImpl.java:127)
>> at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.re
>> gisterService(ServiceRegistry.java:225)
>> at 

[Dev] [ESB 4.8.1] Respond with arrays in JSON and XML formats

[Lahiru Sandaruwan]

Hi,

I want to change the responding content type based on Accept header(JSON or
XML), sent in the request. My concern is the wrapping element of arrays.
For example,

Required Json response,

[
{
"aaa" : "23432",
"bbb" : "234",
"ccc" : "asdfas"
},
{
"aaa" : "23432",
"bbb" : "234",
"ccc" : "asdfas"
},
{
"aaa" : "23432",
"bbb" : "234",
"ccc" : "asdfas"
}
]

Required XML response,



2342344
23432432432
asdasdasd


234324
32432
asdfasdf


234
34234
asdf



If I build local message with jsonArray and jsonElement as below, I could
get the JSON response correctly. But XML response would be wrong, as it is
not wrapped with accounts and account tags.



2342344
23432432432
asdasdasd


234324
32432
asdfasdf


234
34234
asdf



I'm building this message using a XSLT. I can think of using 2 XSLTs for
two types. But that will duplicate XSLT just for this. Is there a better
approach?

Thanks.
-- 
--

Lahiru Sandaruwan
Associate Technical Lead,
WSO2 Inc., http://wso2.com

lean.enterprise.middleware

m: +94773325954
e: lahi...@wso2.com b: https://medium.com/@lahirugmg
in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [CEP] GSoC Project - Siddhi Extension Doc Auto Generation

[Nadun De Silva]

Hi,

I have made the necessary changes to update the README.md as well as the
documentation home page using the relevant headings as mentioned.

Please find the changes in the PR I created. [1]

This includes the following changes.

   - Updating the README.md file if the following headings are found. (The
   same changes that were done to the home page of the documentation based on
   the home page template)
  - ## Features
  - ## Latest API Docs
   - Committing and pushing to GitHub the changes made to the
   README.md file when *release:prepare* goal is run.

[1] https://github.com/wso2/siddhi/pull/493

Thank you!

Regards,
Nadun De Silva

On Fri, Aug 18, 2017 at 12:11 PM, Chathurika Amarathunga <
chathuri...@wso2.com> wrote:

> Hi Nadun,
>
> Currently, It is updated the descriptions under "Feature" & "latest API
> docs"  headings only in site when we prepare the 'README.md' as you
> mentioned. It is not updated the description in the 'README.md' under those
> headings. Could you please, make it updated on both 'Index.md' and
> 'README.md' files.
>
> Thank you.
>
> Regards,
> Chathurika Amarathunga.
>
> --
> *Chathurika Amarathunga*
> Software Engineer - WSO2
>
> Email: chathuri...@wso2.com
> Mobile: +94783886224 <078%20388%206224>
> 
>



-- 

[image: profile_pic.jpg]

Nadun De Silva

Undergraduate of Computer Science and Engineering

University of Moratuwa

[image: GitHub.png]  [image: LinkedIn.png]
 [image: Facebook.png]


Mobile:

(+94) 77 8 222 607

Email:

nadun...@gmail.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Improve Default Claim Handler logic

[Farasath Ahamed]

Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 




On Mon, Aug 21, 2017 at 9:35 AM, Hasanthi Purnima Dissanayake <
hasan...@wso2.com> wrote:

> Hi Farasath,
>
> The logic behind returning claims in 'oidc' is based on the intersection
> of both sp requested claims and the registry defined claims for the scope.
> So in order to return a specific claims it should define in the registry
> and it should define as a requested claims.
>
> 2. Improve the fix[2] to return all claims for *openid *flow only when
>> service provider has no requested claims.
>>
>>  So why do we need to return all the claims for openid flow when the SP
> has no requested claims?
>

I think there is a small confusing here. In the our current implementation
we are returing all the claims for *openid *(not *openidconnect*) request
type[1]. So I wanted to improve the handler logic while maintaining
backward compatibility for *openid* relying parties.


[1]
https://github.com/wso2/carbon-identity-framework/blob/77b83f1d2ca172366a86476395da3062c56c4fd6/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/claims/impl/DefaultClaimHandler.java#L422



>
> Thanks,
>
> Hasanthi Dissanayake
>
> Software Engineer | WSO2
>
> E: hasan...@wso2.com
> M :0718407133| http://wso2.com 
>
> On Mon, Aug 21, 2017 at 9:11 AM, Rushmin Fernando 
> wrote:
>
>> yes, we should get rid of unwanted processing.
>>
>> IMO we should honour the configured requested claims in the service
>> provider. But I'm not aware whether there was a need to send all the claims
>> for open id.
>>
>>
>>
>> On Sat, Aug 19, 2017 at 7:48 PM, Farasath Ahamed 
>> wrote:
>>
>>> Hi All,
>>>
>>> In the current implementation of the DefaultClaimHandler[1] claim
>>> handling logic involves the below steps when retrieving claims for local
>>> and federated scenarios,
>>>
>>> 1. Loading local claims and claims mappings
>>> 2. Loading all non-empty claims of the user
>>>
>>> #1 involves several DB calls where as step #2 results in a call to the
>>> user store which means either a DB call or LDAP/AD call depending on the
>>> user store configured.
>>>
>>> Here are few shortcoming I noticed,
>>>
>>>1. If a service provider has configured no requested claims, we
>>>simply return an empty map of claims after going through the whole 
>>> process
>>>#1 and #2.
>>>2. For authentication involved with flows like OAuth which do not
>>>involve claims going through this claims handling logic doesn't make any
>>>sense.
>>>
>>>
>>> To give an idea of the performance impact, An authentication request
>>> coming into the Authentication Framework takes about 950ms to complete. Of
>>> this around 550ms is spent on handling claims (that's close to ~60%). So
>>> for an OAuth flow with authorization code or implicit flow, this is a
>>> performance hit.
>>>
>>> I initially did a fix for this[2], by returning an empty map of claims
>>> if the there were no requested claims. But this doesn't seem to work since
>>> we seem to return all available claims for *openid *flow[3].
>>>
>>> Do we have a specific reason for return all available claims in the
>>> openid flow? Shouldn't we honour service provider requested claims when
>>> sending out user claims out of the framework?
>>>
>>>
>>> I have a few improvements in my mind to overcome the problem,
>>>
>>> 1. Specifically, check for the *oauth *request type and stop executing
>>> claim handling logic.
>>> 2. Improve the fix[2] to return all claims for *openid *flow only when
>>> service provider has no requested claims.
>>>
>>> Do you see any complexities that could arise with the suggested
>>> improvements?
>>>
>>>
>>> [1] https://github.com/wso2/carbon-identity-framework/blob/m
>>> aster/components/authentication-framework/org.wso2.carbon.id
>>> entity.application.authentication.framework/src/main/java/or
>>> g/wso2/carbon/identity/application/authentication/framework/
>>> handler/claims/impl/DefaultClaimHandler.java
>>>
>>> [2] https://github.com/wso2/carbon-identity-framework/pull/961
>>>
>>> [3] https://github.com/wso2/carbon-identity-framework/blob/m
>>> aster/components/authentication-framework/org.wso2.carbon.id
>>> entity.application.authentication.framework/src/main/java/or
>>> g/wso2/carbon/identity/application/authentication/framework/
>>> handler/claims/impl/DefaultClaimHandler.java#L422
>>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer, WSO2 Inc.; http://wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 

Re: [Dev] Missing Attributes in Token Introspection Response

[KasunG Gajasinghe]

Hi,

On Mon, Aug 21, 2017 at 3:23 PM, Gayan Gunawardana  wrote:

>
>
> On Mon, Aug 21, 2017 at 1:54 PM, Farasath Ahamed 
> wrote:
>
>>
>>
>>
>> On Mon, Aug 21, 2017 at 1:23 PM, Gayan Gunawardana 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:
>>>
 Hi All,
 I think we need to add them in introspection result, since they were
 anyway present in AuthenticationResponse inside JWT.

 @Gayan,
 How about the acr, amr ?

>>> +1 we can add them too.
>>>
>>
>> Can we also consider providing an extension point to decide attributes
>> that go into the introspection response?
>>
> +1 token binding will introduce some more attributes.
>

Yep. OAuth Token Binding needs to add cnf:tbh attribute. This is defined in
[1]. However, we can make this part of the default introspection response
builder as well.

 {
   "active": true,
   "iss": "https://server.example.com;,
   "aud": "https://resource.example.org;,
   "sub": "br...@example.com"
   "iat": 1467324320,
   "exp": 1467324920,*   "cnf":{
 "tbh": "7NRBu9iDdJlYCTOqyeYuLxXv0blEA-yTpmGIrAwKAws"
   }
* }



[1]
https://tools.ietf.org/html/draft-ietf-oauth-token-binding-04#section-3.5


>
>>
>>>
 Cheers,
 Ruwan

 On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
 wrote:

> Hi Indunil,
>
> Form token introspection response I can get below attributes.
>
> {"scope":"openid","active":true,"token_type":"Bearer","exp":
> 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3JH
> ciaitPzoa","username":"admin@carbon.super"}
>
> But some of optional attributes are not included in introspection
> response
>
>sub
>   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
> ].
>   Usually a machine-readable identifier of the resource owner who
>   authorized this token.
>
>aud
>   OPTIONAL.  Service-specific string identifier or list of string
>   identifiers representing the intended audience for this token, as
>   defined in JWT [RFC7519 ].
>
>iss
>   OPTIONAL.  String representing the issuer of this token, as
>   defined in JWT [RFC7519 ].
>
> Do we have any limitation to support above attributes ?
>
>
> [1] https://tools.ietf.org/html/rfc7662
>
> Thanks,
> Gayan
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>





>>>
>>>
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>
>
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>



-- 

*Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
email: kasung AT spamfree wso2.com
linked-in: http://lk.linkedin.com/in/gajasinghe
blog: http://kasunbg.org
phone: +1 650-745-4499, 77 678 0813
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Missing Attributes in Token Introspection Response

[Gayan Gunawardana]

On Mon, Aug 21, 2017 at 1:54 PM, Farasath Ahamed  wrote:

>
>
>
> On Mon, Aug 21, 2017 at 1:23 PM, Gayan Gunawardana  wrote:
>
>>
>>
>> On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:
>>
>>> Hi All,
>>> I think we need to add them in introspection result, since they were
>>> anyway present in AuthenticationResponse inside JWT.
>>>
>>> @Gayan,
>>> How about the acr, amr ?
>>>
>> +1 we can add them too.
>>
>
> Can we also consider providing an extension point to decide attributes
> that go into the introspection response?
>
+1 token binding will introduce some more attributes.

>
>
>>
>>> Cheers,
>>> Ruwan
>>>
>>> On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi Indunil,

 Form token introspection response I can get below attributes.

 {"scope":"openid","active":true,"token_type":"Bearer","exp":
 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3JH
 ciaitPzoa","username":"admin@carbon.super"}

 But some of optional attributes are not included in introspection
 response

sub
   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
 ].
   Usually a machine-readable identifier of the resource owner who
   authorized this token.

aud
   OPTIONAL.  Service-specific string identifier or list of string
   identifiers representing the intended audience for this token, as
   defined in JWT [RFC7519 ].

iss
   OPTIONAL.  String representing the issuer of this token, as
   defined in JWT [RFC7519 ].

 Do we have any limitation to support above attributes ?


 [1] https://tools.ietf.org/html/rfc7662

 Thanks,
 Gayan
 --
 Gayan Gunawardana
 Senior Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Missing Attributes in Token Introspection Response

[Ruwan Abeykoon]

+1 on the extension point.

However, we should allow some attributes by default, and IMO the above
should be default in IS.

Cheers,
Ruwan

On Mon, Aug 21, 2017 at 1:54 PM, Farasath Ahamed  wrote:

>
>
>
> On Mon, Aug 21, 2017 at 1:23 PM, Gayan Gunawardana  wrote:
>
>>
>>
>> On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:
>>
>>> Hi All,
>>> I think we need to add them in introspection result, since they were
>>> anyway present in AuthenticationResponse inside JWT.
>>>
>>> @Gayan,
>>> How about the acr, amr ?
>>>
>> +1 we can add them too.
>>
>
> Can we also consider providing an extension point to decide attributes
> that go into the introspection response?
>
>
>>
>>> Cheers,
>>> Ruwan
>>>
>>> On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
>>> wrote:
>>>
 Hi Indunil,

 Form token introspection response I can get below attributes.

 {"scope":"openid","active":true,"token_type":"Bearer","exp":
 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3JH
 ciaitPzoa","username":"admin@carbon.super"}

 But some of optional attributes are not included in introspection
 response

sub
   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
 ].
   Usually a machine-readable identifier of the resource owner who
   authorized this token.

aud
   OPTIONAL.  Service-specific string identifier or list of string
   identifiers representing the intended audience for this token, as
   defined in JWT [RFC7519 ].

iss
   OPTIONAL.  String representing the issuer of this token, as
   defined in JWT [RFC7519 ].

 Do we have any limitation to support above attributes ?


 [1] https://tools.ietf.org/html/rfc7662

 Thanks,
 Gayan
 --
 Gayan Gunawardana
 Senior Software Engineer; WSO2 Inc.; http://wso2.com/
 Email: ga...@wso2.com
 Mobile: +94 (71) 8020933

>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>


-- 

*Ruwan Abeykoon*
*Associate Director/Architect**,*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Missing Attributes in Token Introspection Response

[Farasath Ahamed]

On Mon, Aug 21, 2017 at 1:23 PM, Gayan Gunawardana  wrote:

>
>
> On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:
>
>> Hi All,
>> I think we need to add them in introspection result, since they were
>> anyway present in AuthenticationResponse inside JWT.
>>
>> @Gayan,
>> How about the acr, amr ?
>>
> +1 we can add them too.
>

Can we also consider providing an extension point to decide attributes that
go into the introspection response?


>
>> Cheers,
>> Ruwan
>>
>> On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
>> wrote:
>>
>>> Hi Indunil,
>>>
>>> Form token introspection response I can get below attributes.
>>>
>>> {"scope":"openid","active":true,"token_type":"Bearer","exp":
>>> 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3JH
>>> ciaitPzoa","username":"admin@carbon.super"}
>>>
>>> But some of optional attributes are not included in introspection
>>> response
>>>
>>>sub
>>>   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
>>> ].
>>>   Usually a machine-readable identifier of the resource owner who
>>>   authorized this token.
>>>
>>>aud
>>>   OPTIONAL.  Service-specific string identifier or list of string
>>>   identifiers representing the intended audience for this token, as
>>>   defined in JWT [RFC7519 ].
>>>
>>>iss
>>>   OPTIONAL.  String representing the issuer of this token, as
>>>   defined in JWT [RFC7519 ].
>>>
>>> Do we have any limitation to support above attributes ?
>>>
>>>
>>> [1] https://tools.ietf.org/html/rfc7662
>>>
>>> Thanks,
>>> Gayan
>>> --
>>> Gayan Gunawardana
>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>>> Email: ga...@wso2.com
>>> Mobile: +94 (71) 8020933
>>>
>>
>>
>>
>>
>>
>
>
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Missing Attributes in Token Introspection Response

[Gayan Gunawardana]

On Mon, Aug 21, 2017 at 1:21 PM, Ruwan Abeykoon  wrote:

> Hi All,
> I think we need to add them in introspection result, since they were
> anyway present in AuthenticationResponse inside JWT.
>
> @Gayan,
> How about the acr, amr ?
>
+1 we can add them too.

>
> Cheers,
> Ruwan
>
> On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana 
> wrote:
>
>> Hi Indunil,
>>
>> Form token introspection response I can get below attributes.
>>
>> {"scope":"openid","active":true,"token_type":"Bearer","exp":
>> 1503061170,"iat":1503057570,"client_id":"oRbEK6KkycbSLGxt3J
>> HciaitPzoa","username":"admin@carbon.super"}
>>
>> But some of optional attributes are not included in introspection
>> response
>>
>>sub
>>   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
>> ].
>>   Usually a machine-readable identifier of the resource owner who
>>   authorized this token.
>>
>>aud
>>   OPTIONAL.  Service-specific string identifier or list of string
>>   identifiers representing the intended audience for this token, as
>>   defined in JWT [RFC7519 ].
>>
>>iss
>>   OPTIONAL.  String representing the issuer of this token, as
>>   defined in JWT [RFC7519 ].
>>
>> Do we have any limitation to support above attributes ?
>>
>>
>> [1] https://tools.ietf.org/html/rfc7662
>>
>> Thanks,
>> Gayan
>> --
>> Gayan Gunawardana
>> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
>> Email: ga...@wso2.com
>> Mobile: +94 (71) 8020933
>>
>
>
>
>
>


-- 
Gayan Gunawardana
Senior Software Engineer; WSO2 Inc.; http://wso2.com/
Email: ga...@wso2.com
Mobile: +94 (71) 8020933
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Missing Attributes in Token Introspection Response

[Ruwan Abeykoon]

Hi All,
I think we need to add them in introspection result, since they were anyway
present in AuthenticationResponse inside JWT.

@Gayan,
How about the acr, amr ?

Cheers,
Ruwan

On Mon, Aug 21, 2017 at 11:08 AM, Gayan Gunawardana  wrote:

> Hi Indunil,
>
> Form token introspection response I can get below attributes.
>
> {"scope":"openid","active":true,"token_type":"Bearer","
> exp":1503061170,"iat":1503057570,"client_id":"
> oRbEK6KkycbSLGxt3JHciaitPzoa","username":"admin@carbon.super"}
>
> But some of optional attributes are not included in introspection response
>
>sub
>   OPTIONAL.  Subject of the token, as defined in JWT [RFC7519 
> ].
>   Usually a machine-readable identifier of the resource owner who
>   authorized this token.
>
>aud
>   OPTIONAL.  Service-specific string identifier or list of string
>   identifiers representing the intended audience for this token, as
>   defined in JWT [RFC7519 ].
>
>iss
>   OPTIONAL.  String representing the issuer of this token, as
>   defined in JWT [RFC7519 ].
>
> Do we have any limitation to support above attributes ?
>
>
> [1] https://tools.ietf.org/html/rfc7662
>
> Thanks,
> Gayan
> --
> Gayan Gunawardana
> Senior Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB4] Removing Hazelcast dependency from common coordination tasks

[Indika Sampath]

+1 for removing Hazelcast from MB4 code base.

On Mon, Aug 21, 2017 at 12:58 PM, Asanka Abeyweera 
wrote:

> Hi all,
>
> We are still using Hazelcast for some common tasks even though we
> alternatively have the RDBMS based coordination implementation. I am
> planning to refactor code to remove those Hazelcast tasks in MB4.
>
> I could see that we are using Hazelcast for following tasks,
>
>- Hazelcast node addresses are maintained in Node details for
>consumption by an MBean service. Since we are planning to use REST services
>as an alternative to admin service, we can get rid of this. Additionally,
>in a non-Hazelcast environment, it does not make sense to maintain the
>Hazelcast node addresses.
>- To check if the node IDs are duplicated, a Hazelcase map is
>maintained. We can remove this when we use the RDBMS based coordination.
>- A unique ID generated using a Hazelcast ID generator is used as a
>parameter in generating cluster-wide unique IDs. Since we are focusing
>mainly on the 2 node HA deployment we do not need a cluster-wide unique
>message ID. If we need a cluster-wide unique ID we can later implement an
>algorithm on top of the RDBMS based coordination.
>
>
> WDYT?
>
> --
> Asanka Abeyweera
> Senior Software Engineer
> WSO2 Inc.
>
> Phone: +94 712228648 <+94%2071%20222%208648>
> Blog: a5anka.github.io
>
> 
>



-- 
Indika Sampath
Associate Technical Lead
WSO2 Inc.
http://wso2.com

Phone: +94 716 424 744
Blog: http://indikasampath.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [MB4] Removing Hazelcast dependency from common coordination tasks

[Ramith Jayasinghe]

+1

On Mon, Aug 21, 2017 at 12:58 PM, Asanka Abeyweera 
wrote:

> Hi all,
>
> We are still using Hazelcast for some common tasks even though we
> alternatively have the RDBMS based coordination implementation. I am
> planning to refactor code to remove those Hazelcast tasks in MB4.
>
> I could see that we are using Hazelcast for following tasks,
>
>- Hazelcast node addresses are maintained in Node details for
>consumption by an MBean service. Since we are planning to use REST services
>as an alternative to admin service, we can get rid of this. Additionally,
>in a non-Hazelcast environment, it does not make sense to maintain the
>Hazelcast node addresses.
>- To check if the node IDs are duplicated, a Hazelcase map is
>maintained. We can remove this when we use the RDBMS based coordination.
>- A unique ID generated using a Hazelcast ID generator is used as a
>parameter in generating cluster-wide unique IDs. Since we are focusing
>mainly on the 2 node HA deployment we do not need a cluster-wide unique
>message ID. If we need a cluster-wide unique ID we can later implement an
>algorithm on top of the RDBMS based coordination.
>
>
> WDYT?
>
> --
> Asanka Abeyweera
> Senior Software Engineer
> WSO2 Inc.
>
> Phone: +94 712228648 <071%20222%208648>
> Blog: a5anka.github.io
>
> 
>



-- 
Ramith Jayasinghe
Technical Lead
WSO2 Inc., http://wso2.com
lean.enterprise.middleware

E: ram...@wso2.com
P: +94 777542851
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [MB4] Removing Hazelcast dependency from common coordination tasks

[Asanka Abeyweera]

Hi all,

We are still using Hazelcast for some common tasks even though we
alternatively have the RDBMS based coordination implementation. I am
planning to refactor code to remove those Hazelcast tasks in MB4.

I could see that we are using Hazelcast for following tasks,

   - Hazelcast node addresses are maintained in Node details for
   consumption by an MBean service. Since we are planning to use REST services
   as an alternative to admin service, we can get rid of this. Additionally,
   in a non-Hazelcast environment, it does not make sense to maintain the
   Hazelcast node addresses.
   - To check if the node IDs are duplicated, a Hazelcase map is
   maintained. We can remove this when we use the RDBMS based coordination.
   - A unique ID generated using a Hazelcast ID generator is used as a
   parameter in generating cluster-wide unique IDs. Since we are focusing
   mainly on the 2 node HA deployment we do not need a cluster-wide unique
   message ID. If we need a cluster-wide unique ID we can later implement an
   algorithm on top of the RDBMS based coordination.


WDYT?

-- 
Asanka Abeyweera
Senior Software Engineer
WSO2 Inc.

Phone: +94 712228648
Blog: a5anka.github.io


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Display the roles of a custom user store for Identity Server

[Thomas LEGRAND]

Hello Isura,

As I said, I modified my custom user store to prefix the names of the users
with the domain name. So I modified, the method doListUsers to have the
following:

@Override
> public String[] doListUsers(String filter, int maxItemLimit) throws
> UserStoreException {
> LOGGER.info("doListUsers()");
> return new String[]{"CUSTOM/Lala", "CUSTOM/Toto", "CUSTOM/Titi",
> "CUSTOM/Jeje"};
> }


Of course, "CUSTOM" is the defined domain name I used to configure my user
store on the IS.

So I can see list my names [1] but when I want to retrieve the roles via
the "View roles" button in the list, I have the following stack trace and
so, the popup in [2] which appears:

[2017-08-21 08:57:16,158]  INFO
> {fr.icl.picsel20.user.store.CustomUserStoreManager} -  getRoleListOfUser()
> [2017-08-21 08:57:16,158] DEBUG
> {org.wso2.carbon.user.core.common.AbstractUserStoreManager} -  Retrieving
> internal roles for user name :  Jeje and search filter *
> [2017-08-21 08:57:16,158] ERROR
> {org.wso2.carbon.user.core.common.AbstractUserStoreManager} -  Error
> occurred while accessing Java Security Manager Privilege Block
> [2017-08-21 08:57:16,158] ERROR {org.wso2.carbon.user.mgt.UserRealmProxy}
> -  org.wso2.carbon.user.core.UserStoreException: Error occurred while
> accessing Java Security Manager Privilege Block
> [2017-08-21 08:57:16,174] ERROR
> {org.wso2.carbon.user.mgt.ui.UserAdminClient} -  Error occurred while
> accessing Java Security Manager Privilege Block
> org.wso2.carbon.user.mgt.stub.UserAdminUserAdminException:
> UserAdminUserAdminException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at
> org.wso2.carbon.user.mgt.stub.UserAdminStub.getRolesOfUser(UserAdminStub.java:3054)
> at
> org.wso2.carbon.user.mgt.ui.UserAdminClient.getRolesOfUser(UserAdminClient.java:154)
> at
> org.apache.jsp.user.view_002droles_jsp._jspService(view_002droles_jsp.java:263)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:439)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:395)
> at
> org.apache.jasper.servlet.JspServlet.service(JspServlet.java:339)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at org.wso2.carbon.ui.JspServlet.service(JspServlet.java:155)
> at
> org.wso2.carbon.ui.TilesJspServlet.service(TilesJspServlet.java:80)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at
> org.eclipse.equinox.http.helper.ContextPathServletAdaptor.service(ContextPathServletAdaptor.java:37)
> at
> org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:128)
> at
> org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:68)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
> at
> org.wso2.carbon.tomcat.ext.servlet.DelegationServlet.service(DelegationServlet.java:68)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
> at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:747)
> at
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:603)
> at
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:542)
> at
> org.eclipse.equinox.http.servlet.internal.RequestDispatcherAdaptor.include(RequestDispatcherAdaptor.java:37)
> at
> org.eclipse.equinox.http.helper.ContextPathServletAdaptor$RequestDispatcherAdaptor.include(ContextPathServletAdaptor.java:369)
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary.java:897)
> at
> org.apache.jasper.runtime.PageContextImpl.doInclude(PageContextImpl.java:688)
> at
> org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:682)
> at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 

Re: [Dev] Where is the create publishers, streams and receivers page in wso2das-4.0.0-M6

[Sagar Kapadia]

Thanks Grainier. I will check it out
Regards,
Sagar

On Mon, Aug 21, 2017 at 7:13 AM, Grainier Perera  wrote:

> Hi Sagar,
>
> From SP 4.0.0-MX [1] (formerly DASw-4.0.0-MX) <, we don't have a
> management console page (localhost:9443/carbon). Instead, we have the
> editor. Also, there are some changes to key concepts such as receivers
> and publishers. Instead of receivers and publishers, we have a new
> concept called event source[2] and event sink[3], which can be defined
> within the Siddhi App (execution plan) it self. Therefore, you don't have
> to create streams, receivers, and publishers separately as you did in DAS
> 3.1.0.
>
> Note: You can find the latest milestone release at [4] with further
> improvements.
>
> [1] https://docs.wso2.com/display/SP400/
> [2] https://docs.wso2.com/display/SP400/Receiving+Events
> [3] https://docs.wso2.com/display/SP400/Publishing+Events
> [4] https://github.com/wso2/product-sp/releases/download/v4.
> 0.0-M9/wso2sp-4.0.0-M9.zip
>
> Regards,
> Grainier.
>
> On Sat, Jul 22, 2017 at 11:04 AM, Sagar Kapadia 
> wrote:
>
>> Hi,
>> I installed wso2das-4.0.0-M6, and ran it using the "editor.bat" command.
>> However, I cant figure out where is the localhost:9443/carbon page which
>> was present in wso2das-3.1.0. I need that to create
>> streams, publishers and receivers. The composer in wso2das-4.0.0-M6
>> allows me to handle events by linking streams. But where do I create the
>> steams, receivers and publishers themselves?
>> Sagar
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Grainier Perera
> Senior Software Engineer
> Mobile : +94716122384
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev