You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@stratos.apache.org by Imesh Gunaratne <im...@apache.org> on 2015/01/04 05:44:11 UTC

[Discuss] Feedback on Java Cartridge Agent Extendibility Behaviour

Hi Devs,

This is to give $subject, I noticed following implementation:


IMO this is not a proper extendibility design, according to this
implementation users could completely replace the cartridge agent with any
Java class. In real life if we were to extend a car we don't simply replace
the entire car with another, we use extendibility points to extend it. A
similar concept applies to software components.

One other point is that here CartridgeAgent is not an interface or an
abstract class, in the above logic c.newInstance() casts the object to
CartridgeAgent, this is the default Cartridge Agent class. A custom
cartridge agent and a default cartridge agent cannot exist at the same time
with the same class name.

Thanks



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Re: [Discuss] Feedback on Java Cartridge Agent Extendibility Behaviour

Posted by Chamila De Alwis <ch...@wso2.com>.

Hi,

I also think that we should focus on introducing an extensive extension
framework through Python pluggables in the Python agent rather than having
extension points at various code paths. It allows for more control over the
agent logic and we can focus on improving the extensions rather than trying
to introduce a certain contract for the whole agent.


Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com



On Sun, Jan 4, 2015 at 12:09 PM, Imesh Gunaratne <im...@apache.org> wrote:

> Thanks for the feedback Akila. Yes there may have been a reason to
> implement this logic at that stage.
>
> Thanks
>
> On Sun, Jan 4, 2015 at 11:58 AM, Akila Ravihansa Perera <
> ravihansa@wso2.com> wrote:
>
>> Hi Imesh,
>>
>> I do agree with you here. But there may have been a reason for this
>> implementation. Perhaps looking at the Git history might give an idea. But
>> I also think that there is no point in allowing the agent to be completely
>> replaced. We're better off deploying a completely different agent rather
>> than replacing a class.
>>
>> In fact this is why more extension points were introduced for topology
>> events. I believe we can re-factor agent code to support more extensibility
>> for the cartridge agent.
>>
>> I went through the Python agent code and it seems this is not the case
>> for it [1]. Since we're planning deprecate Java agent, we can focus on
>> improving the extensibility in Python agent. Hence my proposal for
>> pluggable extensions architecture for Python agent, see mail thread
>> "Pluggable Extensions Framework for Python Cartridge Agent". I'm sorry I
>> couldn't continue with that discussion after that. I'll try to come up with
>> more details on the design.
>>
>> [1]
>> https://github.com/apache/stratos/blob/master/components/org.apache.stratos.python.cartridge.agent/cartridgeagent/cartridgeagent/agent.py#L341
>>
>> Thanks.
>>
>>
>> On Sun, Jan 4, 2015 at 10:14 AM, Imesh Gunaratne <im...@apache.org>
>> wrote:
>>
>>> Hi Devs,
>>>
>>> This is to give $subject, I noticed following implementation:
>>>
>>>
>>> IMO this is not a proper extendibility design, according to this
>>> implementation users could completely replace the cartridge agent with any
>>> Java class. In real life if we were to extend a car we don't simply replace
>>> the entire car with another, we use extendibility points to extend it. A
>>> similar concept applies to software components.
>>>
>>> One other point is that here CartridgeAgent is not an interface or an
>>> abstract class, in the above logic c.newInstance() casts the object to
>>> CartridgeAgent, this is the default Cartridge Agent class. A custom
>>> cartridge agent and a default cartridge agent cannot exist at the same time
>>> with the same class name.
>>>
>>> Thanks
>>> 
>>>
>>>
>>> --
>>> Imesh Gunaratne
>>>
>>> Technical Lead, WSO2
>>> Committer & PMC Member, Apache Stratos
>>>
>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> Software Engineer, WSO2
>>
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>

Re: [Discuss] Feedback on Java Cartridge Agent Extendibility Behaviour

Posted by Imesh Gunaratne <im...@apache.org>.

Thanks for the feedback Akila. Yes there may have been a reason to
implement this logic at that stage.

Thanks

