Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Hi Vinod,

Whenever a user changes his/her substitute, we check for a circular
dependency.  This check happens independent of the fact whether substitutes
are defined when the user are created ("modeling time") or when the
substitute of a user is changed during "runtime". Is that your
understanding too?

If a circular dependency is detected, the request for the new substitute is
not accepted.  And, yes, that's problematic because it may become quite
cumbersome or even impossible to find a possible substitute (i.e. one that
our cycle checker will accept).  For example, in case of n users U1,
U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we
have a problem. During modeling time their may be time to fix the problem,
but during runtime that may be critical.  Setting the Reserved or
inProgress tasks of the user just defining his new substitute in state
Ready doesn't help because there may be no potential owners who may get
aware about the task.

For this purpose, the key principle of Human Task is that the engine must
do everything to push tasks to (at least) Reserve status. This is done by
corresponding deadline processing, or by nomination: i.e. the engine
informs the Business Administrator of the task who then assigns the task to
an owner. But this may result in a burden of the Business Administrator in
case he will get many tasks to nominate.

So, let's discuss. My current preference is to *not accept* a change in the
substitute definition in case a cyclic structure would result.  WDYT?



Best regards,
Frank

2016-06-16 3:31 GMT+02:00 Vinod Kavinda :

> Hi Frank,
> Yes, it's when changing the substitute user. We have to use the second
> suggestion also.
>
> In a scenario where substitution starts in a future time(not just after
> changing the substitute user), we do not have the option of rejecting the
> substitution request. In such a scenario, we will have to make his tasks
> unclaimed!
>
> Regards,
> Vinod
> On Jun 16, 2016 2:28 AM, "Frank Leymann"  wrote:
>
> Hi Vinod,
>
> yes, that's a well-known issue :-)   I suggest to adopt your first
> suggestion, namely checking circular dependencies when a new substitute has
> been specified (I guess that's what you meant - not when adding a new user,
> right?).
>
>
>
> Best regards,
> Frank
>
> 2016-06-15 13:25 GMT+02:00 Vinod Kavinda :
>
>> Hi all,
>> I ran into an issue while implementing this.
>>
>> What if we ran into a *circular dependency between user substitutes*? We
>> can't calculate a transitive substitute in this scenario. No one will be
>> available to take up the tasks of the unavailable user.
>>
>> Here is my suggestion for this:
>>
>> *Circular dependency detected while adding a new user*
>> We abort this user addition and reply back to the user asking for a new
>> substitute.
>>
>> *Circular dependency detected while resolving transitive subs in a
>> scheduled event (Due to a user's substitution starting at this point )*
>>
>> Mark the transitive sub is "UNDEFINED". Future tasks that are assigning
>> to this user will be reverted back as unclaimed tasks (remove the assignee).
>>
>> Any suggestions?
>>
>>
>>
>>
>> On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda  wrote:
>>
>>> Hi Frank,
>>> Agreed.
>>> I have created Jira [1] to track this improvement after the Human Task
>>> integration with BPMN engine.
>>>
>>> [1] - https://wso2.org/jira/browse/BPS-1043
>>>
>>> Regards,
>>> Vinod
>>>
>>> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana 
>>> wrote:
>>>
 Yes, Once the task engine refactoring is complete, we can integrate our
 own task implementation with activiti . Then we can overcome the current
 limitations of user tasks.

 Regards
 Nandika

 On Wed, Jun 8, 2016 at 7:18 PM, Milinda Perera 
 wrote:

>
> On Wed, Jun 8, 2016 at 6:49 PM, Frank Leymann  wrote:
>
>> Dear Vinod,
>>
>> understood.  My recommendation is that we should argue as long as
>> possible independent from a certain implementation: if we may decide to
>> move from Activiti to Camunda, we should have the architecture/design 
>> right
>> to port our implementation with minimal effort. That's why I argue in 
>> terms
>> of the BPMN recommended state model, and when we agree on the principles 
>> we
>> can map it to the underlying engine. Does this sound acceptable?
>>
>> Which brings up the following question:  When we support User Tasks
>> in Activiti, don't we use our HumanTask implementation as User Task as 
>> BPMN
>> 2.0 assumes? But we use the simplified implementation that Activiti 
>> ships?
>> If we do the latter, what is our strategy of our HumanTask 
>> implementation?
>>
>
>
>
>  +1, Soon or Later I think replacing Activiti User Task or introducing
> as a new type of user task, with our WS-HumanTask it the best option.
> AFAIR similar idea is in our future roadmap @Hasitha @Nandika : isn't
>>>

[Architecture] [WSO2 MB] MQTT over Websockets Transport

[Pamod Sylvester]

Hi All,

As an extension of the revamped transport model discussed in [1] a
Websocket based transport implementation was extended through the Abstract
Netty Server implementation. The pipe-line for the Websocket transport is
depicted through the below diagram,

*Inbound Message Flow (pipeline)*

[image: Inline image 4]


   1. WSClient could be a web-browser or any form of a Websocket client who
   will send the request to message broker.
   2. The incoming request would be intercepted by HTTPRequestDecoder which
   will decode the message
   3. Decoded message would be aggregated through HTTPObjectAggregator
   4. Aggregated message would be handled by
   WebSocketServerProtocolHandler, which takes care of the handshake and
   processing of the control frames
   5. Once the handshake and the control messages are identified and
   processed, the Websocket frames are converted into a bytes message by
   WebSocketFrameDecoder
   6. The converted bytes message would be decoded by MQTTDecoder for
   handling MQTT message derived from Websockets.
   7. The decoded MQTT message would be given to MQTTProtocolHandler to
   handle message based on MQTT protocol. The protocol handling details of
   MQTT could be referred from [1].



*Outbound Message Flow (pipeline)*


[image: Inline image 3]


   1. The outbound message would be encoded into bytes through MQTTEncoder
   2. The bytes message would be arranged into Websocket frames by
   WebsocketServerFrameEncoder
   3. The Websocket frames would be further encoded into HTTP bytes message
   which would make it ready to be transmitted through the wire to the
   Websocket client.


[1] [Architecture] [MB] Generalizing the transport model and Revamping MQTT
transport

Thanks,
Pamod
-- 
*Pamod Sylvester *

*WSO2 Inc.; http://wso2.com *
cell: +94 77 7779495
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev][IS] Improvements in handling incorrect login attempts

