[Wildfly Maven Plugin] Skip start and shutdown
by Thomas Segismont
Hi,
Recently I've sent a pull request[1] so that the Wildfly Maven plugin
can skip start and shutdown.
In RHQ and Hawkular metrics projects, we use the Wildfly Maven plugin to
start a server and deploy an application for integration testing.
To sum up, we attach the following goals to different build phases:
* pre-integration-test -> start
* pre-integration-test -> deploy
* post-integration-test -> shutdown
The deploy goal has a skip parameter[2]. But the start and shutdown
goals haven't. So when we disable tests, we can skip the deploy phase
but Maven will still start and stop the Wildfly server.
I've tested a local build of the plugin with the changes. On the
Hawkular metrics rest-tests module, build time goes from 15 seconds down
to 5 seconds when start and stop goal are skipped.
Can somebody please have a look at the PR?
Thanks,
Thomas
[1] https://github.com/wildfly/wildfly-maven-plugin/issues/26
[2]
https://docs.jboss.org/wildfly/plugins/maven/latest/deploy-mojo.html#skip
8 years, 1 month
add a module dependency in a DeploymentUnitProcessor
by Carl Harris
I’ve written an extension in which I would like to make add a module dependency to a deployment (as if the dependency had been included in the Dependencies manifest header or jboss-deployment-structure.xml).
I’m assuming that this needs to happen in a DeploymentUnitProcessor. Looking at how the ManifestDeploymentProcessor in wildfly-core works, it seems I should be able to do something like this in a deployment processor that runs in the PARSE phase:
ModuleIdentifier moduleId = ModuleIdentifier.create(“org.example.api”);
ModuleLoader loader = Module.getBootModuleLoader();
ModuleDependency dependency = new ModuleDependency(loader, moduleId, false, false, false, false);
phaseContext.addToAttachmentList(Attachments.MANIFEST_DEPENDENCIES, dependency);
This isn’t working — the deployment unit processor runs without error, but when I try to reference classes provided by the module, I get NoClassDefFoundError.
Of course, If I add the same module identifier to the Dependencies manifest header in the deployment itself, all is well.
Perhaps this isn’t the way to approach this problem?
Thanks in advance for any tips/guidance,
carl
8 years, 1 month
Customizing a provisioned server
by Stuart Douglas
Hi everyone,
Work on the provisioning tool is now well underway, so I would like to
revisit something I mentioned in my original email, which is allowing
the provisioning tool to customize a provisioned server.
I think there are a few options here, some more palatable than others.
In no particular order:
1) Customize the XML directly
Using this approach we would just directly customize the XML
configuration files. This would basically require the use of XSLT
(yuck), or require us to basically invent our own version of XSLT (even
more yuck). Even though this approach will work, and will be fairly easy
to implement, I think it would really suck from an end-user point of
view, and I think we should discount it.
2) Allow the user to provide CLI commands to customise the server
This is by far my favorite approach. The provisioning file would just
contain a list of CLI commands, and would execute them in order. I think
this is by far the most intuitive, and the CLI is well documented.
3) Allow the user to provide DMR operations to customize the server
Similar to 2, but allow the user to provide DMR or JSON operations to
customize the server. I think this is not nearly as nice as 2, as users
are much more likely to be familiar with the CLI rather than DMR.
I think 2 is by far the best approach, however it does open up the
question of how and when to execute the operations. I think the easiest
way to do this would be to just start the server in admin only mode on a
custom port (so it will not interfere with any existing running Wildfly
instances), and just execute the CLI commands in admin only mode.
Does this all sound reasonable?
Stuart
8 years, 1 month
Moving WildFly 9 to Java 8?
by Tomaž Cerar
Hi folks,
we agreed that WildFly 10+ is going to require Java 8, given that its
release date is planned well after JDK7 will be EOL-ed. [1]
Looking at all discussion and new projects / components already require
JDK8 (Eltryon, new WildFly client, Weld 3,...) for development.
I was wondering if we could move WildFly 9 to Java 8 as well?
According to current release plan WF9 should be release around the same
time JDK7 is EOL-ed (April 2015) [1]
Pros of moving to JDK8 early:
- components can use JDK8 eariler --> better testing
- supporting JDK9 will be easier (-XX:MaxPermSize fails to start JVM on 9)
- support for TLS SNI (think of it as virtual hosts for SSL)
- better ciphers and many other security related improvements
- nashorn (fast javascript engine)
- better concurrency libs
- easier testing, one less JDK combo to test on CI
and of course all of the language improvements, lambda ftw!
Cons of moving early
- back porting of code could be impaired
- there is currently no non beta release of IBM JDK8
There are probably other pros & cons but in general I think it would be
better to upgrade early as there will be many
hidden issues with new Java 8 features people want to use but are server
doesn't understand currently, mostly here
are features like enhanced type annotations and default methods.
This problem are and will creep up more and more often as adoption of Java
8 is quite good already [2] and still rising.
so what do you guys think? Should we move for WildFly or should we wait for
10 as planned?
--
tomaz
[1] http://www.oracle.com/technetwork/java/eol-135779.html
[2] http://jaxenter.com/java-2-111936.html
8 years, 1 month
WildFly Core Alpha17 released
by Brian Stansberry
The latest in our roughly weekly series of WildFly Core alphas has been
released and merged into full WildFly's master branch.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
8 years, 1 month
Arquillian-core 1.1.7 is now in master
by Tomaž Cerar
He guys,
just heads up that arquillian-core was upgraded from our fork of 1.1.2 to
latest official 1.1.7.Final.
Everything should still work and even work better.
But if you do see any problems in our testsuite that resulted as part of
this let me know.
--
tomaz
8 years, 1 month
Embedding a WF instance in the CLI
by Brian Stansberry
Moving a thread to the dev list.
This is about some prototyping I've been doing on weekends 'cause I'm
bored with my regular tasks. I've been playing with direct local
administration of a WF installation via the CLI without requiring a
socket-based connection. The general use case is initial setup type
activities where the user doesn't want to have to launch a WF server or
HC process and potentially have it be visible on the network.
https://issues.jboss.org/browse/WFLY-3288 is one use case; another is a
desire some folks have expressed in being able to do configuration
without first having to edit any xml to avoid port conflicts on 9990 or
9999.
This isn't a major initiative or big priority or anything at this point.
Just something I find interesting and perhaps you will too.
On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
> Neat :) Yes, figuring out the module path is biting everywhere.
> For file system path command line arguments there is a specialized
> FileSystemPathArgument.
>
Thanks; I'll switch to that.
>
> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>> Copying Heiko Braun as he expressed some interest in the topic.
>>
>> BTW, I played with this a bit more last weekend and was able to start an
>> embedded server inside the CLI easily enough. See [1] for very raw
>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>
>> [disconnected/] embed-server
>>
>> There are a couple issues I see, besides the HC stuff I mentioned in my
>> last message.
>>
>> 1) If the CLI is started in a non-modular environment via java -jar
>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules into
>> the jar. And then the embed-server command would need params specifying
>> the location of JBOSS_HOME, possibly module path etc. But it could embed
>> a server installed in any accessible filesystem location.
>>
>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>> running from a WF dist in a modular environment and the embedded server
>> modules are coming from the CLI's own module path. It would be more
>> effort to support embedding a server based on some other module path.
>> Maybe it's no big deal; maybe it's really hard. :)
>>
>> 2) The console logging from the embedded server goes to stdout mixed in
>> with the CLI output. Maybe that's good, maybe it's bad.
>>
>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>
>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>> I was poking around at this for an hour or so over the weekend.
>>>
>>> The standalone case seems pretty straightforward. Seems the existing
>>> embedded server API could work readily enough. The
>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>> ModelControllerClient.
>>>
>>> The domain case is much harder, as the CLI wants a HostController, not a
>>> ProcessController. I'd really like this to use an in-VM client, not a
>>> remote one, so I don't like having the CLI embed a PC and then the HC is
>>> an external process. My thoughts of the morning are to allow inverting
>>> the HC/PC relationship for this kind of usage. That is, remove
>>> controlling the HC lifecycle from the charge of the PC component. CLI
>>> launches HC, and then the HC creates an in-process PC-ish component (not
>>> a separate process) to manage the server lifecycles. There could be all
>>> sorts of problems with that; it's just the thought for the morning.
>>>
>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>> Embedding the AS is the best starting point to achieve that! And more
>>>> fun, I agree :)
>>>>
>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>> And to think my reason for opening the Jira was just for a common
>>>>> way to
>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>
>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>> Wow! Indeed :)
>>>>>>>
>>>>>>> There could be an embedded scope - true, i.e. commands available
>>>>>>> only
>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>
>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>> implementation of all of them would be based in the server; the
>>>>>> "client"
>>>>>> aspect of the CLI would just use the management interface. The
>>>>>> difference between an embedded mode and what we have now would
>>>>>> just be
>>>>>> in how the "client" side gets its ModelControllerClient -- what we
>>>>>> have
>>>>>> now vs starting an embedded server and getting some sort of in-vm
>>>>>> client.
>>>>>>
>>>>>>> But it would still mean the server/controller would have to actually
>>>>>>> provide implementations of that functionality and expose it to the
>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>>> I like this idea as a concept - direct local management. W/o any
>>>>>>> remote
>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>
>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>> probably
>>>>>>> easier to implement at this point.
>>>>>>>
>>>>>>
>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>> thread
>>>>>> where I briefly get into this general area too.
>>>>>>
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>> Hi Alexey,
>>>>>>>>
>>>>>>>> Wanted to point the discussion on this JIRA out to you as it gets
>>>>>>>> into
>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>> interesting.
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use AESH or
>>>>>>>> move it
>>>>>>>> into the CLI
>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>> From: Darran Lofthouse (JIRA) <issues(a)jboss.org>
>>>>>>>> To: brian.stansberry(a)redhat.com
>>>>>>>>
>>>>>>>>
>>>>>>>> [
>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin....
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ]
>>>>>>>>
>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>> ----------------------------------------
>>>>>>>>
>>>>>>>> That could be very interested, won't go into too much detail in
>>>>>>>> this
>>>>>>>> Jira as it is not directly related shortly I am switching to the
>>>>>>>> SSL
>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>> enablement we talked about in Brno - managing an embedded instance
>>>>>>>> could
>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>
>>>>>>>> I can see this task may end up coming back my way combined with the
>>>>>>>> other stuff ;-)
>>>>>>>>
>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>> ---------------------------------------------------
>>>>>>>>>
>>>>>>>>> Key: WFLY-3288
>>>>>>>>> URL: https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>> Project: WildFly
>>>>>>>>> Issue Type: Feature Request
>>>>>>>>> Security Level: Public(Everyone can see)
>>>>>>>>> Components: Domain Management, Scripts
>>>>>>>>> Reporter: Darran Lofthouse
>>>>>>>>> Fix For: Awaiting Volunteers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Within the add-user utility it is difficult to handle situations
>>>>>>>>> where
>>>>>>>>> we do not have access to a java.io.Console which is the easiest
>>>>>>>>> way to
>>>>>>>>> handle password reading without an echo to the user e.g. in Cygwin
>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>> there to
>>>>>>>>> handle this.
>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>> special
>>>>>>>>> mode of the CLI, we may at some point want to switch to runtime
>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>> could be
>>>>>>>>> the first step to make this possible.
>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>> comments
>>>>>>>>> here are just a starting point.
>>>>>>>>
>>>>>>>> --
>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>> administrators
>>>>>>>> For more information on JIRA, see:
>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
8 years, 1 month
