Srcdeps in WildFly and WildFly Core
by Peter Palaga
Hi *,
this is not new to those of you who attended my talk on the F2F 2016 in
Brno. Let me explain the idea here again for all others who did not have
a chance to be there.
Srcdeps [1] is a tool to build Maven dependencies from their sources.
With srcdeps, wildfly-core can depend on a specific commit of, e.g.,
undertow:
<version.io.undertow>1.4.8.Final-SRC-revision-aabbccd</version.io.undertow>
where aabbccd is the git commit id to build when any undertow artifact
is requested during the build of wildfly-core.
[1] describes in detail, how it works.
The main advantage of srcdeps is that changes in components can be
integrated and tested in wildfly-core immediately after they are
committed to a public component branch. There is no need to wait for the
component release.
Here in the WildFly family of projects, it is often the case that
something needs to be fixed in a component, but the verification (using
bug reproducer, or integration test) is possible only at the level of
wildfly or wildfly-core. Engineers typically work with snapshots
locally, but when their changes need to get shared (CI, reviews) in a
reproducible manner, snapshots cannot be used anymore.
In such situations a source dependency come in handy: it is very easy to
share and it is as reproducible as a Maven build from a specific commit
can be. All CIs and reviewers can work with it, because all source
dependency compilation is done under the hood by Maven.
Developers working on changes that span over multiple interdependent git
repos can thus get feedback (i-tests, reviews) quickly without waiting
for releases of components.
Srcdeps emerged in the Hawkular family of projects to solve exactly this
kind of situation and is in use there since around October 2015.
When I said there is no need to wait for releases of components, I did
not mean that we can get rid of component releases altogether. Clearly,
we cannot, because i.a. for any tooling uninformed about how srcdeps
work, those source dependencies would simply be non-resolvable from
public Maven repositories. So, before releasing the dependent component
(such as wildfly-core) all its dependencies need to be released. To
enforce this, srcdeps is by default configured to make the release fail,
as long as there are source dependencies.
I have sent a PR introducing srcdeps to wildfly-core:
https://github.com/wildfly/wildfly-core/pull/2122
To get a feeling how it works, checkout the branch, switch to e.g.
<version.io.undertow>1.4.8.Final-SRC-revision-1bff8c32f0eee986e83a7589ae95ebbc1d67d6bd</version.io.undertow>
(that happens to be the commit id of the 1.4.8.Final tag)
and build wildfly-core as usual with "mvn clean install". You'll see in
the build log that undertow is being cloned to ~/.m2/srcdeps/io/undertow
and that it is built there. After the build, check that the
1.4.8.Final-SRC-revision-1bff8c32f0eee986e83a7589ae95ebbc1d67d6bd
version of Undertow got installed to your local Maven repo (usually
~/m2/repository/io/undertow/undertow-core )
Are there any questions or comments?
[1] https://github.com/srcdeps/srcdeps-maven#srcdeps-maven
Thanks,
Peter
P.S.: I will be talking about srcdeps on Saturday 2017-01-28 at 14:30 at
DevConf Brno.
6 years, 11 months
Version notifications at library init
by David M. Lloyd
This is relatively minor but I've been sitting on it for a pretty long
time so I wanted to see if anyone had a strong opinion about it.
In the past few years, we've internationalized many of our projects, and
in the process assigned unique, searchable codes to exceptions and
INFO-and-higher log messages. In the meantime, as part of our existing
logging standards, we always log a version string for each library as it
is activated (this lets us quickly identify which versions of which
libraries are active, in order to aid in troubleshooting, etc.).
At present it is not part of our logging standard to assign a searchable
code to the version message. It has been suggested that we begin doing
so. If we did, I would recommend that the code be '0' for such messages
as most if not all of our projects use '1' as the lowest message ID.
The advantage of doing so is that it allows a given library's version
message to be quickly found in a log file, even if the language of the
log file is not known to the searcher. The disadvantage is that it
brings in additional noise to the log which makes it harder to read.
Does anyone have any strong feelings one way or the other, or better
yet, some pros or cons to add?
--
- DML
7 years
Could WildFly automatically detect Hibernate native applications and auto add Hibernate dependencies to the application classpath...
by Scott Marlow
Hibernate native applications that are deployed on WildFly, need the
application classpath to include org.hibernate:main + org.javassist:main
static modules. We proposed via WFLY-459 [1], that the Hibernate ORM
module should export the javassist module but that is not overrideable
by applications (since module exclusions are ignored for export=true
modules).
Another approach could be adding a (tattletale like?) deployment unit
processor to WildFly, that could scan through application classes,
without loading them, to check for references to certain Hibernate
classes, like "org.hibernate.Session". Would that introduce too much
overhead to deployment? If we did this scanning, we would have to scan
through all application classes to verify that the application doesn't
already depend on a Hibernate static module or include its own copy of
Hibernate classes.
Perhaps an alternative could be a wildflySomething.xml way to indicate
that a deployment is a Hibernate native application and that
Hibernate/Javassist dependencies should be auto added.
What do you think?
Scott
[1] https://issues.jboss.org/browse/WFLY-459
7 years, 1 month
How-to create Custom SessionManager and SessionConfig implementations?
by Eric B
I've been trying to figure out how to build my own custom SessionManager to
push my sessions into Redis with a custom SessionConfig implementation, but
am having trouble finding any documentation to that extent.
For the SesisonManager, I've read that I need to:
1. Develop SessionManager which implements io.undertow.server.session.
SessionManager
2. Develop SessionManagerFactory which implements
io.undertow.servlet.api.SessionManagerFactory
3. Develop startup extension which implements
io.undertow.servlet.ServletExtension,
and in handleDeployment(Deployment) method change sessionManagerFactory
with new SessionManagerFactory.
4. Register new ServletExtension by adding ../META-INF/services/io.
undertow.servlet.ServletExtension file (file should contain the name of
new ServletExtension. for example com.my.utils.StartupExtension)
But I can't seem to find anything that indicates how to provide my own
SessionConfig implementation. How do I register a custom SessionConfig
implementation? Is there any documentation to that extent?
Are there any examples that can show me how to create my own SessionManager
and SessionConfig object?
Thanks,
Eric
7 years, 1 month
a way to obtain local ModelController within javaagent?
by John Mazzitelli
OK, here's another one where I need some secret magical sauce - hoping someone knows of a technique I can use.
Suppose I have a javaagent installed in a WildFly server (using the standard -javaagent VM argument).
The javaagent would like to talk to the WildFly Server it is co-located with. Since it is in the same VM, the javaagent wants to avoid it looking like a remote call.
But I know of no way to obtain a local ModelController instance to build a client short of injecting some service or subsystem into WildFly itself (something I would like to avoid).
If the javaagent were instead a subsystem extension, it could do something like this:
InjectedValue<ModelController> mcValue = new InjectedValue<>();
...
((ServiceBuilder) bldr).addDependency(Services.JBOSS_SERVER_CONTROLLER, ModelController.class, mcValue);
...
WHAT_I_WANT = mcValue.getValue().createClient(...)
But obviously, that's no good for something running outside of the WildFly container (albeit in the same JVM).
Any hope at all? I was thinking some trickery on the order of what ByteMan does in order to figure out a way to obtain a local ModelController? But that's a last ditch effort :) Hoping there is something that uses a little less witchcraft.
7 years, 1 month
Latest WildFly Elytron Test Results - 2017-03-15
by Darran Lofthouse
After last nights merges we currently stand at 23 failures: -
https://ci.wildfly.org/viewLog.html?buildId=50650&buildTypeId=WF_MasterNe...
I am going to work on the 'RemotingLoginModuleTestCase' failures today
which will hopefully remove 4.
org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testDir
org.jboss.as.test.integration.naming.ldap.LdapUrlInSearchBaseTestCase.testLdap
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testNotAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleTestCase.testAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testNotAuthorizedClient
org.jboss.as.test.integration.security.loginmodules.RemotingLoginModuleUseNewClientCertTestCase.testAuthorizedClient
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnlyBeforeCompletion
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationSucceeded
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testRollbackOnly
org.jboss.as.test.iiop.transaction.TransactionIIOPInvocationTestCase.testSynchronizationFailed
org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful
org.jboss.as.test.clustering.cluster.dispatcher.CommandDispatcherTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.provider.ServiceProviderRegistrationTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.registry.RegistryTestCase(SYNC-tcp).test
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testGracefulShutdownConcurrentFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatelessFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testStatefulFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testSecureStatelessFailover
org.jboss.as.test.clustering.cluster.ejb.remote.RemoteFailoverTestCase(SYNC-tcp).testClientException
org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testRollbackOnlyBeforeCompletion
org.jboss.as.test.multinode.transaction.TransactionInvocationTestCase.testSynchronizationSucceeded
org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testServerToServerSFSBInvocation
org.jboss.as.test.multinode.remotecall.scoped.context.DynamicJNDIContextEJBInvocationTestCase.testSFSBPassivationWithScopedEJBProxyMemberInstances
7 years, 1 month
Accessing ssl/trusted store from a servlet
by Peter Nalyvayko
Hello,
Is there an way to programmatically access the truststore configuration
(the path to the store and the store password) defined by
security-realm/authentication/truststore XML element in standalone.xml from
a servlet?
Thanks!
--Peter
7 years, 1 month
how not to pass a JVM arg from host controller to spawned servers?
by John Mazzitelli
I noticed that whatever -D options you pass to the host controller (via HOST_CONTROLLER_JAVA_OPTS in domain.conf) by default also get passed along to all the servers that are spawned. If there is a specific system property that I do NOT want set in any spawned servers, how do I tell the host controller that?
I simply just want to tell the host controller "The system properties named "abc" and "xyz" are *your* system properties only - they are not for any of the spawned servers to get. The other system properties you can pass down to the spawned servers."
I'm hoping there is a way to do this without altering the host.xml definitions.
7 years, 1 month
Apache Portable Runtime (APR) in Wildfly
by Peter Nalyvayko
Hello,
Not sure if this is the right mailing list to post the question. Does
Wildfly support Apache Portable Runtime? I've found some old discussions
about configuring APR in JBoss Web/JBoss EAP that go a few years back, but
nothing as far as Wildfly/APR support goes. A reference to a section in
the documentation explicitly stating that such and such technology is not
supported is really what I am after.
Regards,
--Peter
7 years, 1 month
