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 >> > >
