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
