JBoss Modules support
by Max Rydahl Andersen
Hey guys,
Just wanted to let you know that Rob Stryker added in support in our
eclipse tooling for grokking the new multi layered module+patching
system.
Thus unless you go changing this layout again we should be set for a
while.
But even possible more interesting for you to know is that we now
support setting up class path for your project that will honor
'Dependencies' in your manifest.mf file.
That means as long as you have a local wildfly install and use it as
target for your project we will pick up the binaries from that server
based on module id.
In short: you can start doing development against wildfly without having
to configure any maven, ant, gradle etc. It will just work :)
/max
http://about.me/maxandersen
8 years, 9 months
problem with JSF 2.2.7
by Frank Langelage
After upgrade of current sources from github including patch to JSF
2.2.7 I get this:
19.06. 00:05:14,934 ERROR [io.undertow.request#handleFirstRequest]
UT005023: Exception handling request to
/web-maj2e-langfr-dev/Login.xhtml: java.lang.RuntimeException:
java.lang.IllegalStateException
at
io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:182)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.ServletFormAuthenticationMechanism.servePage(ServletFormAuthenticationMechanism.java:85)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.FormAuthenticationMechanism.sendChallenge(FormAuthenticationMechanism.java:158)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2] at
io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:330)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl$ChallengeSender.transition(SecurityContextImpl.java:349)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl$ChallengeSender.access$300(SecurityContextImpl.java:314)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl.sendChallenges(SecurityContextImpl.java:135)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:109)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:114)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:54)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:27)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:243)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:230)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:149)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:195)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:733)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_60]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_60]
Caused by: java.lang.IllegalStateException
at
com.sun.faces.context.FacesContextImpl.assertNotReleased(FacesContextImpl.java:705)
[jsf-impl-2.2.7-jbossorg-1.jar:]
at
com.sun.faces.context.FacesContextImpl.getAttributes(FacesContextImpl.java:237)
[jsf-impl-2.2.7-jbossorg-1.jar:]
at
org.richfaces.context.ExtendedPartialViewContext.setInstance(ExtendedPartialViewContext.java:55)
[richfaces-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at
org.richfaces.context.ExtendedPartialViewContext.release(ExtendedPartialViewContext.java:64)
[richfaces-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at
org.richfaces.context.ExtendedPartialViewContextImpl.release(ExtendedPartialViewContextImpl.java:473)
[richfaces-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at
com.sun.faces.context.FacesContextImpl.release(FacesContextImpl.java:591) [jsf-impl-2.2.7-jbossorg-1.jar:]
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:665)
[jboss-jsf-api_2.2_spec-2.2.7.jar:2.2.7]
at
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
[undertow-core-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:232)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:175)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
at
io.undertow.servlet.spec.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:159)
[undertow-servlet-1.1.0.Beta2.jar:1.1.0.Beta2]
... 32 more
When adding
-Dversion.com.sun.faces=2.2.6-jbossorg-4
-Dversion.org.jboss.spec.javax.faces.jboss-jsf-api_2.2_spec=2.2.6
for build to get the the prior JSF-version, my web application works
without problems.
8 years, 9 months
First patch for the build split has been merged
by Stuart Douglas
Hi all,
The first patch of many for the build split has been merged. This
introduces a few changes, the most obvious of which is that the server
that is produced in the build dir is now a 'thin' server, that uses jars
directly from the local maven directory, and the full traditional server
is now built in the 'dist' directory.
Stuart
8 years, 9 months
Is there a way to avoid multiple singleton masters
by Michael Musgrove
I'd like to have an option of running our transaction recovery manager
as an HA singleton. WFLY-68 implies that the master can run at most once
(even in the presences of network partition) but I don't see how we can
guarantee that. If I hold the service start in a breakpoint then split
the network and then allow another master on the other side of the
partition to become master and then release the breakpoint we will
briefly have two services running. I know using breakpoints is invalid
but surely there are timing windows where the same outcome could
conceivably occur.
Mike
--
Michael Musgrove
Transactions Team
e: mmusgrov(a)redhat.com
t: +44 191 243 0870
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland)
8 years, 9 months
Handling history with the build split
by Stuart Douglas
Hi all,
So something we have been thinking about is how best to handle history
when doing the split, there were three obvious options that we looked at:
1) Copy the repo for each split, and just delete what is no longer needed.
This means that you have full history, however each repo is 130Mb+, so
once you have 4 or more repos you are looking at a very large amount of
data to checkout a full WF server, which will probably put off potential
contributors.
2) Clean break
Copy the files into a core repo, and just have a clean break, which
means that if you want to view history you will need to refer to the
original WF repo, which is not great (I know I use history and git
annotate a lot). This also means that it looks like the whole server was
added by one person in a single commit, which is not great.
3) git filter-branch
We use the filer branch command to filter out all non-relevant history.
This means most history is intact, however you do loose the full context
of the commit if it modified subsystems that have been moved into
separate repos.
It looks like it should be possible to append the old commit sha to the
message on a new line, which will make it easy to look up the old commit
if you need to see the full context.
The interesting thing is that options 2) and 3) can also be used with a
little known command called 'git replace' (which is basically a
replacement for grafts), to basically graft the full history over the
top of the truncated/rewritten history. Basically if you care about the
full history you will be able to run a script, and it will graft the
complete WF history into your repo, so any command that works with
history will show each commit in its entirety.
I think we should use option 3) combined with 'git replace'. This means
that the repo will be much smaller, and contain a rewritten version of
history that should be enough for most people. If anyone needs a full
history (e.g. when doing backporting) all that will be required is
running a simple script to replace the fake history with the real thing.
Comments?
Stuart
8 years, 9 months
Making RemoteConnectionFactory available in subsystem
by Dejan Kitic
Hi guys,
I am trying to figure out if it's possible to make HornetQ
RemoteConnectionFactory available within subsystem using something like:
final CastingInjector<ConnectionFactory> connFactInjector = new
CastingInjector<ConnectionFactory>(connFactInjector,
ConnectionFactory.class);
and then doing something like:
...
.addDependency(ConnectionFactoryService.SERVICE_NAME, connFactInjector)
within SubsystemAdd performRuntime.
Above is just thinking on the subject, the actual problem would be what to
put in the addDependency call for service name, and even how to specify
that I need to wait for the RemoteConnectionFactory to become available.
Might be completely off with this, so any help is appreciated.
Regards,
Dejan
8 years, 9 months
JMX Console over Web Admin Console
by Sebastian Łaskawiec
Hi
One of our projects is based on JBoss 5.1 and we are considering migrating
it to Wildfly. One of our problems is Web based JMX Console...
We have pretty complicated production environment and Web based JMX console
with basic Auth delegated to LDAP is the simplest solution for us.
I noticed that there was a ticket opened for porting legacy JMX Console:
https://issues.jboss.org/browse/WFLY-1197.
However I think it would be much better idea to to have this functionality
in Web Administraction console. In my opinion it would be great to have it
under "Runtime" in "Status" submenu.
What do you think about this idea?
Best Regards
--
Sebastian Łaskawiec
8 years, 9 months
Design Proposal: Log Viewer
by James R. Perkins
While there wasn't a huge talk about this at the Brno meeting I know
Heiko brought it up as part of the extended metrics. It's on some future
product road maps as well too. I figured I might as well bring it up
here and get opinions on it.
This design proposal covers how capturing log messages. The "viewer"
will likely be an operation that returns an object list of log record
details. The design of how a GUI view would look/work is beyond the
scope of this proposal.
There is currently an operation to view a log file. This has several
limitations. The file must be defined as a known file handler. There is
also no way to filter results, e.g. errors only. If per-deployment
logging is used, those log messages are not viewable as the files are
not accessible.
For the list of requirements I'm going to be lazy and just give the link
the wiki page https://community.jboss.org/wiki/LogViewerDesign.
Implementation:
1) There will be a new resource on the logging subsystem resource that
can be enabled or disabled, currently called log-collector. Probably
some attributes, but I'm not sure what will need to be configurable at
this point. This will likely act like a handler and be assignable only
to loggers and not the async-handler.
2) If a deployment uses per-deployment logging then a separate
log-collector will need to be added to the deployments log context
3) Logging profiles will also have their own log-collector.
4) The messages should be written asynchronously and to a file in some
kind of formatted structure. The structure will likely be JSON.
5) An operation to query the messages will need to be create. This
operation should allow the results to be filtered on various fields as
well as limit the data set returned and allow for a starting position.
6) All operations associated with view the log should use RBAC to
control the access.
7) Audit logs will eventually need to be viewable and queryable. This
might be separate from the logging subsystem as it is now, but it will
need to be done.
There are things like how long or how many records should we keep that
needs to be determined. This could possibly be configurable via
attributes on the resource.
This is about all I've got at this point. I'd appreciate any feedback.
--
James R. Perkins
JBoss by Red Hat
8 years, 9 months