On Sun, Jan 4, 2015 at 11:58 AM, Akila Ravihansa Perera <ra...@wso2.com>
wrote:

> Hi Imesh,
>
> I do agree with you here. But there may have been a reason for this
> implementation. Perhaps looking at the Git history might give an idea. But
> I also think that there is no point in allowing the agent to be completely
> replaced. We're better off deploying a completely different agent rather
> than replacing a class.
>
> In fact this is why more extension points were introduced for topology
> events. I believe we can re-factor agent code to support more extensibility
> for the cartridge agent.
>
> I went through the Python agent code and it seems this is not the case for
> it [1]. Since we're planning deprecate Java agent, we can focus on
> improving the extensibility in Python agent. Hence my proposal for
> pluggable extensions architecture for Python agent, see mail thread
> "Pluggable Extensions Framework for Python Cartridge Agent". I'm sorry I
> couldn't continue with that discussion after that. I'll try to come up with
> more details on the design.
>
> [1]
> https://github.com/apache/stratos/blob/master/components/org.apache.stratos.python.cartridge.agent/cartridgeagent/cartridgeagent/agent.py#L341
>
> Thanks.
>
>
> On Sun, Jan 4, 2015 at 10:14 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Devs,
>>
>> This is to give $subject, I noticed following implementation:
>>
>>
>> IMO this is not a proper extendibility design, according to this
>> implementation users could completely replace the cartridge agent with any
>> Java class. In real life if we were to extend a car we don't simply replace
>> the entire car with another, we use extendibility points to extend it. A
>> similar concept applies to software components.
>>
>> One other point is that here CartridgeAgent is not an interface or an
>> abstract class, in the above logic c.newInstance() casts the object to
>> CartridgeAgent, this is the default Cartridge Agent class. A custom
>> cartridge agent and a default cartridge agent cannot exist at the same time
>> with the same class name.
>>
>> Thanks
>> 
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Akila Ravihansa Perera
> Software Engineer, WSO2
>
> Blog: http://ravihansa3000.blogspot.com
>



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Re: [Discuss] Feedback on Java Cartridge Agent Extendibility Behaviour

Posted by Akila Ravihansa Perera <ra...@wso2.com>.

Hi Imesh,

I do agree with you here. But there may have been a reason for this
implementation. Perhaps looking at the Git history might give an idea. But
I also think that there is no point in allowing the agent to be completely
replaced. We're better off deploying a completely different agent rather
than replacing a class.

In fact this is why more extension points were introduced for topology
events. I believe we can re-factor agent code to support more extensibility
for the cartridge agent.

I went through the Python agent code and it seems this is not the case for
it [1]. Since we're planning deprecate Java agent, we can focus on
improving the extensibility in Python agent. Hence my proposal for
pluggable extensions architecture for Python agent, see mail thread
"Pluggable Extensions Framework for Python Cartridge Agent". I'm sorry I
couldn't continue with that discussion after that. I'll try to come up with
more details on the design.

[1]
https://github.com/apache/stratos/blob/master/components/org.apache.stratos.python.cartridge.agent/cartridgeagent/cartridgeagent/agent.py#L341

Thanks.

On Sun, Jan 4, 2015 at 10:14 AM, Imesh Gunaratne <im...@apache.org> wrote:

> Hi Devs,
>
> This is to give $subject, I noticed following implementation:
>
>
> IMO this is not a proper extendibility design, according to this
> implementation users could completely replace the cartridge agent with any
> Java class. In real life if we were to extend a car we don't simply replace
> the entire car with another, we use extendibility points to extend it. A
> similar concept applies to software components.
>
> One other point is that here CartridgeAgent is not an interface or an
> abstract class, in the above logic c.newInstance() casts the object to
> CartridgeAgent, this is the default Cartridge Agent class. A custom
> cartridge agent and a default cartridge agent cannot exist at the same time
> with the same class name.
>
> Thanks
> 
>
>
> --
> Imesh Gunaratne
>
> Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>

-- 
Akila Ravihansa Perera
Software Engineer, WSO2

Blog: http://ravihansa3000.blogspot.com