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 > <[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 >>>>>> >>>>>>> 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#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 >>>>>>>>>> <[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/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 >>>>>>>>>>>>> >>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> <[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 >> >
