Wildfly 9.0.1 - Roadmap
by Carvalho, Tercio Spina
Hi all
Do you have any information about end-of-life or support of Wildfly 9.0.1?
Regards.
Tercio Spina.
8 years, 7 months
"WildFly Test Suite: Integration - Web" fails completely since today
by Frank Langelage
After checkout of current Wildfly 10 CR1 sources the build with smoke
tests fails. As of Friday everything was fine.
Tests in error:
DeploymentOverlayTestCase.org.jboss.as.test.integration.deployment.deploymentoverlay.DeploymentOverlayTestCase
? Deployment
WarResourceListingTestCase.org.jboss.as.test.integration.deployment.resourcelisting.WarResourceListingTestCase
? Deployment
WarClassLoadingTestCase.org.jboss.as.test.integration.deployment.classloading.war.WarClassLoadingTestCase
? Deployment
WebModuleDeploymentTestCase.org.jboss.as.test.integration.web.annotationsmodule.WebModuleDeploymentTestCase
? Deployment
CustomErrorsUnitTestCase.org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
? Deployment
FormAuthUnitTestCase.org.jboss.as.test.integration.web.formauth.FormAuthUnitTestCase
? Deployment
UndertowHandlersConfigTestCase.org.jboss.as.test.integration.web.handlers.UndertowHandlersConfigTestCase
? Deployment
RequestDumpingHandlerTestCase.org.jboss.as.test.integration.web.handlers.RequestDumpingHandlerTestCase
? Deployment
ExternalTagLibTestCase.org.jboss.as.test.integration.web.jsp.taglib.external.ExternalTagLibTestCase
? Deployment
JspMappingTestCase.org.jboss.as.test.integration.web.jsp.JspMappingTestCase
? Deployment
JspSecurityManagerTestCase.org.jboss.as.test.integration.web.jsp.JspSecurityManagerTestCase
? Deployment
DefaultServletMultipartConfigTestCase.org.jboss.as.test.integration.web.multipart.defaultservlet.DefaultServletMultipartConfigTestCase
? Deployment
ReverseProxyTestCase.org.jboss.as.test.integration.web.reverseproxy.ReverseProxyTestCase
? Deployment
ReverseProxyTestCase.tearDown:142 NullPointer
RootContextWarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextWarUnitTestCase
? Deployment
RootContextEarUnitTestCase.org.jboss.as.test.integration.web.rootcontext.RootContextEarUnitTestCase
? Deployment
WebSecurityBASICTestCase.org.jboss.as.test.integration.web.security.basic.WebSecurityBASICTestCase
? Deployment
WebSecurityCERTTestCase.org.jboss.as.test.integration.web.security.cert.WebSecurityCERTTestCase
? Deployment
WebSecurityExternalAuthTestCase.org.jboss.as.test.integration.web.security.external.WebSecurityExternalAuthTestCase
? Deployment
WebSecurityJBossSimpleRoleMappingTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityJBossSimpleRoleMappingTestCase
? Deployment
WebSecurityFORMTestCase.org.jboss.as.test.integration.web.security.form.WebSecurityFORMTestCase
? Deployment
WebSecurityProgrammaticLoginTestCase.org.jboss.as.test.integration.web.security.servlet3.WebSecurityProgrammaticLoginTestCase
? Deployment
TransportGuaranteeTestCase.org.jboss.as.test.integration.web.security.tg.TransportGuaranteeTestCase
? Deployment
ServletLifecycleMethodDescriptorTestCase.org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase
? Deployment
EmptyCompEnvTestCase.org.jboss.as.test.integration.web.servlet.enc.empty.EmptyCompEnvTestCase
? Deployment
ServletResourceOverlaysTestCase.org.jboss.as.test.integration.web.servlet.overlays.ServletResourceOverlaysTestCase
? Deployment
SharedSessionTestCase.org.jboss.as.test.integration.web.sharedsession.SharedSessionTestCase
? Deployment
ServletThreadPoolSelectionTestCase.org.jboss.as.test.integration.web.threads.ServletThreadPoolSelectionTestCase
? Deployment
WebSocketTestCase.org.jboss.as.test.integration.web.websocket.WebSocketTestCase
? Deployment
CookieUnitTestCase.org.jboss.as.test.integration.web.cookie.CookieUnitTestCase
? Deployment
UndertowNonBlockingHandlerTestCase.org.jboss.as.test.integration.web.extension.UndertowNonBlockingHandlerTestCase
? Deployment
DefaultConcurrencyServletTestCase.org.jboss.as.test.integration.ee.naming.defaultbindings.concurrency.DefaultConcurrencyServletTestCase
? Deployment
DefaultContextServiceServletTestCase.org.jboss.as.test.integration.ee.concurrent.DefaultContextServiceServletTestCase
? Deployment
JspTagTestCase.org.jboss.as.test.integration.jsp.JspTagTestCase ?
Deployment C...
WarNotAsClientTest.org.jboss.as.test.smoke.web.WarNotAsClientTest ?
Deployment
WarTestCase.org.jboss.as.test.smoke.web.WarTestCase ? Deployment
Cannot deploy...
Tests run: 40, Failures: 0, Errors: 36, Skipped: 4
...
[INFO] WildFly: Servlet Distribution ...................... SUCCESS [
10.220 s]
[INFO] WildFly: Web Services Tests Integration Subsystem .. SUCCESS [
8.569 s]
[INFO] WildFly Test Suite: Shared ......................... SUCCESS [
11.796 s]
[INFO] WildFly Test Suite: Aggregator ..................... SUCCESS
[02:18 min]
[INFO] WildFly Test Suite: Integration .................... SUCCESS [
7.957 s]
[INFO] WildFly Test Suite: Integration - Web .............. FAILURE
[01:07 min]
[INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED
The Caused by seems to be always the same:
Caused by: javax.security.sasl.SaslException: Authentication failed: all
available authentication mechanisms failed:
JBOSS-LOCAL-USER: Server rejected authentication
DIGEST-MD5: Server rejected authentication
at
org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:198)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:112)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at
org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:545)
at ...asynchronous invocation...(Unknown Source)
at
org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
at
org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
at
org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:83)
at
org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:114)
at
org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:257)
at
org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:71)
at
org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212)
at
org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146)
at
org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65)
at
org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147)
at
org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168)
at
org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeAsync(AbstractModelControllerClient.java:111)
at
org.jboss.as.controller.client.helpers.standalone.impl.ModelControllerClientServerDeploymentManager.executeOperation(ModelControllerClientServerDeploymentManager.java:50)
at
org.jboss.as.controller.client.helpers.standalone.impl.AbstractServerDeploymentManager.execute(AbstractServerDeploymentManager.java:79)
at
org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:54)
at
org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
at
org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
at
org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
at
org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:144)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
at
org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at
org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at
org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at
org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
at
org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
at
org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
at
org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:201)
at
org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
at
org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
at
org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
at org.junit.runners.Suite.runChild(Suite.java:127)
at org.junit.runners.Suite.runChild(Suite.java:26)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Connecting to the server via jboss-cli.sh to run a script fails also:
Failed to connect to the controller: Unable to authenticate against
controller at localhost:9990: Authentication failed: all available
authentication mechanisms failed:
DIGEST-MD5: Server rejected authentication
Platform is Oracle Solaris SPARC 10.
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
8 years, 7 months
Early Access builds for JDK 8u66 b02 and JDK 9 b78 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 8u66 b02 <http://jdk8.java.net/download.html>
is available on java.net, summary of changes are listed here.
<http://download.java.net/jdk8u66/changes/jdk8u66-b02.html?q=download/jdk8...>
Early Access build for JDK 9 b78 <https://jdk9.java.net/download/> is
available on java.net, summary of changes are listed here
<http://download.java.net/jdk9/changes/jdk9-b78.html?q=download/jdk9/chang...>.
With respect to ongoing JDK 9 development, I'd like to draw your
attention to the following requests to provide
feedback on the relevant mailing lists.
*OpenJDK JarSigner API*
JDK 9 is more restricted on calling sun.* public methods but we know
there are users calling
sun.security.tools.jarsigner.Main to sign jar files. A new API is
proposed
<http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012636.html>for
this very purpose in OpenJDK.
Feedback on this API should be provided on the security-dev
<http://mail.openjdk.java.net/mailman/listinfo/security-dev> mailing list.
*RFC JEP: NIST SP 800-90A SecureRandom implementations : *Feedback on
this draft
<http://mail.openjdk.java.net/pipermail/security-dev/2015-August/012667.html>
JEP should be provided
on the security-dev
<http://mail.openjdk.java.net/mailman/listinfo/security-dev> mailing list.
*
* *Public API for internal Swing classes*
According to the JEP 200: The Modular JDK
<http://openjdk.java.net/jeps/200> we expect that classes from internal
packages (like sun.swing) will not be
accessible. If you are using the internal Swing API and it is not
possible to replace it by public API, please provide
feedback on the swing-dev
<http://mail.openjdk.java.net/mailman/listinfo/swing-dev> mailing list.
If you haven’t already subscribed to a list then please do so first,
otherwise your message will be discarded as spam.
Finally, videos of presentations from the JVM Language Summit have been
published at :
http://www.oracle.com/technetwork/java/javase/community/jlssessions-2015-...
.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
8 years, 7 months
Permissions in WildFly Core
by Josef Cacek
Hi *,
Is there a way how to configure Java security permissions in WildFly Core?
If not, is there any reason why not to move the wildfly-security-manager from WildFly into WildFly Core?
I'm investigating failing tests in WildFly Core testsuite ([1],[2]) when security manager is enabled.
The problem is, security manager is in place and I'm not able to define permissions for deployments
- using policy file (configured by java.security.policy system property) doesn't work for me;
- putting META-INF/permissions.xml into deployments doesn't help because PermissionsParseProcessor deployment processor is part of wildfly-security-manager (i.e. not in Core) and it is only activated when security-manager subsystem is present.
So the tests fail because of AccessControlExceptions on the server side.
Any thoughts?
As a workaround we can run the Core testsuite against full WildFly and use either in-deployment permissions.xml or configure permissions in subsystem [3] - but both ways have some disadvantages.
We either have to put "unnecessary" permissions.xml in WFCORE deployments or we have to use too wide minimum-permissions in security-manager subsystem configuration.
[1] https://issues.jboss.org/browse/WFCORE-846
[2] https://issues.jboss.org/browse/JBEAP-526
[3] /subsystem=security-manager/deployment-permissions=default:write-attribute(name=minimum-permissions, value=[{class=java.security.AllPermission}])")
Thanks,
-- Josef Cacek
8 years, 7 months
Wildfly SSL and mutual SSL authentication quickstarts
by Giriraj Sharma
Hi,
I had a look at wildfly quickstarts[1]. If it looks fine, I would like to
add a few Wildfly SSL quickstarts like
#1. A simple helloworld or helloworld-rs or helloworld-html5 app or all of
these demonstrating enabling SSL over wildfly. (configuring keystore, https
listener)
#2. A simple helloworld or helloworld-rs or helloworld-html5 app or all of
these demonstrating enabling mutual client authentication via SSL.
(configuring keystore, truststore and https listener)
#3. Securing war apps [a simple helloworld or helloworld-rs or
helloworld-html5 app or all of these ] deployed over wildfly (Configuring
keystore, truststore, https-listener and security-domain using login
modules(CertificateRoles))
[1] https://github.com/wildfly/quickstart
<https://github.com/wildfly/quickstart>
--
Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
8 years, 7 months
Persisting attributes explicitly set to default values
by Dominik Pospisil
Is there any rule saying if an attribute should be persisted if it is
explicitly set to it's default value or not?
At least some attributes in the legacy web subsystem are persisted in such
case and some are not.
It seems that the API encourages to choose any of the options. Is there any
reason for that?
Many thanks,
- Dominik
8 years, 7 months
Widlfly 9.0.1.Final - subsystem expression evaluation not entirely water proof
by Dennis Brouwer
Dear reader,
We recently moved to Wildfly 9.0.1.Final (from 8.2.0) for testing and
stumbled upon a bug regarding expression evaluation in the standalone*.xml.
Let me give an example for the following subsystem:
<subsystem xmlns="urn:jboss:domain:jgroups:3.0">
<channels default="ee">
<channel name="ee"/>
</channels>
...
</subsytem>
Since we have several deployment stages on one physical server we need to
separate the clusters by using a distinct name for each one of the stages
deployed. Hence we introduced a startup property to be substituted in the
standalone*.xml configuration like following snippet clarifies:
<subsystem xmlns="urn:jboss:domain:jgroups:3.0">
<channels default="${custom_clustername:ee}">
<channel name="${custom_clustername:ee}"/>
</channels>
...
</subsytem>
Using this approach however fails to start the container because the
channels default attribute is properly evaluated to "ee" (accoding to
specs). However the channel name attribute is not evaluated at all and is
registered as "${custom_clustername:ee}" (without the quotes).
I took the liberty to dig in the class:
org.jboss.as.clustering.jgroups.subsystem.JGroupsSubsystemXMLReader and
manually do the expression evaluation for the channel name. At first glance
this seems to work however the container rewrites the standalone*.xml file
at a certain moment resulting in this snippet:
<subsystem xmlns="urn:jboss:domain:jgroups:3.0">
<channels default="${custom_clustername:ee}">
<channel name="ee"/>
</channels>
...
</subsytem>
Which on subsequent container starts and when using the
-Dcustom_clustername=whee
startup property causes a problem because the channels default is evaluated
to "whee" and the channel name remains "ee".
So my questions are:
1] How to solve this issue in a correct way?
2] Can somebody provide another mechanism to configure a non default
channel name on startup?
--
Best regards,
*Dennis Brouwer*
Extraordinary Goalkeeper
ZEEF - Kizitos B.V.
Amstelboulevard 184
1096 HM Amsterdam
www.ZEEF.com <http://www.zeef.com/>
US: +1 (415) 992-9409
NL: +31 (085) 888-3186
8 years, 7 months
Migration management operation - open questions
by Miroslav Novak
Hi,
we have a few questions related to correct behavior of the :migrate operation for following subsystems:
- JBoss Web to Undertow [1]
- HornetQ to Apache ActiveMQ Artemis [2]
- jacorb to iiop-openjdk [3]
Part of it was already clarified on wildfly-dev list [4] but there are still unspecified topics related to work flow and expected results of migration operation. We summarized them into following questions:
1. What will be the precise set of steps the administrator must perform to migrate legacy subsystem in standalone mode and domain mode? What are the specifics and limitations for domain mode?
2. If legacy subsystem is dependent on element defined in another subsystem but does not exist in new configuration, can migration operation create it on its own? Or should it just print warning?
-- For example legacy subsystem can depend on socket-binding which does not exist in new configuration. Should migration operation create socket-binding?
3. What is the expected behavior when part which was configured as part of the legacy subsystem is now configured outside of new subsystem having just reference to it? Should the migration operation create the additional configuration even when it is manipulating with configuration parts outside of the subsystem?
-- For example ssl configuration of https connector/listener. In Web subsystem it is part of the connector configuration, in Undertow it is just reference to security realm and it is defined as part of the security realms, should new security realm be created with equivalent configuration to the one in legacy Web subsystem?
4. What should happen if some other subsystem is expecting definition of element in new migrated configuration but it's not there after migration?
-- For example ejb subsystem has by default "activemq-ra" as default resource adapter for MDBs and migrated Artemis subsystem will not contain it.
5. We generally believe that if the :migrate operation can detect an error, it should do that and provide a warning. Only when an error situation can be detected at runtime the :migrate operation should be allowed not to print any warning. Is this accounted for, or at least do we agree on this?
6. Should the extensions for old subsystems be left in configuration after migration?
7. Should the :migrate operation return reload-required header?
Thank you,
Mirek
[1] https://issues.jboss.org/browse/EAP7-326
[2] https://issues.jboss.org/browse/EAP7-327
[3] https://issues.jboss.org/browse/EAP7-328
[4] http://lists.jboss.org/pipermail/wildfly-dev/2015-April/003841.html
8 years, 7 months
clarification on why Wildfly versions are increasing so quickly
by Karl Pietrzak
Hi everyone!
First off, kudos to everyone for a great product!
Secondly, I'm wondering if someone could explain to me the significance of
the quick succession of Wildfly version upgrades: from 8 -> 9 -> 10 (soon).
It seemed like we were on JBoss 7.x for a long time, and now the top link
at http://wildfly.org/downloads/ is actually the Wildfly 10.x beta.
Does this represent:
1. a sudden increase in contributions and feature work?
2. shift in marketing (i.e., no underlying tech changes)
3. something else
Our concern is that this represents some instability / internal dynamics /
change in policy that would encourage us to visit other app servers.
Thank you!
--
Karl
8 years, 7 months
Metrics & runtime attribute registration
by Tomaž Cerar
Hey guys,
We had interesting discussion with Brian on
https://github.com/wildfly/wildfly-core/pull/848#issuecomment-119778986
about how we register runtime/metric attribute on resources.
There are many cases where subsystems only register attributes / resources
only when server is booting into normal mode.
but if it server is booted only to "admin mode" all that runtime/metrics
attributes are not registered and as such not seen in the model.
Registering runtime attributes only in normal mode can cause that results
of :read-resource-description/read-resource
wouldn't return attributes that are on resources if server is started in
admin mode or even CLI standalone.
Our metadata already provides information if attributes is
runtime/metric/configuration.
This can cause problems for tooling that relies on output of those two
operations.
Looking at current state of the code, we do use both ways of registering
attributes either conditionally or always.
This probably originates from times where there was no good api/way to mark
attribute/resource as runtime.
I am personally am in favor of always registering runtime attributes as
this makes sure that user isn't surprised by some extra/missing
attributes based on fact how it is starting the server.
What do you guys think? Should we always register it or have it
conditionally?
--
tomaz
8 years, 7 months
