Yes, will get feedback to you today. It looks good but will see if Barbara has any comments. -Tony
> On Jul 10, 2017, at 7:49 AM, Rafael Weingärtner <[email protected]> > wrote: > > Tony, Barbara, can we get a feedback on this one? > > On Tue, Jul 4, 2017 at 3:03 PM, Rafael Weingärtner > <[email protected] <mailto:[email protected]>> wrote: > For contributors in Apache, as far as I know, there is no agreement that need > to be signed. For, committers there is the ICLA. > > On Tue, Jul 4, 2017 at 3:01 PM, Tony Faustini <[email protected] > <mailto:[email protected]>> wrote: > 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] >> <mailto:[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 <tel:+1%20650-713-6092> >> >> On Jun 23, 2017, at 12:44 PM, Rafael Weingärtner >> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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 >>> >>> <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] <mailto:[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] <mailto:[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] <mailto:[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 >>> <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 >>> <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] >>> <mailto:[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 <tel:(650)%20713-6092> >>> >>> On Jun 6, 2017, at 8:42 AM, Lucas Berri Cristofolini >>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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 >>>> >>>> <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] <mailto:[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 >> >> > > > > -- > Rafael Weingärtner > > > > -- > Rafael Weingärtner
