That would be awesome. Thanks Barbara. On Mon, Jul 3, 2017 at 2:20 PM, Barbara Malta Gomes < [email protected]> 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 < > [email protected]> 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 < >> [email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]> 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 < >>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>> [email protected]> 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
