Re: [Hawkular-dev] Usage of other apis

Alerting is frankly the most complex part of the big picture which Jay or LucasP are be much more qualified to comment on. But for example inventory is at its core just a simple CRUD interface. The only thing fancy about it is that it stores a graph with custom edges (and can do versioning, blah, blah). Inventory in and of itself doesn't interact with anything else. It could use JPA for example but that would unnecessarily tie it to RDBMs which it currently doesn't need (and uses a graph db instead). Of course, that changes when you want to integrate other stuff with inventory and create the "big picture". But only then one should think about using EE (or camel for that matter) stuff to help with that. Metrics is another example that could do without ee just fine imho. Again, only the integration layer really needs some of the EE features because of the bus and even then I think your bus works out of ee, too? I think the question coul also be what we DO absolutely necessary need that is best provided by EE. On Friday, February 20, 2015 09:26:12 John Mazzitelli wrote: > I don't understand the rush to get rid of EE6 and dependencies like that > (especially when we are rushing to get something done quickly). We have at > our disposal a nice EE API and deployment model that let's us "get work > done". If we don't, for example, use MDBs, we have to handle all of what > they do by ourselves. Same with the other types of constructs. > > I can see this restriction for things like wildfly-monitor where we embed a > collector of metrics that could go in Wildfly-Core. But for the integration > components (like alerts), to take away EE would be detrimental to the > development effort because think of all the infrastructure we'd have to > "re-invent" before we could do the actual work of alerting. > > What are the use-cases where we don't want EE? What components are we > talking about that shouldn't use EE? Maybe I'm missing the big picture?? > > ----- Original Message ----- > >> On Friday, February 20, 2015 08:50:40 Heiko Braun wrote: >>>> On 19 Feb 2015, at 22:25, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: >>>>> Am 16.02.2015 um 16:07 schrieb Peter Palaga <ppalaga(a)redhat.com >>>>> <mailto:ppalaga@redhat.com>>: Second, the possibility to run in a >>>>> non-WF-like container is still somewhere in my consciousness. >>>>> Importing >>>>> wf BoM does not seem to be a step in that direction. >>>> Yes. We need to restrict ourselves to Java EE 6 and EJB 3.1, JMS 1.1 >>>> apis. >>>> We can use what EAP 6.4 offers - including JAX-RS 2 (this is not in >>>> there >>>> by default, but can be supplied by the application). >>>> This does not imply that we have to develop on EAP 6.4 though. >>> These two statements are contradicting each other: running in a “non >>> WF-like” container and assuming EE6 API’s on the target platform are two >>> worlds apart. >>> >>> First of all, if you build on EE6, you don’t “restrict” yourself. At >>> least >>> not in the way of “limiting” the API dependencies. But limiting the API >>> dependencies is a prerequisite to successfully integrate with other >>> platforms (or containers), which is what Peter has in mind, if I am >>> correct. >>> >>> Hawkular want’s to provide a set of re-usable components. Re-usable in a >>> sense, that other software project can integrate them easily. On the >>> other >>> hand there is the goal to build a Hawkular application, which itself is >>> a >>> consumer of the before mentioned components. >>> >>> I think the continuous mistake among the Hawkular contributors is that >>> you >>> don’t prioritise these two approaches. To do that, we need to >>> acknowledge >>> an intrinsic dependency of the Hawkular application onto the components. >>> Furthermore, any decision of API and service dependencies of those >>> components impacts the way in which they can be re-used. Dependencies >>> would >>> need to be carried over to any platform that want’s to leverage Hawkular >>> components. Which, in a way, limits it’s reusability. >> I guess the point the Heiko R. wanted to make is that by using >> jboss-javaee7 BoM or whatever BoM that defines versions of dependencies >> that are used in our >> *primary* target container, all we are doing is that we limit ourselves in >> a choice of versions of *potential* dependencies. By importing a BoM you >> don't actually depend on anything - you merely predefine the versions of >> artifacts you might want to depend on. All it does is it makes our lives >> easier when composing the integrated solution together. >> >> Otherwise everything you said resonates with me. The components themselves >> should be first of all embeddable as a library and therefore have only an >> absolutely necessary number of deps. >> >> REST API then becomes a facade on top of that. If we ever want to expose >> the components as EJBs, those EJBs would again be facades using the >> library. Etc. >> >> That's how I understood the outcome of our design discussions. While it >> may >> not look like it at the moment when we want to "rush" something (barely) >> consumable out to public, that outcome is definitely what we want to have >> in the "final" picture (or at least I sincerely hope so ;) ). >> >> Of course, embeddable libraries are only a small beginning. The picture >> gets more interesting when you start to think about integrations between >> the components (i.e actually fire an alert when some value flows into >> metrics). I actually am not sure we cracked that architectural nut such >> that we all are satisfied with it. A message bus of sorts lends itself as >> a solution to loosely coupled communication between the components but >> components themselves >> I think should not depend on the bus by default - if for nothing else than >> for >> the "baggage" of dependencies any of the message bus solutions carry with >> it.> >>> My suggestion would be to prioritise on the component re-use. Even if >>> that >>> results in inconveniences when building the Hawkular application: >>> >>> - Get rid of all EE6 dependencies. >> +1 >> >>> - Stop thinking in WAR and EAR deployments. >> +1 for components, -1 for their REST APIs and the integrated solution >> >>> - Support reusability by strictly limiting the API dependencies. >> +100 >> >>> - Come to an agreement about the priorities. >> I think the prios are clear - rush something "dirty" out now, clean up to >> our hearts' content right after the first version is out. >> >>> - Document and communicate the outcome of this discussion >> +1, we (and most of all I) need to get better at this >> >>> - Make sure all contributors understand and respect these constraints. >>> >>> Regards, Heiko B. >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > _______________________________________________ > hawkular-dev mailing list > hawkular-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hawkular-dev _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev