incubator-imperius-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Autonomic Computing with Imperius
Date Mon, 12 May 2008 16:16:36 GMT
Just one comment regarding getters and setters.

>> Getters and Setters are not mandatory in Java.
>> We would need some logic to see if the method exists etc. Is this  
>> how we
>> should implement it?
>> We currently allow access to private variables through getters and  
>> setters
>> right?
>> and it can be used outside the condition block.  
>> attr1=bean.getAttr1();
>>
>> What we could do is first check if bean.attr1 is accessible (ie is  
>> public)
>> if not we can try doing
>> getAttr1() that way we remain flexible
>
I'd suggest that the first attempt should be to translate "bean.attr1"  
to bean.getAttr1() and if that method is not public then see if the  
field attr1 is public. Just reversing the proposed logic...

Craig

On May 12, 2008, at 5:26 AM, Prashant B Baliga wrote:

> Hi,
> I propose adding a new method to the Java-SPL as below to extend the
> policy infrastructure for dynamically generated classes/objects/beans.
>
> We could add a method that takes in the java object/bean and the  
> policy
> string.
> This method would use string manipulation to add the import statement
> which it would get from the object.
> The parsing/validation and evaluation could become a single flow  
> here to
> accommodate dynamic evaluation.
>
> Let me know if you have any suggestions.
>
>
> Thanks & Regards,
>
> Prashant Baliga
>
> Autonomic Computing Policy Development,
> India Software Labs, IBM Software Group
> Tivoli, IBM.
>
> http://incubator.apache.org/imperius/
> ----- Forwarded by Prashant B Baliga/India/IBM on 05/12/2008 17:44  
> -----
>
> Neeraj Joshi/Durham/IBM@IBMUS
> 05/08/2008 18:30
>
> To
> Prashant B Baliga/India/IBM@IBMIN
> cc
>
> Subject
> Re: Autonomic Computing with Imperius
>
>
>
>
>
> My comments in red
> Sorry was on vacation hence the delay in replying
> Neeraj
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "The light at the end of the tunnel...may be you"
>
>
> Neeraj Joshi
> WebSphere XD - Compute Grid
> AIM, IBM
> Apache Imperius - http://incubator.apache.org/imperius
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> Prashant B Baliga/India/IBM@IBMIN
> 04/29/2008 01:32 AM
>
> To
> Neeraj Joshi/Durham/IBM@IBMUS
> cc
>
> Subject
> Re: Autonomic Computing with Imperius
>
>
>
>
>
> Hi Neeraj,
> My comments are in blue below.
>
>
>
> Thanks & Regards,
>
> Prashant Baliga
>
> Autonomic Computing Policy Development,
> India Software Labs, IBM Software Group
> Tivoli, IBM.
>
> http://incubator.apache.org/imperius/
>
>> Neeraj Joshi <jneeraj@us.ibm.com>
> 04/22/2008 18:54
> Please respond to
> imperius-dev@incubator.apache.org
>
>
> To
> "Reza Asadollahi" <rasadoll@uwaterloo.ca>,
> imperius-dev@incubator.apache.org, imperius-user@incubator.apache.org
> cc
> David L Kaminsky <dlk@us.ibm.com>
> Subject
> Re: Autonomic Computing with Imperius
>
>
>
>
>
>
> Hi Reza,
> Thank you for your interest in trying out  SPL your comments are  
> greatly
> appreciated.
>
>> For example bean.attr1 should be translated internally to
> bean.getAttr1().
>
> I think this is a good idea and do not think it will be very hard to
> implement.
>
>> anchor classes are kind of dynamically generated classes, and I can  
>> not
> specify their class names
>
> This one is a bit tricky because a policy has a 2 phase life-cycle in
> phase 1 the policy is validated syntatically and semantically and an
> *executable* is generated and cached.
> In phase 2 the policy is evaluated using the input parameters.
>
>
> Not knowing the class name in phase 1 will naturally be a problem so  
> we
> would have to be able to support a way to evaluate on the fly...this  
> may
> require some fundamental changes.
>
> We could add a method that takes in the java object/bean and the  
> policy
> string.
> This method would use string manipulation to add the import statement
> which it would get from the object.
> The parsing/validation and evaluation could become a single flow  
> here to
> accommodate dynamic evaluation.
>
> Yeah thats a good idea
>
> We are always looking for folks to participate in our project so if  
> you
> have the cycles you could just provide us with a patch for #1 and I  
> can
> check it in.
>
> I have cc'ed this email to the community for others to comment
>
> Thanks!
> Neeraj
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "The light at the end of the tunnel...may be you"
>
>
> Neeraj Joshi
> WebSphere XD - Compute Grid
> AIM, IBM
> Apache Imperius - http://incubator.apache.org/imperius
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
> "Reza Asadollahi" <rasadoll@uwaterloo.ca>
> 04/21/2008 04:07 PM
>
> To
> David L Kaminsky/Raleigh/IBM@IBMUS, Neeraj Joshi/Durham/IBM@IBMUS
> cc
>
> Subject
> Autonomic Computing with Imperius
>
>
>
>
>
>
> Hi,
> I am doing research in the area of autonomic computing in the  
> University
> of Waterloo Canada. As part of my research, I was intending to  
> develop an
> implementation of CIM-SPL, and hopefully, I found that you did it.  
> Thank
> you so much. You did a great job, and I guess Imperius can be the  
> leader
> of policy engines in this area.
>
> I used the current version of Imperius in my project and I found a few
> limitations in the application. I would like to share them with you  
> and
> get your suggestions about them.
>
> 1.       A policy can not access the anchor class private attributes  
> via
> their getter and setter methods, and the attributes should be defined
> ?public? instead. Yes, I found that it is possible to call a getter  
> method
>
> in the ?condition? section but it is more interesting to read and  
> write
> attributes in an expression-like language. For example bean.attr1  
> should
> be translated internally to bean.getAttr1().  The idea of Java EE
> Expression Language in terms of using high-level expressions instead  
> of
> java-like code could be helpful in this context as well.
> 2.       The objects that I pass to the policies as anchor classes are
> kind of dynamically generated classes, and I can not specify their  
> class
> names in the policy file (they don?t extend a specific super class or
> interface). Hence, it is not possible to work with the anchor  
> objects in
> the policies as sensors and effectors. For example, I have a
> dynamically-generated java bean and I know that it would have have an
> attribute named ?attr1?, but I don?t know its class (and it is not
> important at all); however, I would like to able to use that java  
> bean in
> the policy. To overcome this problem, I guess it would be enough for
> Imperius to work with the passed java beans by reflection.
>
> I believe that addressing the mentioned concerns in Imperius will
> significantly improve its feature set and facilitate its usage in
> different adaptation environments.
>
> I would like to thank you for your attention to my points, and I am
> looking forward to hearing from you soon.
>
>
>
> Best Regards,
>
> Reza Asadollahi
>
>
>
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message