Building WildFly 9.0.0.Alpha2-SNAPSHOT
by Sandeep Samdaria
Hi,
I am trying to build wildfly locally. I am facing the errors mentioned
below. I had sent a similar mail three weeks ago and got no response.
Yesterday, I had posted this on jboss forum
https://developer.jboss.org/message/906929. Jaikiran suggested to re-post
it to with the latest wildfly code.
Environment:
*OS* : Ubuntu 12.04(64bit)
*Java* : version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode)
Is there something obvious that I am missing? Please let me know.
*Error *
sandeep@sandeep:~/development/grails-project/wildfly$ ./build.sh
Maven already exists
Maven is correct version
./tools/maven/bin/mvn -s tools/maven/conf/settings.xml install
[INFO] Scanning for projects...
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] WildFly: Parent Aggregator
[INFO] WildFly: Naming Subsystem
[[[ truncated some of the unrelated logs ]]]]
[INFO] WildFly Test Suite: Integration - Smoke
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building WildFly: Parent Aggregator 9.0.0.Alpha2-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @
wildfly-parent ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @
wildfly-parent ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @
wildfly-parent ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create-timestamp
(get-build-timestamp) @ wildfly-parent ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @
wildfly-parent ---
[INFO] Executing: /bin/sh -c cd
/home/sandeep/development/grails-project/wildfly && git rev-parse --verify
HEAD
[INFO] Working directory: /home/sandeep/development/grails-project/wildfly
[INFO] Storing buildNumber: 206ad185abcaec3dc00ab87e07e23829bd0baee2 at
timestamp: 1413270863566
[INFO] Storing buildScmBranch: master
[INFO]
[INFO] --- maven-checkstyle-plugin:2.12.1:checkstyle (check-style) @
wildfly-parent ---
[INFO]
[INFO] --- maven-source-plugin:2.3:jar-no-fork (attach-sources) @
wildfly-parent ---
[INFO]
[INFO] --- maven-install-plugin:2.5.1:install (default-install) @
wildfly-parent ---
[INFO] Installing /home/sandeep/development/grails-project/wildfly/pom.xml
to
/home/sandeep/.m2/repository/org/wildfly/wildfly-parent/9.0.0.Alpha2-SNAPSHOT/wildfly-parent-9.0.0.Alpha2-SNAPSHOT.pom
[INFO]
[INFO]
------------------------------------------------------------------------
[INFO] Building WildFly: Naming Subsystem 9.0.0.Alpha2-SNAPSHOT
[INFO]
------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (ban-bad-dependencies) @
wildfly-naming ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @
wildfly-naming ---
[INFO]
[INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @
wildfly-naming ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create-timestamp
(get-build-timestamp) @ wildfly-naming ---
[INFO]
[INFO] --- buildnumber-maven-plugin:1.3:create (get-scm-revision) @
wildfly-naming ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
wildfly-naming ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 9 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
wildfly-naming ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 87 source files to
/home/sandeep/development/grails-project/wildfly/naming/target/classes
[INFO] -------------------------------------------------------------
[WARNING] COMPILATION WARNING :
[INFO] -------------------------------------------------------------
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/RemoteNamingAdd.java:[30,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingBindingAdd.java:[41,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingSubsystemAdd.java:[27,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/RemoteNamingAdd.java:[30,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingBindingAdd.java:[41,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[WARNING]
/home/sandeep/development/grails-project/wildfly/naming/src/main/java/org/jboss/as/naming/subsystem/NamingSubsystemAdd.java:[27,31]
org.jboss.as.controller.ServiceVerificationHandler in
org.jboss.as.controller has been deprecated
[INFO] 6 warnings
[INFO] -------------------------------------------------------------
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Cannot read org.jboss.as.naming.logging package files, cause :
java.io.FileNotFoundException: org.jboss.as.naming.logging/NamingLogger
at
com.sun.tools.javac.processing.JavacFiler.getResource(JavacFiler.java:464)
at
org.jboss.logging.processor.apt.TranslationClassGenerator.findTranslationFiles(TranslationClassGenerator.java:152)
at
org.jboss.logging.processor.apt.TranslationClassGenerator.processTypeElement(TranslationClassGenerator.java:115)
at
org.jboss.logging.processor.apt.LoggingToolsProcessor.process(LoggingToolsProcessor.java:145)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
at com.sun.tools.javac.main.Main.compile(Main.java:417)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] WildFly: Parent Aggregator ......................... SUCCESS [
5.533 s]
[INFO] WildFly: Naming Subsystem .......................... FAILURE [
5.495 s]
[INFO] WildFly: EE ........................................ SKIPPED
[[[ truncated some of the unrelated logs ]]]]
[INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 20.434 s
[INFO] Finished at: 2014-10-14T12:44:31+05:30
[INFO] Final Memory: 170M/465M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project wildfly-naming: Compilation failure
[ERROR] Cannot read org.jboss.as.naming.logging package files, cause :
java.io.FileNotFoundException: org.jboss.as.naming.logging/NamingLogger
[ERROR] at
com.sun.tools.javac.processing.JavacFiler.getResource(JavacFiler.java:464)
[ERROR] at
org.jboss.logging.processor.apt.TranslationClassGenerator.findTranslationFiles(TranslationClassGenerator.java:152)
[ERROR] at
org.jboss.logging.processor.apt.TranslationClassGenerator.processTypeElement(TranslationClassGenerator.java:115)
[ERROR] at
org.jboss.logging.processor.apt.LoggingToolsProcessor.process(LoggingToolsProcessor.java:145)
[ERROR] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:793)
[ERROR] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:722)
[ERROR] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1700(JavacProcessingEnvironment.java:97)
[ERROR] at
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1029)
[ERROR] at
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1163)
[ERROR] at
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1106)
[ERROR] at
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:824)
[ERROR] at com.sun.tools.javac.main.Main.compile(Main.java:417)
[ERROR] at
com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:132)
[ERROR] at
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126)
[ERROR] at
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
[ERROR] at
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:785)
[ERROR] at
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
[ERROR] at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
[ERROR] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
[ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
[ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
[ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[ERROR] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.lang.reflect.Method.invoke(Method.java:601)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR] at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :wildfly-naming
Thanks,
Sandeep.
10 years, 2 months
status attribute for datasources
by Claudio Miranda
Hi, what do you think of adding a "status" attribute for datasources ?
It should have the same meaning of "status" for deployment.
The deployment have the status attribute, that says if the application
was properly deployed and is running.
/deployment=jboss-kitchensink.war:read-attribute(name=status)
{
"outcome" => "success",
"result" => "FAILED"
}
However there is no way in CLI mode to ask if a datasource (RA also)
is working, user must check for exceptions in the log.
The proposal is to add an attribute status to a datasource and RA, it
will be true if test-connection-in-pool returns true, otherwise false.
Every moment the datasource configuration changes, a test-connection
is performed.
I came to this suggestion, as was working for a customer that has 16
datasources (they are migrating from weblogic) and there were some
connections errors, but the user was unable to see at once which
connections failed, they needed to grep log. It would be very useful
to have this attribute.
Kind regards
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years, 2 months
Proposal to add notifications to WildFly management model and API
by Jeff Mesnil
# Add Notification support to WildFly Management
Tracked by https://issues.jboss.org/browse/WFLY-266
Use Cases
---------
Notifications are an useful mechanism to observe management changes on WildFly servers.
It allows an administrator to be informed of changes outside of his own actions (e.g. a server has been killed, a new application is deployed, etc.)
Currently WildFly lacks notifications and users that were depending on JMX notifications in previous versions have no similar feature to use.
The most expected use cases for WildFly notifications are:
- enhance UX for Web console. Using notifications, the Web console could notify the users of changes outside its own actions.
- replacement for JMX notifications. Users that were listening for JMX notifications to observe management changes would have a similar feature using WildFly own notifications
- integration with JMX. Notifications emitted by WildFly could be converted and made available using JMX notifications (including notifications for mbean registered/unregistered)
Part 1: Notification Definition
-------------------------------
A resource will define the notifications it emits. These definitions will be added to the attributes and operations definitions on a resource.
{
"description" => "A manageable resource",
"attributes" => {
...
},
"operations" => {
...
},
"notifications" => {
"resource-added" => {
...
}
},
"children" => {
...
}
}
The description of a notification will be composed of:
* type - String - the type of notification (resource-added, server-stopped, etc.)
* description - String - i18ned description of the notification
* access-constraints - the RBAC access constraints that controls who can receive the notifications
* data-type - ModelType or complex structure - optional - only present if the notification will have a data value. data-type will detail the structure of the data value, enumerating the value's fields and the type of their value
The read-resource-description will be enhanced with a notifications parameter (boolean) to include the notifications descriptions (default value is false, same as the operations parameter).
The ManagementResourceRegistration interface will be enhanced to register a notification definition with registerNotification(NotificationDefinition notification). The NotificationDefinition interface corresponds to the detyped representation of a notifications and comes with a builder API.
Part 2: Emitting a notification
-------------------------------
A notification can be emitted in any OperationStepHandler using the OperationContext.emit(Notification method)
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
// perform some actions
...
context.emit(new Notification(SERVER_RESTARTED_NOTIFICATION, address, ROOT_LOGGER.serverHasBeenRestarted()));
context.stepCompleted();
}
The notification is *not* emitted (i.e. delivered to interested parties) when OperationContext.emit() is called. It is emitted at the end of the operation step only if it is successful. A call to OperationContext.emit() will have no effect if the operation is rolled back.
Notification emission is done asynchronously using the server thread pool and does not block the execution of the operation that triggered the notification: having zero or any notification handlers must have no impact of the execution of the operation.
A Notification is a simple Java class that represents the notification. It is composed of:
* type - String - the notification type
* address - PathAddress - the address of the resource that emits the notification
* message - String - the i18ned description of the message
* timestamp - long - the timestamp of the notification. It is set when the Notification object is created.
* data - ModelNode - optional - a detyped representation of data associated to the notification. If a notification includes a data field, its definition must describe it (in its data-type parameter).
If RBAC is enabled, the notification access-constraints will be checked to ensure that the handler have the required privileges to receive the notification. Notification will potentially contain critical information (e.g. if a security-credential attribute is updated, the notification will contain its old and new values) and must be constrained accordingly.
Part 3: Global Resource Notifications
——————————————————
In the same way that some operations are available for any resource (e.g. add, remove, read-resource-description), some notifications will be added to any resource of WildFly management model:
* resource-added - when a resource is added, it emits a resource-added notification
* resource-removed - when a resource is removed, it emits a resource-removed notification
* attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information:
* name - String - the name of the attribute
* old-value - the detyped representation of the previous value of the attribute
* new-value - the detyped representation of the new value
Part 4: Notification Handlers
——————————————
Any interested parties can receive notifications by registering a NotificationHandler using the ModelController.getNotificationSupport().registerNotificationHandler(source, handler, filter) method.
The source is a path address to handle notifications emitted by resources at this address.
The NotificationHandler is an interface with a single handleNotification(Notification notification) method.
The isNotificationEnabled(Notification notification) is an interface with a single isNotificationEnabled(Notification notification) method to filter out uninteresting notifications.
There is a similar unregister method to unregister a (handler, filter)
To be useful, the source path address will have to accept wildcards for the address' values:
* /subsystem=messaging/hornetq-server=* to receive notifications emitted by any hornetq-server resources
* /subsystem=messaging/hornetq-server=*/jms-queue=* to receive notifications emitted by any jms-queue on any hornetq-server resources
Wildcards for address' keys or key/value paris are not allowed (/subsystem=messaging/*=*/jms-queue=* and /subsystem=messaging/*/jms-queue=* are not valid).
This notion of wildcard for the resource addresses should be made to match current usage (e.g. in the CLI).
The main reason for the wildcard is for the resource-added/resource-removed notifications. I find more intuitive to have the notifications at the same resource-level than their corresponding add/remove operations. However until the resource is created, there is no way to register a notification listener on it without using a wildcard.
If that proves problematic, we could change this approach with two alternatives:
* have a single well-known resource emit the notifications for all resource (that's the JMX approach). A likely candidate would be /core-service=management
* the resource-added/-removed notifications can be emitted by the resource parents (but it only fixes the issue for the last leaf of the address tree…)
I still have questions about RBAC enforcements and it is possible that the registration of a handler will have to be done with additional metadata identifying the user roles wrt RBAC...
Part 5: Domain Notifications
——————————————
Notifications are also intended to work in domain mode. In particular, they will be used to observe server state.
The following notifications will be emitted by resources at /host=XXX/server-config=YYY (i.e. the resource to start/stop/etc. a server):
* server-started
* server-stopped
* server-restarted
* server-destroyed
* server-killed
Part 6: Integration with local JMX
—————————————————
The jmx subsystem will be updated to leverage the WildFly notifications and expose them as MBean notifications in our jmx facade for the management model:
* the WildFly notification description will be converted to MBeanNotificationInfo and added to the MBeanInfo
* when a JMX notification listener is added to an ObjectName, a WildFly NotificationHandler will be added to the path address corresponding to the ObjectName.
* depending on the user feedback, we may provide a hack to convert some WildFly notifications to their well-known JMX equivalent notifications (e.g. resource-added => jmx.mbean.registered).
In a first step, integration will be limited to use of JMX locally. Remoting will not be supported.
Part 7: Integration with Remote Management API
———————————————————————
We will enhance the remote management native API to register/unregister a notification handler from the ModelControllerClient
void registerNotificationHandler(ModelNode resourceAddress, NotificationClientHandler handler, NotificationClientFilter filter);
The client contract will have to taken into account reconnection when server is reloaded (possibly by caching the handler & filter and register them again after reconnection to the server...)
The Management HTTP API will also be enhance to support notifications with its REST API.
A neat addition will be to provide a browser-specific way to push notifications to the browser (e.g. using Server-Sent Events or Web Sockets).
=> the Web Console is the recipient for this feature and will have their say in how they prefer to consume notifications
Part 8: Integration with Remote JMX
—————————————————
Once the WildFly Management API will support notifications (for both native and HTTP), we can add support to JMX remotely (if there is any user interest for it).
Part 9: Web Console UX improvement
—————————————————
Once the Management HTTP API supports notifications, the Web console can leverage it to improve its UX.
This is a task that touch different parts of the app server (mainly in wildfly-core though) and I intend to split it in different JIRA issues (approx. one for each part) that can be merged one after the other instead of a big huge commit.
What do you think?
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
10 years, 2 months
HAL: show deployment status
by Claudio Miranda
Hi, on deployment view, it shows the "enabled" attribute for
deployments, but if the deploy failed for some reason (status=false)
the user only sees the 404 http error code when he tries to access the
application.
Also the "ok" mark (icon) on the deploy view, lead to user think the
deploy was ok
I propose to add the deploy "status" attribute besides the "enabled"
attribute, but only if the status is failed. An example
http://imgur.com/WhrzewT
I know the image is horrible, but it shows the proposal. It is
important to show it in the list view and not in the attribute list
below them, because the failed deployments should be quickly visible
in web console.
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
10 years, 2 months
WildFly Core component upgrade coordination
by David M. Lloyd
If you are assigned a JIRA for WildFly that requires a change to WildFly
Core (either a direct fix or a component upgrade), there (obviously)
needs to be a WildFly Core release and upgrade into WildFly proper
before the change can be completed. But because we're all asynchronous
here, coordination is something of a problem.
So, to organize things a bit, I've opened
https://issues.jboss.org/browse/WFLY-3945 for upgrading WildFly Core to
1.0.0.Alpha9.
If you have a WFCORE task or component upgrade that you think should be
finished before the upgrade happens, add the corresponding JIRA as a
dependency to that issue. If a WFLY task is blocked waiting for the
WFCORE upgrade, add that task as a dependent (in other words, add
WFLY-3945 as a dependency to that task; you can do it either way though).
If the list gets too large, we'll have a discussion about splitting the
work between Alpha9 and Alpha10 (or whatever is next).
Keeping the work organized around this issue will remove some of the
confusion around what needs updating and when, and why.
--
- DML
10 years, 2 months
IPv6 testing changes
by Tomaž Cerar
Hi guys,
JGroups update <https://github.com/wildfly/wildfly/pull/6805> exposed a
problem with our ipv6 testing on our CI.
To fix that we had to modify the network configuration on all build agents
and config how ipv6 testsuite is ran.
As part of work we also simplified testing on ipv6 where now all you
need to pass to testsuite is -Dipv6.
for anyone of you that runs ipv6 testsuite locally on linux add this config
for your network:
# Allow loopback to multicast
ip -6 route add table local local ff13::/16 dev lo metric 5
# Add an additional "unique" address to lo for clustering tests
ifconfig lo add fccc::2/128
Anyone that has currently open PR that is not merged yet, to rebase them
as otherwise you will get clustering & domain ipv6 related test failures.
--
tomaz
10 years, 2 months
