You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iota.apache.org by Lucas Berri Cristofolini <lu...@gmail.com> on 2017/07/03 15:02:50 UTC
Re: Fey-core and Spring integration
OK, we've run some more tests and changed a couple things... Everything
should be good to go now.
Is there some sort of "standard procedure" to contribute these changes to
the IOTA project? Is just opening a PR on girhub OK or is there something
else to it?
Cheers!
Lucas
On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
lucascristofolini@gmail.com> wrote:
> OK, we figured it out. Managed to get it going by adding the proper merge
> strategies.
>
> And we've finally managed to get Spring dependency injection working!
> We'll run some more tests to make sure everything is up to standard and
> then we can discuss how we can contribute this functionality to the project.
>
> Cheers!
> Lucas
>
> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
> rafaelweingartner@gmail.com> wrote:
>
>> Spring is packaged with AOP classes. Can you check who is bringing the
>> aopalliance-1.0.jar?
>>
>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>> lucascristofolini@gmail.com> wrote:
>>
>>> OK, so I've gotten to the point of testing our new design and ran into a
>>> problem.
>>>
>>> As soon as I add the spring framework as a build dependency on sbt, I
>>> seem to run into some merge conflicts with other dependencies (?).
>>>
>>> I'm not familiar with the sbt build system at all so I figured I should
>>> ask you guys for ideas, I'll attach the build log (terminal output) and the
>>> files changed to this email, so you guys can see what I'm doing (the
>>> changes really come down to adding a line for the spring dependency and
>>> adding that variable to the fey project's compile-time dependencies).
>>>
>>> In the meantime, I'll read up on how sbt handles this sort of thing and
>>> see if I can figure it out.
>>>
>>> Cheers!
>>> Lucas
>>>
>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>> rafaelweingartner@gmail.com> wrote:
>>>
>>>> We are not. Our doubt was regarding agents/performers/actors
>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>> (right?).
>>>>
>>>>
>>>> We want dependency injection, and some of this "service" objects will
>>>> have connections to other systems (e.g. database systems), so we wanted to
>>>> check if AKKA required agents to be serializable; from our reading of AKKA
>>>> documentation, this was not clear. Then we asked you guys here (it seems
>>>> you are quite used to work with AKKA) and today I checked with AKKA
>>>> community.
>>>>
>>>>
>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>> right? (The topic of some other email exchange we had some time ago).
>>>> We are working without AKKA (Fey) clustering for now; after fixing the bits
>>>> for dependency injection we will take a look at this.
>>>>
>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <ba...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Rafael,
>>>>>
>>>>> Glad you guys figured that out.
>>>>> As I said in one of the previous thread, Fey does not support remote
>>>>> actors, so I'm not sure how are you guys able to instanciate an actor in a
>>>>> different JVM using fey.
>>>>>
>>>>> Do you mind explain it ?
>>>>>
>>>>> Barbara Gomes
>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>
>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>
>>>>> We found the answer for those questions.
>>>>> In summary:
>>>>> An ActorRef can be thought of as an address. Yes, we can send it over
>>>>> to other JVMs (so long as they are in the same cluster), and can be used to
>>>>> send messages to that Actor.
>>>>> However (and this is Very Very Important), this isn't a remote
>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>> ever. Instead, you send them messages.
>>>>>
>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>
>>>>>> In a more direct question, do agents instances need to be
>>>>>> serializable?
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>
>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>> discussing ideas for a possible alternative.
>>>>>>>
>>>>>>> When reading the documentation on akka actors and props (
>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>> following statement about the ActorRef type:
>>>>>>>
>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>> across the network."
>>>>>>>
>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>> separate JVM?
>>>>>>>
>>>>>>> Cheers!
>>>>>>> Lucas
>>>>>>>
>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>
>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>> trick.
>>>>>>>>
>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>
>>>>>>>> If using Spring for the ActorSystem is interesting to the project
>>>>>>>> as a whole, we could consider making some changes to make that work...
>>>>>>>>
>>>>>>>> I'll keep working on this as is for now. Let me know what you guys
>>>>>>>> think about the ActorSystem idea.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Lucas
>>>>>>>>
>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>
>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> So after a while pondering and going back and forth between a few
>>>>>>>>>> possible implementations, I think we're on to something interesting.
>>>>>>>>>>
>>>>>>>>>> Let me try and give you guys an outline of the design we came up
>>>>>>>>>> with:
>>>>>>>>>>
>>>>>>>>>> - Create an Akka extension that will load the Spring context,
>>>>>>>>>> as shown here -> https://github.com/typesafehub
>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to be
>>>>>>>>>> interpreted from the orchestration JSON. One to specify that the performers
>>>>>>>>>> within that orchestration will be using Spring (so that we can call the
>>>>>>>>>> alternate method mentioned above); and another one specifying the path for
>>>>>>>>>> the Spring context file
>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>
>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Lucas
>>>>>>>>>>
>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> That sounds good.
>>>>>>>>>>>
>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>
>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>
>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>
>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>
>>>>>>>>>>> I'll try to get something up and running and report back. Once
>>>>>>>>>>> we get it going maybe we can discuss a feature proposal and eventually even
>>>>>>>>>>> bringing full spring integration to the fey core.
>>>>>>>>>>>
>>>>>>>>>>> Cheers!
>>>>>>>>>>> Lucas
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>
>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>
>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>
>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the Spring
>>>>>>>>>>>> framework into Fey. Which would be a bit more complex, since Fey would have
>>>>>>>>>>>> to instantiate the Spring context and the Actor System would also have to
>>>>>>>>>>>> be instantiated using the Spring context. Which would imply that all the
>>>>>>>>>>>> necessary configuration for the Spring framework would have to be defined
>>>>>>>>>>>> upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>
>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>
>>>>>>>>>>>> I personally think that it would be awesome if we could work on
>>>>>>>>>>>> both approaches. Here are my reasons:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>
>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>
>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>
>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some class
>>>>>>>>>>>> load issues when the performer's dependencies are fairly complex. As an
>>>>>>>>>>>> example, we wrote an Apache Ignite performer and we had to go to some hoops
>>>>>>>>>>>> to get the Spring dependencies loaded in runtime, in fact, the final fix
>>>>>>>>>>>> was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it seems
>>>>>>>>>>>>> that, as far as Akka is concerned, upon creating an Actor, we could pass a
>>>>>>>>>>>>> DependencyInjector and an ApplicationContext within the actor's Props.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey
>>>>>>>>>>>>> would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing
>>>>>>>>>>>>> this feature to the fey-engine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of
>>>>>>>>>>>>>> its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would have consequences on the performer constructor; we
>>>>>>>>>>>>>> would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you guys think about this? We can work to create this
>>>>>>>>>>>>>> integration after we discussed the changes that would be applied to Fey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Barbara Gomes
>>>>>>>>> Computer Engineer
>>>>>>>>> San Jose, CA
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rafael Weingärtner
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>>
>>>
>>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>
Re: Fey-core and Spring integration
Posted by Tony Faustini <to...@litbit.com>.
Yes, will get feedback to you today. It looks good but will see if Barbara has any comments.
-Tony
> On Jul 10, 2017, at 7:49 AM, Rafael Weingärtner <ra...@gmail.com> wrote:
>
> Tony, Barbara, can we get a feedback on this one?
>
> On Tue, Jul 4, 2017 at 3:03 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
> For contributors in Apache, as far as I know, there is no agreement that need to be signed. For, committers there is the ICLA.
>
> On Tue, Jul 4, 2017 at 3:01 PM, Tony Faustini <tony@litbit.com <ma...@litbit.com>> wrote:
> Awesome! There might. A contributors agreement I will check.
> Tony
>
> Sent from my iPhone
>
> On Jul 3, 2017, at 8:02 AM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>
>> OK, we've run some more tests and changed a couple things... Everything should be good to go now.
>>
>> Is there some sort of "standard procedure" to contribute these changes to the IOTA project? Is just opening a PR on girhub OK or is there something else to it?
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>> OK, we figured it out. Managed to get it going by adding the proper merge strategies.
>>
>> And we've finally managed to get Spring dependency injection working! We'll run some more tests to make sure everything is up to standard and then we can discuss how we can contribute this functionality to the project.
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
>> Spring is packaged with AOP classes. Can you check who is bringing the aopalliance-1.0.jar?
>>
>>
>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>> OK, so I've gotten to the point of testing our new design and ran into a problem.
>>
>> As soon as I add the spring framework as a build dependency on sbt, I seem to run into some merge conflicts with other dependencies (?).
>>
>> I'm not familiar with the sbt build system at all so I figured I should ask you guys for ideas, I'll attach the build log (terminal output) and the files changed to this email, so you guys can see what I'm doing (the changes really come down to adding a line for the spring dependency and adding that variable to the fey project's compile-time dependencies).
>>
>> In the meantime, I'll read up on how sbt handles this sort of thing and see if I can figure it out.
>>
>> Cheers!
>> Lucas
>>
>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
>> We are not. Our doubt was regarding agents/performers/actors requirements, when we read the requirement for AKKA, which Fey uses (right?).
>>
>>
>>
>> We want dependency injection, and some of this "service" objects will have connections to other systems (e.g. database systems), so we wanted to check if AKKA required agents to be serializable; from our reading of AKKA documentation, this was not clear. Then we asked you guys here (it seems you are quite used to work with AKKA) and today I checked with AKKA community.
>>
>>
>>
>> I think by supporting remote actors you mean using AKKA clustering, right? (The topic of some other email exchange we had some time ago). We are working without AKKA (Fey) clustering for now; after fixing the bits for dependency injection we will take a look at this.
>>
>>
>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <barbaramaltagomes@gmail.com <ma...@gmail.com>> wrote:
>> Hi Rafael,
>>
>> Glad you guys figured that out.
>> As I said in one of the previous thread, Fey does not support remote actors, so I'm not sure how are you guys able to instanciate an actor in a different JVM using fey.
>>
>> Do you mind explain it ?
>>
>> Barbara Gomes
>> +1 (650) 713-6092 <tel:+1%20650-713-6092>
>>
>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
>>
>>> We found the answer for those questions.
>>> In summary:
>>> An ActorRef can be thought of as an address. Yes, we can send it over to other JVMs (so long as they are in the same cluster), and can be used to send messages to that Actor.
>>> However (and this is Very Very Important), this isn't a remote procedure call. It is absolutely illegal to make procedure calls to Actors, ever. Instead, you send them messages.
>>>
>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
>>> In a more direct question, do agents instances need to be serializable?
>>>
>>>
>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>>> So we've hit a few problems with our original design, and we're discussing ideas for a possible alternative.
>>>
>>> When reading the documentation on akka actors and props (http://doc.akka.io/docs/akka/current/scala/actors.html#creating-actors-with-props <http://doc.akka.io/docs/akka/current/scala/actors.html#creating-actors-with-props>) one question came to mind regarding the following statement about the ActorRef type:
>>>
>>> "The ActorRef is also serializable and network-aware. This means that you can serialize it, send it over the wire and use it on a remote host and it will still be representing the same Actor on the original node, across the network."
>>>
>>> Do you guys happen to know if that means that the ActorRef is serializable and wherever it is used, will ALWAYS point to the original Actor, running on its original JVM, or, is it possible that it would be used to create another instance of the Actor, in another completely separate JVM?
>>>
>>> Cheers!
>>> Lucas
>>>
>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>>> Good catch. Seems that not much needs to be changed... I think simply adding the Spring extension to the ActorSystem config should do the trick.
>>>
>>> While that GitHub example I mentioned does use Spring to set the ActorSystem dependencies, I don't see that as being very useful for us right now, since we'd only use Spring for Actor-specific dependencies.
>>>
>>> If using Spring for the ActorSystem is interesting to the project as a whole, we could consider making some changes to make that work...
>>>
>>> I'll keep working on this as is for now. Let me know what you guys think about the ActorSystem idea.
>>>
>>> Cheers,
>>> Lucas
>>>
>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <barbaramaltagomes@gmail.com <ma...@gmail.com>> wrote:
>>> I might be wrong, but in order to use Akka with Spring, dont we need to also change the way the ActorSystem is being instantiated on Fey?
>>>
>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>>> So after a while pondering and going back and forth between a few possible implementations, I think we're on to something interesting.
>>>
>>> Let me try and give you guys an outline of the design we came up with:
>>> Create an Akka extension that will load the Spring context, as shown here -> https://github.com/typesafehub/activator-akka-java-spring <https://github.com/typesafehub/activator-akka-java-spring>
>>> Implement an ActorProducer that will then instatiate the actors, as shown here -> http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>> Modify "Orchestration.scala" to add an alternative "CreateEnsemble" method which will use the Spring extension when specified
>>> Modify "FeyCore.scala" by adding two possible fields to be interpreted from the orchestration JSON. One to specify that the performers within that orchestration will be using Spring (so that we can call the alternate method mentioned above); and another one specifying the path for the Spring context file
>>> Modify the JSON validator to reflect these changes.
>>>
>>> This should keep the fey core generic, as we mentioned before, not making using Spring mandatory.
>>>
>>> Let me know what you guys think!
>>>
>>> Cheers,
>>> Lucas
>>>
>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <barbaramaltagomes@gmail.com <ma...@gmail.com>> wrote:
>>> That sounds good.
>>>
>>> Thank you Lucas.
>>>
>>> Looking forward for the out coming results.
>>>
>>> This new feature will be a good fit for The Fey Engine.
>>>
>>> Regards,
>>>
>>> Barbara Gomes
>>> +1 (650) 713-6092 <tel:(650)%20713-6092>
>>>
>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>> I think using the Akka dependency injection system is a good starting point. It should be sufficient for our needs and shouldn't take too long to get it working.
>>>>
>>>> I'll try to get something up and running and report back. Once we get it going maybe we can discuss a feature proposal and eventually even bringing full spring integration to the fey core.
>>>>
>>>> Cheers!
>>>> Lucas
>>>>
>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <barbaramaltagomes@gmail.com <ma...@gmail.com>> wrote:
>>>> Hi there,
>>>>
>>>> I'm not very familiar with the Spring framework.
>>>> I spent sometime reading about it and how it would integrate into Fey (Akka).
>>>>
>>>> Correct if I'm misunderstood:
>>>>
>>>> @Rafael is suggesting the complete integration of the Spring framework into Fey. Which would be a bit more complex, since Fey would have to instantiate the Spring context and the Actor System would also have to be instantiated using the Spring context. Which would imply that all the necessary configuration for the Spring framework would have to be defined upon Fey start-up (fey.conf file maybe).
>>>>
>>>> @Lucas is suggesting that we use the built-in dependency injection that Akka offers. This approach sounds simpler than the Spring integration, and would also keep the "Generic" idea of Fey, where the developer should be able to use any framework he wants to.
>>>>
>>>> I personally think that it would be awesome if we could work on both approaches. Here are my reasons:
>>>> Spring is a fairly complex framework, and having it integrated on Fey core would be a huge plus and would also offer a more sophisticated dependency injection framework.
>>>> Using the built-in Akka dependency injection would be cool as well, since it seems way simpler to use and understand, and developers that are not familiar with the Spring framework (like me) would not have a hard time integrating it into the performers world.
>>>> For both approaches, we would have to do some research and present an Integration idea into Fey.
>>>>
>>>> Perhaps we could start working on the proposal for @Lucas suggestions first? What do you guys think?
>>>>
>>>> Just as a heads-up: Unfortunately, Fey still have some class load issues when the performer's dependencies are fairly complex. As an example, we wrote an Apache Ignite performer and we had to go to some hoops to get the Spring dependencies loaded in runtime, in fact, the final fix was to manually add the dependency to the Fey Application when starting Fey, on the run command (java -jar ...). Although it was a simple fix, it would be nice to not have to do it anymore.
>>>>
>>>> Looking forward to hear your thoughts.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <lucascristofolini@gmail.com <ma...@gmail.com>> wrote:
>>>> I've been reading up on how Akka would handle dependency injection (http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>), and it seems that, as far as Akka is concerned, upon creating an Actor, we could pass a DependencyInjector and an ApplicationContext within the actor's Props.
>>>>
>>>> So now I'm imagining that bringing this functionality to Fey would be a simple matter of adding a few extra items (the DependencyInjector class and the ApplicationContext) to the json that defines an orchestration, and once the json is processed, verifying if those items are present, and adding those to the Props before calling akka to instance the actor.
>>>>
>>>> Still, I'm curious to see what you guys think about bringing this feature to the fey-engine.
>>>>
>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <rafaelweingartner@gmail.com <ma...@gmail.com>> wrote:
>>>> We started developing our first agents (performers) using Fey, and we found our first “problem”. There is no integration of Fey and Spring. Or at least, we did not understand how to integrate Fey with Spring.
>>>>
>>>> We want to instantiate our agents in Spring to enjoy all of its benefits (e.g. dependency injection, object management, easy transaction configuration and so forth). Therefore, instead of telling Fey the performer class to instantiate, we would have to tell Fey the source as the application context name and the bean name; so Fey can retrieve the agent (object) already instantiated by Spring.
>>>>
>>>> This would have consequences on the performer constructor; we would need to add another hook to configure an agent in Fey such as a post-constructor method that would be intended to do the same as the constructor today. I mean, we maintain everything we have so far, and we add only a default constructor with no parameters and the post-constructor method that would be hooked in Fey’s performer life-cycle.
>>>>
>>>> Then, we would have to possibilities, first the one we already have to instantiate an agent:
>>>> "source": {
>>>> "name": "agentJarWithDependencies.jar",
>>>> "classPath": "org.awesomeCompany.agentOne",
>>>> "parameters": {
>>>> }
>>>>
>>>>
>>>> And an alternative for agent objects managed by Spring:
>>>> "source": {
>>>> "name": " agentJarWithDependencies.jar",
>>>> "applicationContextName": "agentOneApplicationContext.xml",
>>>> "performerBeanName": "agentOneApplicationContext.xml"
>>>>
>>>>
>>>> This would require Fey to instantiate the Spring’s application context, and then look the bean up there. The idea is that application context file can be found in the classpath.
>>>>
>>>>
>>>>
>>>>
>>>> What do you guys think about this? We can work to create this integration after we discussed the changes that would be applied to Fey.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Barbara Gomes
>>>> Computer Engineer
>>>> San Jose, CA
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> Barbara Gomes
>>> Computer Engineer
>>> San Jose, CA
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>>
>
>
>
> --
> Rafael Weingärtner
>
>
>
> --
> Rafael Weingärtner
Re: Fey-core and Spring integration
Posted by Rafael Weingärtner <ra...@gmail.com>.
Tony, Barbara, can we get a feedback on this one?
On Tue, Jul 4, 2017 at 3:03 PM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:
> For contributors in Apache, as far as I know, there is no agreement that
> need to be signed. For, committers there is the ICLA.
>
> On Tue, Jul 4, 2017 at 3:01 PM, Tony Faustini <to...@litbit.com> wrote:
>
>> Awesome! There might. A contributors agreement I will check.
>> Tony
>>
>> Sent from my iPhone
>>
>> On Jul 3, 2017, at 8:02 AM, Lucas Berri Cristofolini <
>> lucascristofolini@gmail.com> wrote:
>>
>> OK, we've run some more tests and changed a couple things... Everything
>> should be good to go now.
>>
>> Is there some sort of "standard procedure" to contribute these changes to
>> the IOTA project? Is just opening a PR on girhub OK or is there something
>> else to it?
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
>> lucascristofolini@gmail.com> wrote:
>>
>>> OK, we figured it out. Managed to get it going by adding the proper
>>> merge strategies.
>>>
>>> And we've finally managed to get Spring dependency injection working!
>>> We'll run some more tests to make sure everything is up to standard and
>>> then we can discuss how we can contribute this functionality to the project.
>>>
>>> Cheers!
>>> Lucas
>>>
>>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
>>> rafaelweingartner@gmail.com> wrote:
>>>
>>>> Spring is packaged with AOP classes. Can you check who is bringing the
>>>> aopalliance-1.0.jar?
>>>>
>>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>>>> lucascristofolini@gmail.com> wrote:
>>>>
>>>>> OK, so I've gotten to the point of testing our new design and ran into
>>>>> a problem.
>>>>>
>>>>> As soon as I add the spring framework as a build dependency on sbt, I
>>>>> seem to run into some merge conflicts with other dependencies (?).
>>>>>
>>>>> I'm not familiar with the sbt build system at all so I figured I
>>>>> should ask you guys for ideas, I'll attach the build log (terminal output)
>>>>> and the files changed to this email, so you guys can see what I'm doing
>>>>> (the changes really come down to adding a line for the spring dependency
>>>>> and adding that variable to the fey project's compile-time dependencies).
>>>>>
>>>>> In the meantime, I'll read up on how sbt handles this sort of thing
>>>>> and see if I can figure it out.
>>>>>
>>>>> Cheers!
>>>>> Lucas
>>>>>
>>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>
>>>>>> We are not. Our doubt was regarding agents/performers/actors
>>>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>>>> (right?).
>>>>>>
>>>>>>
>>>>>> We want dependency injection, and some of this "service" objects will
>>>>>> have connections to other systems (e.g. database systems), so we wanted to
>>>>>> check if AKKA required agents to be serializable; from our reading of AKKA
>>>>>> documentation, this was not clear. Then we asked you guys here (it seems
>>>>>> you are quite used to work with AKKA) and today I checked with AKKA
>>>>>> community.
>>>>>>
>>>>>>
>>>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>>>> right? (The topic of some other email exchange we had some time
>>>>>> ago). We are working without AKKA (Fey) clustering for now; after fixing
>>>>>> the bits for dependency injection we will take a look at this.
>>>>>>
>>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <barbaramaltagomes@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Rafael,
>>>>>>>
>>>>>>> Glad you guys figured that out.
>>>>>>> As I said in one of the previous thread, Fey does not support remote
>>>>>>> actors, so I'm not sure how are you guys able to instanciate an actor in a
>>>>>>> different JVM using fey.
>>>>>>>
>>>>>>> Do you mind explain it ?
>>>>>>>
>>>>>>> Barbara Gomes
>>>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>>>
>>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>
>>>>>>> We found the answer for those questions.
>>>>>>> In summary:
>>>>>>> An ActorRef can be thought of as an address. Yes, we can send it
>>>>>>> over to other JVMs (so long as they are in the same cluster), and can be
>>>>>>> used to send messages to that Actor.
>>>>>>> However (and this is Very Very Important), this isn't a remote
>>>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>>>> ever. Instead, you send them messages.
>>>>>>>
>>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>
>>>>>>>> In a more direct question, do agents instances need to be
>>>>>>>> serializable?
>>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>>>> discussing ideas for a possible alternative.
>>>>>>>>>
>>>>>>>>> When reading the documentation on akka actors and props (
>>>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>>>> following statement about the ActorRef type:
>>>>>>>>>
>>>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>>>> across the network."
>>>>>>>>>
>>>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>>>> separate JVM?
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>> Lucas
>>>>>>>>>
>>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>>>> trick.
>>>>>>>>>>
>>>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>>
>>>>>>>>>> If using Spring for the ActorSystem is interesting to the project
>>>>>>>>>> as a whole, we could consider making some changes to make that work...
>>>>>>>>>>
>>>>>>>>>> I'll keep working on this as is for now. Let me know what you
>>>>>>>>>> guys think about the ActorSystem idea.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Lucas
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So after a while pondering and going back and forth between a
>>>>>>>>>>>> few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me try and give you guys an outline of the design we came
>>>>>>>>>>>> up with:
>>>>>>>>>>>>
>>>>>>>>>>>> - Create an Akka extension that will load the Spring
>>>>>>>>>>>> context, as shown here -> https://github.com/typesafehub
>>>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to
>>>>>>>>>>>> be interpreted from the orchestration JSON. One to specify that the
>>>>>>>>>>>> performers within that orchestration will be using Spring (so that we can
>>>>>>>>>>>> call the alternate method mentioned above); and another one specifying the
>>>>>>>>>>>> path for the Spring context file
>>>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Lucas
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll try to get something up and running and report back. Once
>>>>>>>>>>>>> we get it going maybe we can discuss a feature proposal and eventually even
>>>>>>>>>>>>> bringing full spring integration to the fey core.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>> Lucas
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the
>>>>>>>>>>>>>> Spring framework into Fey. Which would be a bit more complex, since Fey
>>>>>>>>>>>>>> would have to instantiate the Spring context and the Actor System would
>>>>>>>>>>>>>> also have to be instantiated using the Spring context. Which would imply
>>>>>>>>>>>>>> that all the necessary configuration for the Spring framework would have to
>>>>>>>>>>>>>> be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I personally think that it would be awesome if we could work
>>>>>>>>>>>>>> on both approaches. Here are my reasons:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some
>>>>>>>>>>>>>> class load issues when the performer's dependencies are fairly complex. As
>>>>>>>>>>>>>> an example, we wrote an Apache Ignite performer and we had to go to some
>>>>>>>>>>>>>> hoops to get the Spring dependencies loaded in runtime, in fact, the final
>>>>>>>>>>>>>> fix was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it
>>>>>>>>>>>>>>> seems that, as far as Akka is concerned, upon creating an Actor, we could
>>>>>>>>>>>>>>> pass a DependencyInjector and an ApplicationContext within the actor's
>>>>>>>>>>>>>>> Props.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey
>>>>>>>>>>>>>>> would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing
>>>>>>>>>>>>>>> this feature to the fey-engine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of
>>>>>>>>>>>>>>>> its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This would have consequences on the performer constructor;
>>>>>>>>>>>>>>>> we would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you guys think about this? We can work to create
>>>>>>>>>>>>>>>> this integration after we discussed the changes that would be applied to
>>>>>>>>>>>>>>>> Fey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>> Computer Engineer
>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rafael Weingärtner
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>>
>>>
>>>
>>
>
>
> --
> Rafael Weingärtner
>
--
Rafael Weingärtner
Re: Fey-core and Spring integration
Posted by Rafael Weingärtner <ra...@gmail.com>.
For contributors in Apache, as far as I know, there is no agreement that
need to be signed. For, committers there is the ICLA.
On Tue, Jul 4, 2017 at 3:01 PM, Tony Faustini <to...@litbit.com> wrote:
> Awesome! There might. A contributors agreement I will check.
> Tony
>
> Sent from my iPhone
>
> On Jul 3, 2017, at 8:02 AM, Lucas Berri Cristofolini <
> lucascristofolini@gmail.com> wrote:
>
> OK, we've run some more tests and changed a couple things... Everything
> should be good to go now.
>
> Is there some sort of "standard procedure" to contribute these changes to
> the IOTA project? Is just opening a PR on girhub OK or is there something
> else to it?
>
> Cheers!
> Lucas
>
> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
> lucascristofolini@gmail.com> wrote:
>
>> OK, we figured it out. Managed to get it going by adding the proper merge
>> strategies.
>>
>> And we've finally managed to get Spring dependency injection working!
>> We'll run some more tests to make sure everything is up to standard and
>> then we can discuss how we can contribute this functionality to the project.
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>
>>> Spring is packaged with AOP classes. Can you check who is bringing the
>>> aopalliance-1.0.jar?
>>>
>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>>> lucascristofolini@gmail.com> wrote:
>>>
>>>> OK, so I've gotten to the point of testing our new design and ran into
>>>> a problem.
>>>>
>>>> As soon as I add the spring framework as a build dependency on sbt, I
>>>> seem to run into some merge conflicts with other dependencies (?).
>>>>
>>>> I'm not familiar with the sbt build system at all so I figured I should
>>>> ask you guys for ideas, I'll attach the build log (terminal output) and the
>>>> files changed to this email, so you guys can see what I'm doing (the
>>>> changes really come down to adding a line for the spring dependency and
>>>> adding that variable to the fey project's compile-time dependencies).
>>>>
>>>> In the meantime, I'll read up on how sbt handles this sort of thing and
>>>> see if I can figure it out.
>>>>
>>>> Cheers!
>>>> Lucas
>>>>
>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>
>>>>> We are not. Our doubt was regarding agents/performers/actors
>>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>>> (right?).
>>>>>
>>>>>
>>>>> We want dependency injection, and some of this "service" objects will
>>>>> have connections to other systems (e.g. database systems), so we wanted to
>>>>> check if AKKA required agents to be serializable; from our reading of AKKA
>>>>> documentation, this was not clear. Then we asked you guys here (it seems
>>>>> you are quite used to work with AKKA) and today I checked with AKKA
>>>>> community.
>>>>>
>>>>>
>>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>>> right? (The topic of some other email exchange we had some time ago).
>>>>> We are working without AKKA (Fey) clustering for now; after fixing the bits
>>>>> for dependency injection we will take a look at this.
>>>>>
>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <ba...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Rafael,
>>>>>>
>>>>>> Glad you guys figured that out.
>>>>>> As I said in one of the previous thread, Fey does not support remote
>>>>>> actors, so I'm not sure how are you guys able to instanciate an actor in a
>>>>>> different JVM using fey.
>>>>>>
>>>>>> Do you mind explain it ?
>>>>>>
>>>>>> Barbara Gomes
>>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>>
>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>
>>>>>> We found the answer for those questions.
>>>>>> In summary:
>>>>>> An ActorRef can be thought of as an address. Yes, we can send it over
>>>>>> to other JVMs (so long as they are in the same cluster), and can be used to
>>>>>> send messages to that Actor.
>>>>>> However (and this is Very Very Important), this isn't a remote
>>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>>> ever. Instead, you send them messages.
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>
>>>>>>> In a more direct question, do agents instances need to be
>>>>>>> serializable?
>>>>>>>
>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>
>>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>>> discussing ideas for a possible alternative.
>>>>>>>>
>>>>>>>> When reading the documentation on akka actors and props (
>>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>>> following statement about the ActorRef type:
>>>>>>>>
>>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>>> across the network."
>>>>>>>>
>>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>>> separate JVM?
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>> Lucas
>>>>>>>>
>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>>> trick.
>>>>>>>>>
>>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>
>>>>>>>>> If using Spring for the ActorSystem is interesting to the project
>>>>>>>>> as a whole, we could consider making some changes to make that work...
>>>>>>>>>
>>>>>>>>> I'll keep working on this as is for now. Let me know what you guys
>>>>>>>>> think about the ActorSystem idea.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Lucas
>>>>>>>>>
>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> So after a while pondering and going back and forth between a
>>>>>>>>>>> few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>
>>>>>>>>>>> Let me try and give you guys an outline of the design we came up
>>>>>>>>>>> with:
>>>>>>>>>>>
>>>>>>>>>>> - Create an Akka extension that will load the Spring
>>>>>>>>>>> context, as shown here -> https://github.com/typesafehub
>>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to be
>>>>>>>>>>> interpreted from the orchestration JSON. One to specify that the performers
>>>>>>>>>>> within that orchestration will be using Spring (so that we can call the
>>>>>>>>>>> alternate method mentioned above); and another one specifying the path for
>>>>>>>>>>> the Spring context file
>>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>>
>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lucas
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>
>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try to get something up and running and report back. Once
>>>>>>>>>>>> we get it going maybe we can discuss a feature proposal and eventually even
>>>>>>>>>>>> bringing full spring integration to the fey core.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers!
>>>>>>>>>>>> Lucas
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>
>>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the
>>>>>>>>>>>>> Spring framework into Fey. Which would be a bit more complex, since Fey
>>>>>>>>>>>>> would have to instantiate the Spring context and the Actor System would
>>>>>>>>>>>>> also have to be instantiated using the Spring context. Which would imply
>>>>>>>>>>>>> that all the necessary configuration for the Spring framework would have to
>>>>>>>>>>>>> be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>
>>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I personally think that it would be awesome if we could work
>>>>>>>>>>>>> on both approaches. Here are my reasons:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some
>>>>>>>>>>>>> class load issues when the performer's dependencies are fairly complex. As
>>>>>>>>>>>>> an example, we wrote an Apache Ignite performer and we had to go to some
>>>>>>>>>>>>> hoops to get the Spring dependencies loaded in runtime, in fact, the final
>>>>>>>>>>>>> fix was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it
>>>>>>>>>>>>>> seems that, as far as Akka is concerned, upon creating an Actor, we could
>>>>>>>>>>>>>> pass a DependencyInjector and an ApplicationContext within the actor's
>>>>>>>>>>>>>> Props.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey
>>>>>>>>>>>>>> would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing
>>>>>>>>>>>>>> this feature to the fey-engine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of
>>>>>>>>>>>>>>> its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would have consequences on the performer constructor;
>>>>>>>>>>>>>>> we would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you guys think about this? We can work to create
>>>>>>>>>>>>>>> this integration after we discussed the changes that would be applied to
>>>>>>>>>>>>>>> Fey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Barbara Gomes
>>>>>>>>>> Computer Engineer
>>>>>>>>>> San Jose, CA
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rafael Weingärtner
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>>
>>
>>
>
--
Rafael Weingärtner
Re: Fey-core and Spring integration
Posted by Tony Faustini <to...@litbit.com>.
Awesome! There might. A contributors agreement I will check.
Tony
Sent from my iPhone
> On Jul 3, 2017, at 8:02 AM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>
> OK, we've run some more tests and changed a couple things... Everything should be good to go now.
>
> Is there some sort of "standard procedure" to contribute these changes to the IOTA project? Is just opening a PR on girhub OK or is there something else to it?
>
> Cheers!
> Lucas
>
>> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>> OK, we figured it out. Managed to get it going by adding the proper merge strategies.
>>
>> And we've finally managed to get Spring dependency injection working! We'll run some more tests to make sure everything is up to standard and then we can discuss how we can contribute this functionality to the project.
>>
>> Cheers!
>> Lucas
>>
>>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
>>> Spring is packaged with AOP classes. Can you check who is bringing the aopalliance-1.0.jar?
>>>
>>>
>>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>> OK, so I've gotten to the point of testing our new design and ran into a problem.
>>>>
>>>> As soon as I add the spring framework as a build dependency on sbt, I seem to run into some merge conflicts with other dependencies (?).
>>>>
>>>> I'm not familiar with the sbt build system at all so I figured I should ask you guys for ideas, I'll attach the build log (terminal output) and the files changed to this email, so you guys can see what I'm doing (the changes really come down to adding a line for the spring dependency and adding that variable to the fey project's compile-time dependencies).
>>>>
>>>> In the meantime, I'll read up on how sbt handles this sort of thing and see if I can figure it out.
>>>>
>>>> Cheers!
>>>> Lucas
>>>>
>>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
>>>>> We are not. Our doubt was regarding agents/performers/actors requirements, when we read the requirement for AKKA, which Fey uses (right?).
>>>>>
>>>>>
>>>>>
>>>>> We want dependency injection, and some of this "service" objects will have connections to other systems (e.g. database systems), so we wanted to check if AKKA required agents to be serializable; from our reading of AKKA documentation, this was not clear. Then we asked you guys here (it seems you are quite used to work with AKKA) and today I checked with AKKA community.
>>>>>
>>>>>
>>>>>
>>>>> I think by supporting remote actors you mean using AKKA clustering, right? (The topic of some other email exchange we had some time ago). We are working without AKKA (Fey) clustering for now; after fixing the bits for dependency injection we will take a look at this.
>>>>>
>>>>>
>>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <ba...@gmail.com> wrote:
>>>>>> Hi Rafael,
>>>>>>
>>>>>> Glad you guys figured that out.
>>>>>> As I said in one of the previous thread, Fey does not support remote actors, so I'm not sure how are you guys able to instanciate an actor in a different JVM using fey.
>>>>>>
>>>>>> Do you mind explain it ?
>>>>>>
>>>>>> Barbara Gomes
>>>>>> +1 (650) 713-6092
>>>>>>
>>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
>>>>>>>
>>>>>>> We found the answer for those questions.
>>>>>>> In summary:
>>>>>>> An ActorRef can be thought of as an address. Yes, we can send it over to other JVMs (so long as they are in the same cluster), and can be used to send messages to that Actor.
>>>>>>> However (and this is Very Very Important), this isn't a remote procedure call. It is absolutely illegal to make procedure calls to Actors, ever. Instead, you send them messages.
>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
>>>>>>>> In a more direct question, do agents instances need to be serializable?
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>>>>>>> So we've hit a few problems with our original design, and we're discussing ideas for a possible alternative.
>>>>>>>>>
>>>>>>>>> When reading the documentation on akka actors and props (http://doc.akka.io/docs/akka/current/scala/actors.html#creating-actors-with-props) one question came to mind regarding the following statement about the ActorRef type:
>>>>>>>>>
>>>>>>>>> "The ActorRef is also serializable and network-aware. This means that you can serialize it, send it over the wire and use it on a remote host and it will still be representing the same Actor on the original node, across the network."
>>>>>>>>>
>>>>>>>>> Do you guys happen to know if that means that the ActorRef is serializable and wherever it is used, will ALWAYS point to the original Actor, running on its original JVM, or, is it possible that it would be used to create another instance of the Actor, in another completely separate JVM?
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>> Lucas
>>>>>>>>>
>>>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>>>>>>>> Good catch. Seems that not much needs to be changed... I think simply adding the Spring extension to the ActorSystem config should do the trick.
>>>>>>>>>>
>>>>>>>>>> While that GitHub example I mentioned does use Spring to set the ActorSystem dependencies, I don't see that as being very useful for us right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>>
>>>>>>>>>> If using Spring for the ActorSystem is interesting to the project as a whole, we could consider making some changes to make that work...
>>>>>>>>>>
>>>>>>>>>> I'll keep working on this as is for now. Let me know what you guys think about the ActorSystem idea.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Lucas
>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <ba...@gmail.com> wrote:
>>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>>>>>>>>>> So after a while pondering and going back and forth between a few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me try and give you guys an outline of the design we came up with:
>>>>>>>>>>>> Create an Akka extension that will load the Spring context, as shown here -> https://github.com/typesafehub/activator-akka-java-spring
>>>>>>>>>>>> Implement an ActorProducer that will then instatiate the actors, as shown here -> http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection
>>>>>>>>>>>> Modify "Orchestration.scala" to add an alternative "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>>> Modify "FeyCore.scala" by adding two possible fields to be interpreted from the orchestration JSON. One to specify that the performers within that orchestration will be using Spring (so that we can call the alternate method mentioned above); and another one specifying the path for the Spring context file
>>>>>>>>>>>> Modify the JSON validator to reflect these changes.
>>>>>>>>>>>>
>>>>>>>>>>>> This should keep the fey core generic, as we mentioned before, not making using Spring mandatory.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Lucas
>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <ba...@gmail.com> wrote:
>>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>> +1 (650) 713-6092
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think using the Akka dependency injection system is a good starting point. It should be sufficient for our needs and shouldn't take too long to get it working.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll try to get something up and running and report back. Once we get it going maybe we can discuss a feature proposal and eventually even bringing full spring integration to the fey core.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>> Lucas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <ba...@gmail.com> wrote:
>>>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate into Fey (Akka).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Rafael is suggesting the complete integration of the Spring framework into Fey. Which would be a bit more complex, since Fey would have to instantiate the Spring context and the Actor System would also have to be instantiated using the Spring context. Which would imply that all the necessary configuration for the Spring framework would have to be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> @Lucas is suggesting that we use the built-in dependency injection that Akka offers. This approach sounds simpler than the Spring integration, and would also keep the "Generic" idea of Fey, where the developer should be able to use any framework he wants to.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I personally think that it would be awesome if we could work on both approaches. Here are my reasons:
>>>>>>>>>>>>>>> Spring is a fairly complex framework, and having it integrated on Fey core would be a huge plus and would also offer a more sophisticated dependency injection framework.
>>>>>>>>>>>>>>> Using the built-in Akka dependency injection would be cool as well, since it seems way simpler to use and understand, and developers that are not familiar with the Spring framework (like me) would not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>>> For both approaches, we would have to do some research and present an Integration idea into Fey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Perhaps we could start working on the proposal for @Lucas suggestions first? What do you guys think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just as a heads-up: Unfortunately, Fey still have some class load issues when the performer's dependencies are fairly complex. As an example, we wrote an Apache Ignite performer and we had to go to some hoops to get the Spring dependencies loaded in runtime, in fact, the final fix was to manually add the dependency to the Fey Application when starting Fey, on the run command (java -jar ...). Although it was a simple fix, it would be nice to not have to do it anymore.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <lu...@gmail.com> wrote:
>>>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency injection (http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection), and it seems that, as far as Akka is concerned, upon creating an Actor, we could pass a DependencyInjector and an ApplicationContext within the actor's Props.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey would be a simple matter of adding a few extra items (the DependencyInjector class and the ApplicationContext) to the json that defines an orchestration, and once the json is processed, verifying if those items are present, and adding those to the Props before calling akka to instance the actor.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing this feature to the fey-engine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <ra...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> We started developing our first agents (performers) using Fey, and we found our first “problem”. There is no integration of Fey and Spring. Or at least, we did not understand how to integrate Fey with Spring.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of its benefits (e.g. dependency injection, object management, easy transaction configuration and so forth). Therefore, instead of telling Fey the performer class to instantiate, we would have to tell Fey the source as the application context name and the bean name; so Fey can retrieve the agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This would have consequences on the performer constructor; we would need to add another hook to configure an agent in Fey such as a post-constructor method that would be intended to do the same as the constructor today. I mean, we maintain everything we have so far, and we add only a default constructor with no parameters and the post-constructor method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we already have to instantiate an agent:
>>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>> "name": "agentJarWithDependencies.jar",
>>>>>>>>>>>>>>>>> "classPath": "org.awesomeCompany.agentOne",
>>>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>> "name": " agentJarWithDependencies.jar",
>>>>>>>>>>>>>>>>> "applicationContextName": "agentOneApplicationContext.xml",
>>>>>>>>>>>>>>>>> "performerBeanName": "agentOneApplicationContext.xml"
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s application context, and then look the bean up there. The idea is that application context file can be found in the classpath.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What do you guys think about this? We can work to create this integration after we discussed the changes that would be applied to Fey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>> Computer Engineer
>>>>>>>>>>> San Jose, CA
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rafael Weingärtner
>>>>
>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>
>
Re: Fey-core and Spring integration
Posted by Rafael Weingärtner <ra...@gmail.com>.
That would be awesome.
Thanks Barbara.
On Mon, Jul 3, 2017 at 2:20 PM, Barbara Malta Gomes <
barbaramaltagomes@gmail.com> wrote:
> You guys need to be added to the iota JIRA project as contributors first.
>
> I don't have admin privilegies on JIRA.
>
> *@tony *Can you add Rafael and Lucas as contributors on JIRA?
>
> Regards,
>
> On Mon, Jul 3, 2017 at 11:14 AM, Barbara Malta Gomes <
> barbaramaltagomes@gmail.com> wrote:
>
>> Hi Lucas,
>>
>> Thank you for your contribution.
>>
>> You first need to create a JIRA on iota for your work and add all the
>> necessary documentations there.
>>
>> Once everything is good on JIRA, you can go ahead and open a PR on GitHub
>> using the JIRA number.
>>
>> Regards,
>>
>> On Mon, Jul 3, 2017 at 8:02 AM, Lucas Berri Cristofolini <
>> lucascristofolini@gmail.com> wrote:
>>
>>> OK, we've run some more tests and changed a couple things... Everything
>>> should be good to go now.
>>>
>>> Is there some sort of "standard procedure" to contribute these changes
>>> to the IOTA project? Is just opening a PR on girhub OK or is there
>>> something else to it?
>>>
>>> Cheers!
>>> Lucas
>>>
>>> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
>>> lucascristofolini@gmail.com> wrote:
>>>
>>>> OK, we figured it out. Managed to get it going by adding the proper
>>>> merge strategies.
>>>>
>>>> And we've finally managed to get Spring dependency injection working!
>>>> We'll run some more tests to make sure everything is up to standard and
>>>> then we can discuss how we can contribute this functionality to the project.
>>>>
>>>> Cheers!
>>>> Lucas
>>>>
>>>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>
>>>>> Spring is packaged with AOP classes. Can you check who is bringing the
>>>>> aopalliance-1.0.jar?
>>>>>
>>>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>>>>> lucascristofolini@gmail.com> wrote:
>>>>>
>>>>>> OK, so I've gotten to the point of testing our new design and ran
>>>>>> into a problem.
>>>>>>
>>>>>> As soon as I add the spring framework as a build dependency on sbt, I
>>>>>> seem to run into some merge conflicts with other dependencies (?).
>>>>>>
>>>>>> I'm not familiar with the sbt build system at all so I figured I
>>>>>> should ask you guys for ideas, I'll attach the build log (terminal output)
>>>>>> and the files changed to this email, so you guys can see what I'm doing
>>>>>> (the changes really come down to adding a line for the spring dependency
>>>>>> and adding that variable to the fey project's compile-time dependencies).
>>>>>>
>>>>>> In the meantime, I'll read up on how sbt handles this sort of thing
>>>>>> and see if I can figure it out.
>>>>>>
>>>>>> Cheers!
>>>>>> Lucas
>>>>>>
>>>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>
>>>>>>> We are not. Our doubt was regarding agents/performers/actors
>>>>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>>>>> (right?).
>>>>>>>
>>>>>>>
>>>>>>> We want dependency injection, and some of this "service" objects
>>>>>>> will have connections to other systems (e.g. database systems), so we
>>>>>>> wanted to check if AKKA required agents to be serializable; from our
>>>>>>> reading of AKKA documentation, this was not clear. Then we asked you guys
>>>>>>> here (it seems you are quite used to work with AKKA) and today I checked
>>>>>>> with AKKA community.
>>>>>>>
>>>>>>>
>>>>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>>>>> right? (The topic of some other email exchange we had some time
>>>>>>> ago). We are working without AKKA (Fey) clustering for now; after fixing
>>>>>>> the bits for dependency injection we will take a look at this.
>>>>>>>
>>>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <
>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Rafael,
>>>>>>>>
>>>>>>>> Glad you guys figured that out.
>>>>>>>> As I said in one of the previous thread, Fey does not support
>>>>>>>> remote actors, so I'm not sure how are you guys able to instanciate an
>>>>>>>> actor in a different JVM using fey.
>>>>>>>>
>>>>>>>> Do you mind explain it ?
>>>>>>>>
>>>>>>>> Barbara Gomes
>>>>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>>>>
>>>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>
>>>>>>>> We found the answer for those questions.
>>>>>>>> In summary:
>>>>>>>> An ActorRef can be thought of as an address. Yes, we can send it
>>>>>>>> over to other JVMs (so long as they are in the same cluster), and can be
>>>>>>>> used to send messages to that Actor.
>>>>>>>> However (and this is Very Very Important), this isn't a remote
>>>>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>>>>> ever. Instead, you send them messages.
>>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> In a more direct question, do agents instances need to be
>>>>>>>>> serializable?
>>>>>>>>>
>>>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>>>>> discussing ideas for a possible alternative.
>>>>>>>>>>
>>>>>>>>>> When reading the documentation on akka actors and props (
>>>>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>>>>> following statement about the ActorRef type:
>>>>>>>>>>
>>>>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>>>>> across the network."
>>>>>>>>>>
>>>>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>>>>> separate JVM?
>>>>>>>>>>
>>>>>>>>>> Cheers!
>>>>>>>>>> Lucas
>>>>>>>>>>
>>>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>>>>> trick.
>>>>>>>>>>>
>>>>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>>>
>>>>>>>>>>> If using Spring for the ActorSystem is interesting to the
>>>>>>>>>>> project as a whole, we could consider making some changes to make that
>>>>>>>>>>> work...
>>>>>>>>>>>
>>>>>>>>>>> I'll keep working on this as is for now. Let me know what you
>>>>>>>>>>> guys think about the ActorSystem idea.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lucas
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> So after a while pondering and going back and forth between a
>>>>>>>>>>>>> few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me try and give you guys an outline of the design we came
>>>>>>>>>>>>> up with:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - Create an Akka extension that will load the Spring
>>>>>>>>>>>>> context, as shown here -> https://github.com/typesafehub
>>>>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to
>>>>>>>>>>>>> be interpreted from the orchestration JSON. One to specify that the
>>>>>>>>>>>>> performers within that orchestration will be using Spring (so that we can
>>>>>>>>>>>>> call the alternate method mentioned above); and another one specifying the
>>>>>>>>>>>>> path for the Spring context file
>>>>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Lucas
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll try to get something up and running and report back.
>>>>>>>>>>>>>> Once we get it going maybe we can discuss a feature proposal and eventually
>>>>>>>>>>>>>> even bringing full spring integration to the fey core.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>>> Lucas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the
>>>>>>>>>>>>>>> Spring framework into Fey. Which would be a bit more complex, since Fey
>>>>>>>>>>>>>>> would have to instantiate the Spring context and the Actor System would
>>>>>>>>>>>>>>> also have to be instantiated using the Spring context. Which would imply
>>>>>>>>>>>>>>> that all the necessary configuration for the Spring framework would have to
>>>>>>>>>>>>>>> be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I personally think that it would be awesome if we could work
>>>>>>>>>>>>>>> on both approaches. Here are my reasons:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some
>>>>>>>>>>>>>>> class load issues when the performer's dependencies are fairly complex. As
>>>>>>>>>>>>>>> an example, we wrote an Apache Ignite performer and we had to go to some
>>>>>>>>>>>>>>> hoops to get the Spring dependencies loaded in runtime, in fact, the final
>>>>>>>>>>>>>>> fix was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it
>>>>>>>>>>>>>>>> seems that, as far as Akka is concerned, upon creating an Actor, we could
>>>>>>>>>>>>>>>> pass a DependencyInjector and an ApplicationContext within the actor's
>>>>>>>>>>>>>>>> Props.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to
>>>>>>>>>>>>>>>> Fey would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about
>>>>>>>>>>>>>>>> bringing this feature to the fey-engine.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all
>>>>>>>>>>>>>>>>> of its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This would have consequences on the performer constructor;
>>>>>>>>>>>>>>>>> we would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What do you guys think about this? We can work to create
>>>>>>>>>>>>>>>>> this integration after we discussed the changes that would be applied to
>>>>>>>>>>>>>>>>> Fey.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Rafael Weingärtner
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rafael Weingärtner
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rafael Weingärtner
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Barbara Gomes
>> Computer Engineer
>> San Jose, CA
>>
>
>
>
> --
> Barbara Gomes
> Computer Engineer
> San Jose, CA
>
--
Rafael Weingärtner
Re: Fey-core and Spring integration
Posted by Barbara Malta Gomes <ba...@gmail.com>.
You guys need to be added to the iota JIRA project as contributors first.
I don't have admin privilegies on JIRA.
*@tony *Can you add Rafael and Lucas as contributors on JIRA?
Regards,
On Mon, Jul 3, 2017 at 11:14 AM, Barbara Malta Gomes <
barbaramaltagomes@gmail.com> wrote:
> Hi Lucas,
>
> Thank you for your contribution.
>
> You first need to create a JIRA on iota for your work and add all the
> necessary documentations there.
>
> Once everything is good on JIRA, you can go ahead and open a PR on GitHub
> using the JIRA number.
>
> Regards,
>
> On Mon, Jul 3, 2017 at 8:02 AM, Lucas Berri Cristofolini <
> lucascristofolini@gmail.com> wrote:
>
>> OK, we've run some more tests and changed a couple things... Everything
>> should be good to go now.
>>
>> Is there some sort of "standard procedure" to contribute these changes to
>> the IOTA project? Is just opening a PR on girhub OK or is there something
>> else to it?
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
>> lucascristofolini@gmail.com> wrote:
>>
>>> OK, we figured it out. Managed to get it going by adding the proper
>>> merge strategies.
>>>
>>> And we've finally managed to get Spring dependency injection working!
>>> We'll run some more tests to make sure everything is up to standard and
>>> then we can discuss how we can contribute this functionality to the project.
>>>
>>> Cheers!
>>> Lucas
>>>
>>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
>>> rafaelweingartner@gmail.com> wrote:
>>>
>>>> Spring is packaged with AOP classes. Can you check who is bringing the
>>>> aopalliance-1.0.jar?
>>>>
>>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>>>> lucascristofolini@gmail.com> wrote:
>>>>
>>>>> OK, so I've gotten to the point of testing our new design and ran into
>>>>> a problem.
>>>>>
>>>>> As soon as I add the spring framework as a build dependency on sbt, I
>>>>> seem to run into some merge conflicts with other dependencies (?).
>>>>>
>>>>> I'm not familiar with the sbt build system at all so I figured I
>>>>> should ask you guys for ideas, I'll attach the build log (terminal output)
>>>>> and the files changed to this email, so you guys can see what I'm doing
>>>>> (the changes really come down to adding a line for the spring dependency
>>>>> and adding that variable to the fey project's compile-time dependencies).
>>>>>
>>>>> In the meantime, I'll read up on how sbt handles this sort of thing
>>>>> and see if I can figure it out.
>>>>>
>>>>> Cheers!
>>>>> Lucas
>>>>>
>>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>
>>>>>> We are not. Our doubt was regarding agents/performers/actors
>>>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>>>> (right?).
>>>>>>
>>>>>>
>>>>>> We want dependency injection, and some of this "service" objects will
>>>>>> have connections to other systems (e.g. database systems), so we wanted to
>>>>>> check if AKKA required agents to be serializable; from our reading of AKKA
>>>>>> documentation, this was not clear. Then we asked you guys here (it seems
>>>>>> you are quite used to work with AKKA) and today I checked with AKKA
>>>>>> community.
>>>>>>
>>>>>>
>>>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>>>> right? (The topic of some other email exchange we had some time
>>>>>> ago). We are working without AKKA (Fey) clustering for now; after fixing
>>>>>> the bits for dependency injection we will take a look at this.
>>>>>>
>>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <barbaramaltagomes@gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Hi Rafael,
>>>>>>>
>>>>>>> Glad you guys figured that out.
>>>>>>> As I said in one of the previous thread, Fey does not support remote
>>>>>>> actors, so I'm not sure how are you guys able to instanciate an actor in a
>>>>>>> different JVM using fey.
>>>>>>>
>>>>>>> Do you mind explain it ?
>>>>>>>
>>>>>>> Barbara Gomes
>>>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>>>
>>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>
>>>>>>> We found the answer for those questions.
>>>>>>> In summary:
>>>>>>> An ActorRef can be thought of as an address. Yes, we can send it
>>>>>>> over to other JVMs (so long as they are in the same cluster), and can be
>>>>>>> used to send messages to that Actor.
>>>>>>> However (and this is Very Very Important), this isn't a remote
>>>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>>>> ever. Instead, you send them messages.
>>>>>>>
>>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>
>>>>>>>> In a more direct question, do agents instances need to be
>>>>>>>> serializable?
>>>>>>>>
>>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>>>> discussing ideas for a possible alternative.
>>>>>>>>>
>>>>>>>>> When reading the documentation on akka actors and props (
>>>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>>>> following statement about the ActorRef type:
>>>>>>>>>
>>>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>>>> across the network."
>>>>>>>>>
>>>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>>>> separate JVM?
>>>>>>>>>
>>>>>>>>> Cheers!
>>>>>>>>> Lucas
>>>>>>>>>
>>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>>>> trick.
>>>>>>>>>>
>>>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>>
>>>>>>>>>> If using Spring for the ActorSystem is interesting to the project
>>>>>>>>>> as a whole, we could consider making some changes to make that work...
>>>>>>>>>>
>>>>>>>>>> I'll keep working on this as is for now. Let me know what you
>>>>>>>>>> guys think about the ActorSystem idea.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Lucas
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So after a while pondering and going back and forth between a
>>>>>>>>>>>> few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me try and give you guys an outline of the design we came
>>>>>>>>>>>> up with:
>>>>>>>>>>>>
>>>>>>>>>>>> - Create an Akka extension that will load the Spring
>>>>>>>>>>>> context, as shown here -> https://github.com/typesafehub
>>>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to
>>>>>>>>>>>> be interpreted from the orchestration JSON. One to specify that the
>>>>>>>>>>>> performers within that orchestration will be using Spring (so that we can
>>>>>>>>>>>> call the alternate method mentioned above); and another one specifying the
>>>>>>>>>>>> path for the Spring context file
>>>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>>>
>>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Lucas
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>>
>>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'll try to get something up and running and report back. Once
>>>>>>>>>>>>> we get it going maybe we can discuss a feature proposal and eventually even
>>>>>>>>>>>>> bringing full spring integration to the fey core.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers!
>>>>>>>>>>>>> Lucas
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the
>>>>>>>>>>>>>> Spring framework into Fey. Which would be a bit more complex, since Fey
>>>>>>>>>>>>>> would have to instantiate the Spring context and the Actor System would
>>>>>>>>>>>>>> also have to be instantiated using the Spring context. Which would imply
>>>>>>>>>>>>>> that all the necessary configuration for the Spring framework would have to
>>>>>>>>>>>>>> be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I personally think that it would be awesome if we could work
>>>>>>>>>>>>>> on both approaches. Here are my reasons:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some
>>>>>>>>>>>>>> class load issues when the performer's dependencies are fairly complex. As
>>>>>>>>>>>>>> an example, we wrote an Apache Ignite performer and we had to go to some
>>>>>>>>>>>>>> hoops to get the Spring dependencies loaded in runtime, in fact, the final
>>>>>>>>>>>>>> fix was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it
>>>>>>>>>>>>>>> seems that, as far as Akka is concerned, upon creating an Actor, we could
>>>>>>>>>>>>>>> pass a DependencyInjector and an ApplicationContext within the actor's
>>>>>>>>>>>>>>> Props.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey
>>>>>>>>>>>>>>> would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing
>>>>>>>>>>>>>>> this feature to the fey-engine.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of
>>>>>>>>>>>>>>>> its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This would have consequences on the performer constructor;
>>>>>>>>>>>>>>>> we would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What do you guys think about this? We can work to create
>>>>>>>>>>>>>>>> this integration after we discussed the changes that would be applied to
>>>>>>>>>>>>>>>> Fey.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>> Computer Engineer
>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Rafael Weingärtner
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Weingärtner
>>>>
>>>
>>>
>>
>
>
> --
> Barbara Gomes
> Computer Engineer
> San Jose, CA
>
--
Barbara Gomes
Computer Engineer
San Jose, CA
Re: Fey-core and Spring integration
Posted by Barbara Malta Gomes <ba...@gmail.com>.
Hi Lucas,
Thank you for your contribution.
You first need to create a JIRA on iota for your work and add all the
necessary documentations there.
Once everything is good on JIRA, you can go ahead and open a PR on GitHub
using the JIRA number.
Regards,
On Mon, Jul 3, 2017 at 8:02 AM, Lucas Berri Cristofolini <
lucascristofolini@gmail.com> wrote:
> OK, we've run some more tests and changed a couple things... Everything
> should be good to go now.
>
> Is there some sort of "standard procedure" to contribute these changes to
> the IOTA project? Is just opening a PR on girhub OK or is there something
> else to it?
>
> Cheers!
> Lucas
>
> On Sat, Jun 24, 2017 at 9:55 PM, Lucas Berri Cristofolini <
> lucascristofolini@gmail.com> wrote:
>
>> OK, we figured it out. Managed to get it going by adding the proper merge
>> strategies.
>>
>> And we've finally managed to get Spring dependency injection working!
>> We'll run some more tests to make sure everything is up to standard and
>> then we can discuss how we can contribute this functionality to the project.
>>
>> Cheers!
>> Lucas
>>
>> On Sat, Jun 24, 2017 at 4:11 PM, Rafael Weingärtner <
>> rafaelweingartner@gmail.com> wrote:
>>
>>> Spring is packaged with AOP classes. Can you check who is bringing the
>>> aopalliance-1.0.jar?
>>>
>>> On Sat, Jun 24, 2017 at 3:02 PM, Lucas Berri Cristofolini <
>>> lucascristofolini@gmail.com> wrote:
>>>
>>>> OK, so I've gotten to the point of testing our new design and ran into
>>>> a problem.
>>>>
>>>> As soon as I add the spring framework as a build dependency on sbt, I
>>>> seem to run into some merge conflicts with other dependencies (?).
>>>>
>>>> I'm not familiar with the sbt build system at all so I figured I should
>>>> ask you guys for ideas, I'll attach the build log (terminal output) and the
>>>> files changed to this email, so you guys can see what I'm doing (the
>>>> changes really come down to adding a line for the spring dependency and
>>>> adding that variable to the fey project's compile-time dependencies).
>>>>
>>>> In the meantime, I'll read up on how sbt handles this sort of thing and
>>>> see if I can figure it out.
>>>>
>>>> Cheers!
>>>> Lucas
>>>>
>>>> On Fri, Jun 23, 2017 at 5:11 PM, Rafael Weingärtner <
>>>> rafaelweingartner@gmail.com> wrote:
>>>>
>>>>> We are not. Our doubt was regarding agents/performers/actors
>>>>> requirements, when we read the requirement for AKKA, which Fey uses
>>>>> (right?).
>>>>>
>>>>>
>>>>> We want dependency injection, and some of this "service" objects will
>>>>> have connections to other systems (e.g. database systems), so we wanted to
>>>>> check if AKKA required agents to be serializable; from our reading of AKKA
>>>>> documentation, this was not clear. Then we asked you guys here (it seems
>>>>> you are quite used to work with AKKA) and today I checked with AKKA
>>>>> community.
>>>>>
>>>>>
>>>>> I think by supporting remote actors you mean using AKKA clustering,
>>>>> right? (The topic of some other email exchange we had some time ago).
>>>>> We are working without AKKA (Fey) clustering for now; after fixing the bits
>>>>> for dependency injection we will take a look at this.
>>>>>
>>>>> On Fri, Jun 23, 2017 at 3:57 PM, Barbara <ba...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Rafael,
>>>>>>
>>>>>> Glad you guys figured that out.
>>>>>> As I said in one of the previous thread, Fey does not support remote
>>>>>> actors, so I'm not sure how are you guys able to instanciate an actor in a
>>>>>> different JVM using fey.
>>>>>>
>>>>>> Do you mind explain it ?
>>>>>>
>>>>>> Barbara Gomes
>>>>>> +1 (650) 713-6092 <+1%20650-713-6092>
>>>>>>
>>>>>> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>
>>>>>> We found the answer for those questions.
>>>>>> In summary:
>>>>>> An ActorRef can be thought of as an address. Yes, we can send it over
>>>>>> to other JVMs (so long as they are in the same cluster), and can be used to
>>>>>> send messages to that Actor.
>>>>>> However (and this is Very Very Important), this isn't a remote
>>>>>> procedure call. It is absolutely illegal to make procedure calls to Actors,
>>>>>> ever. Instead, you send them messages.
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 7:57 PM, Rafael Weingärtner <
>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>
>>>>>>> In a more direct question, do agents instances need to be
>>>>>>> serializable?
>>>>>>>
>>>>>>> On Thu, Jun 22, 2017 at 7:16 PM, Lucas Berri Cristofolini <
>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>
>>>>>>>> So we've hit a few problems with our original design, and we're
>>>>>>>> discussing ideas for a possible alternative.
>>>>>>>>
>>>>>>>> When reading the documentation on akka actors and props (
>>>>>>>> http://doc.akka.io/docs/akka/current/scala/actors.html#crea
>>>>>>>> ting-actors-with-props) one question came to mind regarding the
>>>>>>>> following statement about the ActorRef type:
>>>>>>>>
>>>>>>>> "The ActorRef is also serializable and network-aware. This means
>>>>>>>> that you can serialize it, send it over the wire and use it on a remote
>>>>>>>> host and it will still be representing the same Actor on the original node,
>>>>>>>> across the network."
>>>>>>>>
>>>>>>>> Do you guys happen to know if that means that the ActorRef is
>>>>>>>> serializable and wherever it is used, will ALWAYS point to the original
>>>>>>>> Actor, running on its original JVM, or, is it possible that it would be
>>>>>>>> used to create another instance of the Actor, in another completely
>>>>>>>> separate JVM?
>>>>>>>>
>>>>>>>> Cheers!
>>>>>>>> Lucas
>>>>>>>>
>>>>>>>> On Sat, Jun 17, 2017 at 3:12 PM, Lucas Berri Cristofolini <
>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Good catch. Seems that not much needs to be changed... I think
>>>>>>>>> simply adding the Spring extension to the ActorSystem config should do the
>>>>>>>>> trick.
>>>>>>>>>
>>>>>>>>> While that GitHub example I mentioned does use Spring to set the
>>>>>>>>> ActorSystem dependencies, I don't see that as being very useful for us
>>>>>>>>> right now, since we'd only use Spring for Actor-specific dependencies.
>>>>>>>>>
>>>>>>>>> If using Spring for the ActorSystem is interesting to the project
>>>>>>>>> as a whole, we could consider making some changes to make that work...
>>>>>>>>>
>>>>>>>>> I'll keep working on this as is for now. Let me know what you guys
>>>>>>>>> think about the ActorSystem idea.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Lucas
>>>>>>>>>
>>>>>>>>> On Fri, Jun 16, 2017 at 7:45 PM, Barbara Malta Gomes <
>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I might be wrong, but in order to use Akka with Spring, dont we
>>>>>>>>>> need to also change the way the ActorSystem is being instantiated on Fey?
>>>>>>>>>>
>>>>>>>>>> On Fri, Jun 16, 2017 at 12:39 PM, Lucas Berri Cristofolini <
>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> So after a while pondering and going back and forth between a
>>>>>>>>>>> few possible implementations, I think we're on to something interesting.
>>>>>>>>>>>
>>>>>>>>>>> Let me try and give you guys an outline of the design we came up
>>>>>>>>>>> with:
>>>>>>>>>>>
>>>>>>>>>>> - Create an Akka extension that will load the Spring
>>>>>>>>>>> context, as shown here -> https://github.com/typesafehub
>>>>>>>>>>> /activator-akka-java-spring
>>>>>>>>>>> - Implement an ActorProducer that will then instatiate the
>>>>>>>>>>> actors, as shown here -> http://doc.akka.io/docs/akka/c
>>>>>>>>>>> urrent/scala/actors.html#dependency-injection
>>>>>>>>>>> <http://doc.akka.io/docs/akka/current/scala/actors.html#dependency-injection>
>>>>>>>>>>> - Modify "Orchestration.scala" to add an alternative
>>>>>>>>>>> "CreateEnsemble" method which will use the Spring extension when specified
>>>>>>>>>>> - Modify "FeyCore.scala" by adding two possible fields to be
>>>>>>>>>>> interpreted from the orchestration JSON. One to specify that the performers
>>>>>>>>>>> within that orchestration will be using Spring (so that we can call the
>>>>>>>>>>> alternate method mentioned above); and another one specifying the path for
>>>>>>>>>>> the Spring context file
>>>>>>>>>>> - Modify the JSON validator to reflect these changes.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This should keep the fey core generic, as we mentioned before,
>>>>>>>>>>> not making using Spring mandatory.
>>>>>>>>>>>
>>>>>>>>>>> Let me know what you guys think!
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Lucas
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Jun 6, 2017 at 1:03 PM, Barbara <
>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> That sounds good.
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you Lucas.
>>>>>>>>>>>>
>>>>>>>>>>>> Looking forward for the out coming results.
>>>>>>>>>>>>
>>>>>>>>>>>> This new feature will be a good fit for The Fey Engine.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>> +1 (650) 713-6092 <(650)%20713-6092>
>>>>>>>>>>>>
>>>>>>>>>>>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini <
>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I think using the Akka dependency injection system is a good
>>>>>>>>>>>> starting point. It should be sufficient for our needs and shouldn't take
>>>>>>>>>>>> too long to get it working.
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try to get something up and running and report back. Once
>>>>>>>>>>>> we get it going maybe we can discuss a feature proposal and eventually even
>>>>>>>>>>>> bringing full spring integration to the fey core.
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers!
>>>>>>>>>>>> Lucas
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jun 5, 2017 at 3:21 PM, Barbara Malta Gomes <
>>>>>>>>>>>> barbaramaltagomes@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi there,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm not very familiar with the Spring framework.
>>>>>>>>>>>>> I spent sometime reading about it and how it would integrate
>>>>>>>>>>>>> into Fey (Akka).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Correct if I'm misunderstood:
>>>>>>>>>>>>>
>>>>>>>>>>>>> *@Rafael *is suggesting the complete integration of the
>>>>>>>>>>>>> Spring framework into Fey. Which would be a bit more complex, since Fey
>>>>>>>>>>>>> would have to instantiate the Spring context and the Actor System would
>>>>>>>>>>>>> also have to be instantiated using the Spring context. Which would imply
>>>>>>>>>>>>> that all the necessary configuration for the Spring framework would have to
>>>>>>>>>>>>> be defined upon Fey start-up (fey.conf file maybe).
>>>>>>>>>>>>>
>>>>>>>>>>>>> *@Lucas *is suggesting that we use the built-in dependency
>>>>>>>>>>>>> injection that Akka offers. This approach sounds simpler than the Spring
>>>>>>>>>>>>> integration, and would also keep the "Generic" idea of Fey, where the
>>>>>>>>>>>>> developer should be able to use any framework he wants to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I personally think that it would be awesome if we could work
>>>>>>>>>>>>> on both approaches. Here are my reasons:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. Spring is a fairly complex framework, and having it
>>>>>>>>>>>>> integrated on Fey core would be a huge plus and would also offer a more
>>>>>>>>>>>>> sophisticated dependency injection framework.
>>>>>>>>>>>>> 2. Using the built-in Akka dependency injection would be
>>>>>>>>>>>>> cool as well, since it seems way simpler to use and understand, and
>>>>>>>>>>>>> developers that are not familiar with the Spring framework (like me) would
>>>>>>>>>>>>> not have a hard time integrating it into the performers world.
>>>>>>>>>>>>>
>>>>>>>>>>>>> For both approaches, we would have to do some research and
>>>>>>>>>>>>> present an Integration idea into Fey.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Perhaps we could start working on the proposal for *@Lucas *suggestions
>>>>>>>>>>>>> first? What do you guys think?
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Just as a heads-up:* Unfortunately, Fey still have some
>>>>>>>>>>>>> class load issues when the performer's dependencies are fairly complex. As
>>>>>>>>>>>>> an example, we wrote an Apache Ignite performer and we had to go to some
>>>>>>>>>>>>> hoops to get the Spring dependencies loaded in runtime, in fact, the final
>>>>>>>>>>>>> fix was to manually add the dependency to the Fey Application when starting
>>>>>>>>>>>>> Fey, on the run command (java -jar ...). Although it was a simple fix, it
>>>>>>>>>>>>> would be nice to not have to do it anymore.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looking forward to hear your thoughts.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 12:44 PM, Lucas Berri Cristofolini <
>>>>>>>>>>>>> lucascristofolini@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been reading up on how Akka would handle dependency
>>>>>>>>>>>>>> injection (http://doc.akka.io/docs/akka/
>>>>>>>>>>>>>> current/scala/actors.html#dependency-injection), and it
>>>>>>>>>>>>>> seems that, as far as Akka is concerned, upon creating an Actor, we could
>>>>>>>>>>>>>> pass a DependencyInjector and an ApplicationContext within the actor's
>>>>>>>>>>>>>> Props.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> So now I'm imagining that bringing this functionality to Fey
>>>>>>>>>>>>>> would be a simple matter of adding a few extra items (the
>>>>>>>>>>>>>> DependencyInjector class and the ApplicationContext) to the json that
>>>>>>>>>>>>>> defines an orchestration, and once the json is processed, verifying if
>>>>>>>>>>>>>> those items are present, and adding those to the Props before calling akka
>>>>>>>>>>>>>> to instance the actor.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Still, I'm curious to see what you guys think about bringing
>>>>>>>>>>>>>> this feature to the fey-engine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Sun, Jun 4, 2017 at 1:21 PM, Rafael Weingärtner <
>>>>>>>>>>>>>> rafaelweingartner@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We started developing our first agents (performers) using
>>>>>>>>>>>>>>> Fey, and we found our first “problem”. There is no integration of Fey and
>>>>>>>>>>>>>>> Spring. Or at least, we did not understand how to integrate Fey with
>>>>>>>>>>>>>>> Spring.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We want to instantiate our agents in Spring to enjoy all of
>>>>>>>>>>>>>>> its benefits (e.g. dependency injection, object management, easy
>>>>>>>>>>>>>>> transaction configuration and so forth). Therefore, instead of telling Fey
>>>>>>>>>>>>>>> the performer class to instantiate, we would have to tell Fey the source as
>>>>>>>>>>>>>>> the application context name and the bean name; so Fey can retrieve the
>>>>>>>>>>>>>>> agent (object) already instantiated by Spring.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would have consequences on the performer constructor;
>>>>>>>>>>>>>>> we would need to add another hook to configure an agent in Fey such as a
>>>>>>>>>>>>>>> post-constructor method that would be intended to do the same as the
>>>>>>>>>>>>>>> constructor today. I mean, we maintain everything we have so far, and we
>>>>>>>>>>>>>>> add only a default constructor with no parameters and the post-constructor
>>>>>>>>>>>>>>> method that would be hooked in Fey’s performer life-cycle.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Then, we would have to possibilities, first the one we
>>>>>>>>>>>>>>> already have to instantiate an agent:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "name": *"agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "classPath": *"org.awesomeCompany.agentOne"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "parameters": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And an alternative for agent objects managed by Spring:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "source": {
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "name": *" agentJarWithDependencies.jar"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "applicationContextName":
>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "performerBeanName":
>>>>>>>>>>>>>>> *"agentOneApplicationContext.xml"*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This would require Fey to instantiate the Spring’s
>>>>>>>>>>>>>>> application context, and then look the bean up there. The idea is that
>>>>>>>>>>>>>>> application context file can be found in the classpath.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What do you guys think about this? We can work to create
>>>>>>>>>>>>>>> this integration after we discussed the changes that would be applied to
>>>>>>>>>>>>>>> Fey.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Rafael Weingärtner
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Barbara Gomes
>>>>>>>>>>>>> Computer Engineer
>>>>>>>>>>>>> San Jose, CA
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Barbara Gomes
>>>>>>>>>> Computer Engineer
>>>>>>>>>> San Jose, CA
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Rafael Weingärtner
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rafael Weingärtner
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rafael Weingärtner
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Rafael Weingärtner
>>>
>>
>>
>
--
Barbara Gomes
Computer Engineer
San Jose, CA