8:26 a.m.
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> 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