[Gayan Gunawardana]

On Fri, Jun 17, 2016 at 11:53 AM, Isura Karunaratne  wrote:

> Hi Harsha,
>
> On Fri, Jun 17, 2016 at 12:53 AM, Harsha Thirimanna 
> wrote:
>
>> Hi All,
>>
>> Currently We are working on $subject.
>>
>> When user tries to login using invalid credential until reach the maximum
>> attempts count, we lock the account for some specific time. After the time,
>> we allow to user to try again and  it will be locked again after user tries
>> to login using invalid credential for the maximum attempts. Now we are
>> going to increase the lock time than the previous time. This ratio would be
>> a configurable value.
>>
>
> If we are keeping increased the time, and if the lock time reaches like
> 2hours, what is the possible ways to login the system without waiting that
> much time.  (Because the account may lock due to a hacker. Then if actual
> user tries to login what is the possible ways to login him without waiting?)
>

+1 for the idea. Actually we should not keep increasing time until it reach
to higher number like 2hours. After couple of maximum login attempts
failures we can permanently lock the account until original user
acknowledged with his identity.

>
> Once sugession would be ,confirm user through sendinag a mail to user's
> mail address. Then he can click on the link and unlock the account.
>
>
> Thanks
> Isura.
>
>
>
>> As an another improvement when a registered user tries to login to the
>> system without email confirmation, inform him verification is pending and
>> give the ability to resend the confirmation code to the registered email
>> address.
>>
>> Your comments and suggestions are highly appreciated.
>>
>> thanks
>>
>> *Harsha Thirimanna*
>> Associate Tech Lead; WSO2, Inc.; http://wso2.com
>> * *
>> *email: **hars...@wso2.com* * cell: +94 71 5186770 *
>> *twitter: **http://twitter.com/ *
>> *harshathirimannlinked-in: **http:
>> **//www.linkedin.com/pub/harsha-thirimanna/10/ab8/122
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isura Dilhara Karunaratne
> Senior Software Engineer
>
> Mob +94 772 254 810
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


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

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Sagara Gunathunga]

Got update and reduced file size to 12 MB.

BTW can't we reduce dependencies further ?  As an example we have bundled 3
JSON libraries (Gson, Json-smart, Jackson ) and 2 logging APIs
( commons-logging and SLF4J ) with above sample.

Thanks !

On Fri, Jun 17, 2016 at 1:55 PM, Afkham Azeez  wrote:

> Yes;
>
> ls -al target/helloworld-1.1.0-SNAPSHOT.jar
>
> -rw-r--r--  1 azeez  staff  *1143* Jun 16 17:23
> target/helloworld-1.1.0-SNAPSHOT.jar
>
>
>
> On Fri, Jun 17, 2016 at 1:52 PM, Thusitha Thilina Dayaratne <
> thusit...@wso2.com> wrote:
>
>> Hi Sagara,
>>
>> In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
>> removed most of the unwanted OSGi stuffs that get bundled.
>> Will check on this further.
>>
>> Thanks
>> Thusitha
>>
>> On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for
>>> other samples as well)  became 20.1 MB, I don't think this is acceptable
>>> size for a such simple sample. By looking at shade plugin I found number of
>>> unwanted OSGi Jar files get bundled with the sample's uber Jar file, we
>>> have to exclude these unwanted dependencies from parent POM files or need
>>> to refractor Carbon-transport not to import those OSGi dependencies
>>> automatically WDYT ?
>>>
>>> [INFO] Including
>>> org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0 in the shaded jar.
>>>  ( I don't think we need Zip files here)
>>>
>>> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
>>> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0 in
>>> the shaded jar.
>>> [INFO] Including
>>> org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0 in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
>>> in the shaded jar.
>>> [INFO] Including
>>> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
>>> the shaded jar.
>>> [INFO] Including
>>> org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
>>> the shaded jar.
>>> [INFO] Including
>>> org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
>>> the shaded jar.
>>> [INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
>>> shaded jar.
>>> [INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in
>>> the shaded jar.
>>> [INFO] Including 
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.cm:jar:1.1.0.v20131021-1936
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.preferences:jar:3.5.200.v20140224-1527
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator.manipulator:jar:2.0.0.v20131217-1203
>>> in the shaded jar.
>>> [INFO] Including
>>> org.wso2.eclipse.osgi:org.eclipse.osgi.compatibility.state:jar:1.0.1.v20140709-1414
>>> in the shaded jar.
>>>
>>>
>>>
>>>
>>> Thanks !
>>> --
>>> Sagara Gunathunga
>>>
>>> Architect; WSO2, Inc.;  http://wso2.com
>>> V.P Apache Web Services;http://ws.apache.org/
>>> Linkedin; http://www.linkedin.com/in/ssagara
>>> Blog ;  http://ssagara.blogspot.com
>>>
>>>
>>
>>
>> --
>> Thusitha Dayaratne
>> Software Engineer
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> Mobile  +94712756809
>> Blog  alokayasoya.blogspot.com
>> Abouthttp://about.me/thusithathilina
>>
>>
>
>
> --
> *Afkham Azeez*
> Director of Architecture; WSO2, Inc.; http://wso2.com
> Member; Apache Software Foundation; http://www.apache.org/
> * *
> *email: **az...@wso2.com* 
> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
> *http://blog.afkham.org* 
> *twitter: **http://twitter.com/afkham_azeez*
> 

Re: [Architecture] API Manager REST API Support for new Throttling feature

[Ushani Balasooriya]

Hi Malintha,

So Basically,  as an example using Rest API, if we need to get all the
available tiers, it will return only the subscription tiers by below
command.

curl -b cookies
http://localhost:9763/publisher/site/blocks/item-add/ajax/add.jag?

action=getTiers

So how can we retrieve the available tiers for application and resource
level according to APIM 2.0?

Thanks,




On Fri, Jun 17, 2016 at 1:07 PM, Malintha Amarasinghe 
wrote:

> Hi Ushani,
>
> It is not included in Beta Pack.
> Bdw, this feature is not used by the current throttling engine so it has
> no impact on the current throttling engine. It will be only used when APIM
> moves to UUF in future. So for 2.0.0 release, it is not mandatory to test
> it.
>
> Thanks!
> Malintha
>
> On Fri, Jun 17, 2016 at 12:40 PM, Ushani Balasooriya 
> wrote:
>
>> Hi Malintha,
>>
>> Is this new rest api implementation is available in APIM Beta pack? If so
>> we can test it.
>>
>> Thanks,
>> Ushani
>>
>> On Thu, Jun 9, 2016 at 10:02 AM, Malintha Amarasinghe > > wrote:
>>
>>> Hi All,
>>>
>>> I have attached the modified publisher yaml which includes new APIs for
>>> the Throttling feature. Please note API level policies are renamed to
>>> Advanced Policies with the new UI modifications.
>>>
>>> This basically contains new operations as below.
>>>
>>> *Application Policies*
>>> GET /throttling/policies/application
>>> POST /throttling/policies/application
>>> DELETE /throttling/policies/application/{policyName}
>>> PUT /throttling/policies/application/{policyName}
>>>
>>> *Subscription Policies*
>>> GET /throttling/policies/subscription
>>> POST /throttling/policies/subscription
>>> DELETE /throttling/policies/subscription/{policyName}
>>> PUT /throttling/policies/subscription/{policyName}
>>>
>>> *Global Policies*
>>> GET /throttling/policies/global
>>> POST /throttling/policies/global
>>> DELETE /throttling/policies/global/{policyName}
>>> PUT /throttling/policies/global/{policyName}
>>>
>>> *Advanced Policies*
>>> GET /throttling/policies/advanced-policies
>>> POST /throttling/policies/advanced-policies
>>> DELETE /throttling/policies/advanced-policies/{policyName}
>>> PUT /throttling/policies/advanced-policies/{policyName}
>>>
>>> *Blocking Conditions*
>>> GET /throttling/blocking-conditions
>>> POST /throttling/blocking-conditions
>>> DELETE /throttling/blocking-conditions/{conditionId}
>>> PUT /throttling/blocking-conditions/{conditionId}
>>>
>>>
>>> *Few things to note:*
>>>
>>> 1. We define an array of Conditions in Conditional Groups when defining
>>> an Advanced Policy. In implementation level, Condition is defined as a
>>> parent class and its child classes are IPCondition, DateCondition,
>>> HeaderCondition etc. In swagger level, the same concept is used using
>>> swagger "allOf"[1] parameter to avoid the duplicated fields.
>>>
>>> 2. When defining a Conditional Group, the array of Conditions can be of
>>> those multiple types of Conditions (defined in polymorphic way) and that is
>>> also need to represented from JSON payload.
>>>
>>> Ex: *A sample Advanced Policy JSON object*
>>>
>>> {
>>>   "policyName": "AdvancedPolicy-1",
>>>   "displayName": "AdvancedPolicy-1 Description",
>>>   ...
>>>   "conditionalGroups": [
>>> {
>>>   "id": 0,
>>>   "enabled": true,
>>>   "description": "conditional group 1",
>>>   "conditions": [
>>> *{*
>>> *  "type": "HeaderCondition",*
>>> *  "invertCondition": false,*
>>> *  "enabled": true,*
>>> *  "headerName" : "Content-Type"*
>>> *  "headerValue" : "application/json"*
>>> *},*
>>> *{*
>>> *  "type": "QueryParameterCondition",*
>>> *  "invertCondition": false,*
>>> *  "enabled": true,*
>>> *  "parameterName" : "token",*
>>> *  "parametervalue" : "123" *
>>> *}*
>>>   ],
>>>   "quotaPolicy": {
>>> ..
>>>   }
>>> }
>>>   ]
>>> }
>>>
>>> From the REST API Web app, those Conditions need to be mapped to the
>>> correct data type. For that @JsonSubTypes annotation was used.
>>>
>>> Ex:
>>>
>>> @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = 
>>> JsonTypeInfo.As.PROPERTY, property = "type")
>>> @JsonSubTypes({
>>> @JsonSubTypes.Type(value = 
>>> org.wso2.carbon.apimgt.rest.api.publisher.dto.DateConditionDTO.class, name 
>>> = "DateCondition"),
>>> @JsonSubTypes.Type(value = 
>>> org.wso2.carbon.apimgt.rest.api.publisher.dto.HeaderConditionDTO.class, 
>>> name = "HeaderCondition"),
>>> @JsonSubTypes.Type(value = 
>>> org.wso2.carbon.apimgt.rest.api.publisher.dto.QueryParameterConditionDTO.class,
>>>  name = "QueryParameterCondition"),
>>>
>>> 
>>> })
>>> @ApiModel(description = "Throttling Conditions")
>>> public class ThrottleConditionDTO  {
>>>
>>> Now CXF will now do the mapping of the JSON -> DTO correctly based to the 
>>> *type *field of the JSON object.
>>>
>>> Ex:
>>> {
>>> 

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Afkham Azeez]

Yes;

ls -al target/helloworld-1.1.0-SNAPSHOT.jar

-rw-r--r--  1 azeez  staff  *1143* Jun 16 17:23
target/helloworld-1.1.0-SNAPSHOT.jar



On Fri, Jun 17, 2016 at 1:52 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:

> Hi Sagara,
>
> In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
> removed most of the unwanted OSGi stuffs that get bundled.
> Will check on this further.
>
> Thanks
> Thusitha
>
> On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga 
> wrote:
>
>>
>> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for
>> other samples as well)  became 20.1 MB, I don't think this is acceptable
>> size for a such simple sample. By looking at shade plugin I found number of
>> unwanted OSGi Jar files get bundled with the sample's uber Jar file, we
>> have to exclude these unwanted dependencies from parent POM files or need
>> to refractor Carbon-transport not to import those OSGi dependencies
>> automatically WDYT ?
>>
>> [INFO] Including org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0
>> in the shaded jar.  ( I don't think we need Zip files here)
>>
>> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
>> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0 in
>> the shaded jar.
>> [INFO] Including
>> org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0 in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
>> in the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
>> the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
>> the shaded jar.
>> [INFO] Including
>> org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
>> the shaded jar.
>> [INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
>> shaded jar.
>> [INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in
>> the shaded jar.
>> [INFO] Including 
>> org.wso2.eclipse.equinox:org.eclipse.equinox.cm:jar:1.1.0.v20131021-1936
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.preferences:jar:3.5.200.v20140224-1527
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator.manipulator:jar:2.0.0.v20131217-1203
>> in the shaded jar.
>> [INFO] Including
>> org.wso2.eclipse.osgi:org.eclipse.osgi.compatibility.state:jar:1.0.1.v20140709-1414
>> in the shaded jar.
>>
>>
>>
>>
>> Thanks !
>> --
>> Sagara Gunathunga
>>
>> Architect; WSO2, Inc.;  http://wso2.com
>> V.P Apache Web Services;http://ws.apache.org/
>> Linkedin; http://www.linkedin.com/in/ssagara
>> Blog ;  http://ssagara.blogspot.com
>>
>>
>
>
> --
> Thusitha Dayaratne
> Software Engineer
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> Mobile  +94712756809
> Blog  alokayasoya.blogspot.com
> Abouthttp://about.me/thusithathilina
>
>


-- 
*Afkham Azeez*
Director of Architecture; WSO2, Inc.; http://wso2.com
Member; Apache Software Foundation; http://www.apache.org/
* *
*email: **az...@wso2.com* 
* cell: +94 77 3320919blog: **http://blog.afkham.org*

*twitter: **http://twitter.com/afkham_azeez*

*linked-in: **http://lk.linkedin.com/in/afkhamazeez
*

*Lean . Enterprise . Middleware*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] MSF4J Helloworld sample size > 20 MB ?

[Thusitha Thilina Dayaratne]

Hi Sagara,

In the latest pack the helloworld sample is 12.2 MB. AFAIR Azeeze has
removed most of the unwanted OSGi stuffs that get bundled.
Will check on this further.

Thanks
Thusitha

On Fri, Jun 17, 2016 at 1:43 PM, Sagara Gunathunga  wrote:

>
> In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for other
> samples as well)  became 20.1 MB, I don't think this is acceptable size for
> a such simple sample. By looking at shade plugin I found number of unwanted
> OSGi Jar files get bundled with the sample's uber Jar file, we have to
> exclude these unwanted dependencies from parent POM files or need to
> refractor Carbon-transport not to import those OSGi dependencies
> automatically WDYT ?
>
> [INFO] Including org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0
> in the shaded jar.  ( I don't think we need Zip files here)
>
> [INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
> [INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0 in
> the shaded jar.
> [INFO] Including org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
> in the shaded jar.
> [INFO] Including
> org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
> the shaded jar.
> [INFO] Including
> org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
> the shaded jar.
> [INFO] Including
> org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
> the shaded jar.
> [INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
> shaded jar.
> [INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in the
> shaded jar.
> [INFO] Including 
> org.wso2.eclipse.equinox:org.eclipse.equinox.cm:jar:1.1.0.v20131021-1936
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.preferences:jar:3.5.200.v20140224-1527
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator.manipulator:jar:2.0.0.v20131217-1203
> in the shaded jar.
> [INFO] Including
> org.wso2.eclipse.osgi:org.eclipse.osgi.compatibility.state:jar:1.0.1.v20140709-1414
> in the shaded jar.
>
>
>
>
> Thanks !
> --
> Sagara Gunathunga
>
> Architect; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>


-- 
Thusitha Dayaratne
Software Engineer
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

Mobile  +94712756809
Blog  alokayasoya.blogspot.com
Abouthttp://about.me/thusithathilina
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] MSF4J Helloworld sample size > 20 MB ?

[Sagara Gunathunga]

In MSF4J 1.1.0-SNAPSHOT version helloworld sample size ( same go for other
samples as well)  became 20.1 MB, I don't think this is acceptable size for
a such simple sample. By looking at shade plugin I found number of unwanted
OSGi Jar files get bundled with the sample's uber Jar file, we have to
exclude these unwanted dependencies from parent POM files or need to
refractor Carbon-transport not to import those OSGi dependencies
automatically WDYT ?

[INFO] Including org.wso2.carbon:org.wso2.carbon.kernel.feature:zip:5.1.0
in the shaded jar.  ( I don't think we need Zip files here)

[INFO] Including org.osgi:org.osgi.core:jar:6.0.0 in the shaded jar.
[INFO] Including org.wso2.carbon:org.wso2.carbon.tools.core:jar:5.1.0 in
the shaded jar.
[INFO] Including org.wso2.carbon:org.wso2.carbon.runtime.feature:zip:5.1.0
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.launcher.gtk.linux.x86:jar:1.1.200.v20150204-1316
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.common:jar:3.6.200.v20130402-1505
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator:jar:1.1.0.v20131217-1203
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.util:jar:1.0.500.v20130404-1337
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.ds:jar:1.4.200.v20131126-2331
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.launcher:jar:1.3.0.v20140415-2008
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.concurrent:jar:1.1.0.v20130327-1442
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin:jar:2.0.100.v20131209-2144
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.frameworkadmin.equinox:jar:1.0.500.v20131211-1531
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.console:jar:1.1.0.v20140131-1639
in the shaded jar.
[INFO] Including
org.apache.felix:org.apache.felix.gogo.command:jar:0.10.0.v201209301215 in
the shaded jar.
[INFO] Including
org.apache.felix:org.apache.felix.gogo.shell:jar:0.10.0.v201212101605 in
the shaded jar.
[INFO] Including
org.apache.felix:org.apache.felix.gogo.runtime:jar:0.10.0.v201209301036 in
the shaded jar.
[INFO] Including org.ops4j.pax.logging:pax-logging-api:jar:1.8.5 in the
shaded jar.
[INFO] Including org.ops4j.pax.logging:pax-logging-log4j2:jar:1.8.5 in the
shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.cm:jar:1.1.0.v20131021-1936
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.preferences:jar:3.5.200.v20140224-1527
in the shaded jar.
[INFO] Including
org.wso2.eclipse.equinox:org.eclipse.equinox.simpleconfigurator.manipulator:jar:2.0.0.v20131217-1203
in the shaded jar.
[INFO] Including
org.wso2.eclipse.osgi:org.eclipse.osgi.compatibility.state:jar:1.0.1.v20140709-1414
in the shaded jar.




Thanks !
-- 
Sagara Gunathunga

Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS] DCR implementation

[Lalaji Sureshika]

Hi Harsha,

As per your mail,it's going to support the client registration management
spec [1],but you haven't mentioned about support for update/get client
operations and only delete operation..And if we are going to support
this,as per [1],there are some additional response attributes need to be
set in DCR response [eg: a URI pointing to the client configuration
endpoint which will be use for update/delete/get clients]..I think we
should check this as well..

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


Thanks;

On Fri, Jun 17, 2016 at 11:35 AM, Nuwan Dias  wrote:

> Where is the DCR runtime? I presume its in a separate jax-rs hosted on the
> IS itself?
>
> Using a valve to handle authentication/authorization won't be ideal IMO. A
> valve would get hit with every request that the server receives, so it will
> impact performance. Can't we use a jax-rs filter or a cxf interceptor? If
> different products need to customise the authentication/authorization part,
> they can do so by overriding the filter/interceptor configurations.
>
> And I think the default authorization mode should be such that the DCR is
> only permitted for users with the admin "permission". We could perhaps
> maintain the permission string in the web.xml so that people can override
> it if required.
>
> Thanks,
> NuwanD.
>
> On Fri, Jun 17, 2016 at 2:20 AM, Johann Nallathamby 
> wrote:
>
>>
>>
>> On Thu, Jun 16, 2016 at 10:18 PM, Farasath Ahamed 
>> wrote:
>>
>>> Hi Harsha,
>>>
>>> When implementing User Managed Access 1.0 for WSO2 Identity Server, we
>>> implemented a valve similar to what you have proposed here. You can find
>>> the implemented tomcat valve here[1]. Since the endpoints implemented for
>>> UMA were OAuth protected, the idea was to do the OAuth token validation at
>>> the valve and pass the result to each endpoint by setting the token
>>> validation response as an attribute in the request forwarded to the
>>> endpoint.
>>>
>>>
>>> [1]
>>> https://github.com/mefarazath/carbon-identity/blob/gsoc-uma/components/tomcat-valve/src/main/java/org/wso2/carbon/identity/tomcat/valve/OAuthAccessTokenValidatorValve.java
>>>
>>
>> +1.
>>
>> I think it was the same code that was reused by EMM team in their DCR
>> implementation to do authentication, which is now ported by Harsha to IS,
>> except Harsha didn't port the authentication piece yet, because we decided
>> it needs to be externalized from the DCR implementation.
>>
>> Check mail thread [2] also for related discussion.
>> [2] Decoupling client_id/client_secret based OAuth 2.0 client
>> authentication from the token endpoint
>>
>>
>>>
>>> Thanks,
>>> Farasath Ahamed
>>> Software Engineer,
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>>
>>> Email: farasa...@wso2.com
>>> Mobile: +94777603866
>>> Blog: blog.farazath.com
>>> Twitter: @farazath619 
>>>
>>> On Fri, Jun 17, 2016 at 1:12 AM, Harsha Thirimanna 
>>> wrote:
>>>
 Hi All,

 We have covered three [1], [2], [3] specification(not fully, but mostly
 used areas) with this feature.

 ​OAuth application registration and delete
 OIDC application registration.

 *Client Registration Request*

 To register a new Client at the Authorization Server, the Client sends
 an HTTP POST message to the Client Registration Endpoint with any Client
 Metadata parameters that the Client chooses to specify for itself during
 the registration. The Authorization Server assigns this Client a unique
 Client Identifier, optionally assigns a Client Secret, and associates the
 Metadata given in the request with the issued Client Identifier.

 *Sample Request*

 POST /identity/connect/register HTTP/1.1
 Content-Type: application/json
 Accept: application/json
 Host: server.example.com

 {
 "redirect_uris": ["server.example.com"],
 "client_name": "rest_api_store_1",
 "ext_param_owner": "admin",
 "grant_types": ["password"]
 }


 *Response*

 HTTP/1.1 201 Created
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache

 {
 "client_id": "s6BhdRkqt3",
 "client_secret":
 "ZJYCqe3GGRvdrudKyZS0XhGv_Z45DuKhCUk0gBR1vZk",
 "client_secret_expires_at": 1577858400,
 "redirect_uris":
 ["server.example.com"],
 "client_name": "admin_rest_api_store_1"
 }


 *Error Response*

 HTTP/1.1 400 Bad Request
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache

 {
 "error": "invalid_redirect_uri",
 "error_description": "One or more redirect_uri values are invalid"
 }


 *Client UnRegistration Request*

 To deprovision itself on the authorization server, the client makes
 an HTTP DELETE request to the client configuration endpoint.
 DELETE /identity/register/s6BhdRkqt3 HT