7:23 p.m.
<tl;dr>
1. Nest/Kettle builds now use XSLT to tweak the standalone.sh, rather than us having to
maintain a full version of it in git.
2. Kettle is now in master branch - just "mvn install" in hawkular repo and
you'll get it.
3. Still getting a metrics error - see below for stack trace.
</tl;dr>
I refactored the way the nest distro and the kettle distro configures the wildfly server.
For those that are unaware, the "nest" is a wildfly build that includes the bus
infrastructure and the nest deployer - its a "container" that we can deploy
things into (like alerts, or inventory, or even agent components in the future - its meant
to be clusterable in the future with the bus being the communications conduit between
nests).
The "kettle" is that nest distribution with all of our hawkular integration
components deployed inside - inventory, alerts, metrics, embedded C*, the UI console,
etc.
It now uses XSLT (via the xml maven plugin) to tweak the out of box wildfly
standalone.xml. So we no longer have our own full standalone.xml in git - we take the one
that comes with wildfly and tweak it for our needs via XSLT.
Also, the kettle is now in the hawkular repo master branch. Everything should be in the
nexus snapshot repo, so if you just git clone hawkular and "mvn install",
you'll get the kettle distro in hawkular/kettle/target (its a zip file - just unzip it
and run standalone.sh like any other wildfly).
There is still a metrics error when you run the kettle - nothing that I did, I don't
think. Here's the exception - does someone know what this is?
20:18:16,273 WARN [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016006: Could
not load portable extension class org.hawkular.metrics.restServlet.EagerExtension:
java.lang.ClassNotFoundException: org.hawkular.metrics.restServlet.EagerExtension from
[Module
"deployment.hawkular-metrics-api-jaxrs-0.3.0-20150220.180642-17.war:main" from
Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213)
[jboss-modules.jar:1.3.3.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459)
[jboss-modules.jar:1.3.3.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408)
[jboss-modules.jar:1.3.3.Final]
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389)
[jboss-modules.jar:1.3.3.Final]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134)
[jboss-modules.jar:1.3.3.Final]
at
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:131)
[wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:117)
[wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at
org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:81)
[wildfly-weld-8.2.0.Final.jar:8.2.0.Final]
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_31]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
5:40 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/24/2015 02:23 AM, John Mazzitelli wrote:
I'm still confused about what is kettle and nest. By looking at the
code, kettle seems to incorporate nest, adding the other modules there
as well (alerts, inventory, ...). Thus, it sounds to me that, in order
to integrate hawkular-accounts, I'd need to work on kettle and I could
ignore nest.
If that assumption is true, then I'd need to move the data source
definition to kettle, instead of nest. Is this a problem?
Side question: is there a reason to remove the ExampleDS from
standalone.xml? As a Wildfly user, I'd expect it to be there (at least
for dev builds).
Could I also add a "dir" and "tar.gz" distribution to it? For
development, I find it easier to deal with the dir (no need to extract
anything).
- - Juca.
7:18 a.m.
The "nest" consists of the bus infrastructure and a "nest module
extension" whose main purposes today is to provide the bus infrastructure and to
deploy things it finds in its deployments directory
(modules/.../org/hawkular/nest/main/deployments). This WAS going to be the
"agent" until it was realized it could be used for both agent-side and
server-side components - so it was renamed "nest".
In the future, I have a feeling the nest functionality will expand - but for now,
that's what it is.
The kettle, you are right, is nothing more than an "integration build" for lack
of a better term. It takes the nest, and deploys all of the hawkular integration
components into the nest deployments directory. Running the kettle server means you get
all the hawkular components in one single Wildfly container.
So it depends on what you want to do. If you only want to test a single component (say,
alerts for example) you can take a nest build and just shove your alerts EAR into the nest
deployments location and run it and you would have a running alerts component that has
access to the bus infrastructure (which consists of an API and a broker itself).
If you want to test your stuff integrated with everything else, deploy it in the kettle
and watch to see how it plays nice (or not :) with the rest of hawkular.
We can add custom datasources that we need for all the integration components in the
kettle, yes. We have now an XSLT transformation that takes the out of box wildfly
standalone.xml and tweaks it for our use. This is not a problem - its how I think it
should be done. The kettle is the integration platform for everything, so I think we
should be adding things that the components need in there.
If you want to build your own server-side component that runs by itself, you would create
your own "kettle-like" mvn module, build on top of the nest like the kettle
does, but only deploy things that you would need and only tweak standalone.xml for your
component.
But for now, we are building a witch's brew of anything and everything into the one
kettle. So that's probably where you want to do it.
Side question: is there a reason to remove the ExampleDS from
standalone.xml? As a Wildfly user, I'd expect it to be there (at least
for dev builds).
I don't think we want something called like "ExampleDS" in our production
builds (which is likely what kettle will eventually become). We provide all hawkular
integration components with a datasource that they are free to use - it is called
HawkularDS. That's what hawkular devs will use.
We also provide java:/HawkularBusConnectionFactory to connect to the bus infrastructure
(say, for use to inject via @Resource). You can use hawkular-bus-common and
hawkular-bus-mdb jars for convienent API (the nest provides this for free - so long as
your WAR/EAR/Whatever has a dependency on the nest module).
You already can have a "dir" - if by that you mean the server exploded so you
don't have to unzip it. Just build the kettle with "-Pdev" and in target it
will already be exploded for you and no need to extract anything. If you want to add a
tar.gz assembly, feel free to do so with a pull request.
Hope that helps.
7:30 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/25/2015 02:18 PM, John Mazzitelli wrote:
Alright, that clarifies it! Thanks!
If you want to test your stuff integrated with everything else,
deploy it in the kettle and watch to see how it plays nice (or not
:) with the rest of hawkular.
That's probably my goal then.
I actually meant the HawkularDS. It seems weird that my component
needs HawkularDS and to have it defined on the "nest", even though
none of them are directly linked (ie: accounts is not aware of "nest"
and vice-versa). But I don't have strong objections about it.
Ok, so, we don't expect people to deploy their own stuff on our
production builds, right? In the end, it's not a big deal, but I was
left wondering if there's a reason to deviate from Wildfly here.
Yes, by "dir" I meant the "dir" assembly format, as defined on the
assembly descriptor, which is what the zip looks like before it gets
zipped. I can also live with the -Pdev, but I think the "dir" and
"tar.gz" could be defined directly on the assembly descriptor instead,
if there's no reason to keep it out of there. Again, it's not a big
deal, just convenience.
About the tar.gz: I'll send a PR for it.
- - Juca.
8:20 a.m.
I think that is right. I don't think people will be deploying their own stuff into our
"kettle". But even if they do (say, they wrote their own hawkular component,
whatever that might be), they will have to expect to "play nice" with our
integration server or "the nest" and that would mean if they want to use our
datasource, they would use our HawkularDS, just as if they want to hook into our bus they
would use our connection factory HawkularBusConnectionFactory. Its just part of the
infrastructure the Hawkular nest/kettle provides its hosted components.
I know we don't want to ship a product with something called "ExampleDS" -
that just seems "wrong" :) Its not a demo or "example" datasource - it
is the hawkular datasource! :)
Now, with all that said,
1) When all is said and done, I don't even know if Hawkular will even HAVE a JDBC
datasource in the end! We still haven't decided. But for now, we are giving people an
embedded H2 database to use. If we switch and go to, say, Postgres, it will still be
HawkularDS but just pointing to something different. Or it could completely go away. Who
knows? :)
2) I don't even know if this kettle itself is going to be a final product! This was
just for the MVP - a prototype to put all our stuff together and see it run. It may be the
kettle is just for development purposes. Again, who knows?
In other words, we still don't know how this is going to all end up :) Once more
formalized design plans are fleshed out, we'll figure things out.
But let's just roll with it and see how it ends up. As Heiko says, "Just write
something" :)
3683
days inactive
3684
days old
4 comments
2 participants
participants (2)
-
John Mazzitelli -
Juraci Paixão Kröhling