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
