Proposal for improving handling complex types in CLI
by Tomaž Cerar
Hi guys,
there ware some discussions on how we should improve handling complex types
of attribute bit better in CLI.
For most part that was about Map & List types.
After some discussions with few of you I came up with plan / ideas what all
options are there for us to improve on.
you can see current state of proposed enhancements at
https://gist.github.com/ctomc/91055a6f4e7502dcd130
In short, I propose to add set of map-* and list-* global operations and
improve :read-attribute & :write-attribute
with EL like syntax for reading / updating map, list and generic complex
attributes.
Let me know what you think about it, especially Console & CLI folks.
--
tomaz
9 years, 10 months
Heads up on JBoss Logger 3.2 : more changed than what it looks like
by Sanne Grinovero
Hi all,
today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
in an Hibernate project, and got some integration test failures.
The surprising aspect is that everything seemed fine at compile level:
just switch the version in the pom, and without needing any further
changes it compiles fine and runs all unit tests successfully.. but
fails when using the freshly built libraries in WildFly 8.2.
It's not a regression of jboss-logging, but one of its improvements
require a bit of attention.
This is what happened to us:
we have some log statements which look like this in source code (after
simplifying):
int i = ...
log.debugf( "Number: %d", i );
This does of course compile fine in both old an new versions of JBoss
Logger. And it all works as expected in unit tests.
But when deploying the modified version of this Hibernate library in
WildFly 8.2, you'd get some of these:
- java.lang.NoSuchMethodError:
org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
When using the older version of JBoss Logger (at compile time), the
above line of code is compiled as an invocation to:
void debugf(String format, Object param1);
(which is a method present in both versions)
When using the new version of JBoss Logger (at compile time), the same
line of code is interpreted as the (better) invocation to:
void debugf(String format, int arg);
So that's what the library is going to invoke at runtime - and that
method doesn't exist in WildFly 8.2.
Be aware of this when upgrading as it might look like a trivial
version bump but it makes it quite hard to guarantee backwards
compatibility with older versions of the logger.
Personally since I want to upgrade the logger but don't want to drop
compatibility with existing WildFly releases, I'm trying to figure how
to reliably validate that no logging statement is going to invoke one
of the new ones.. for now.
I guess this also means that users won't actually benefit from the
better performance of the new logging methods until we recompile all
of its client libraries using the new version ;-)
Auto-boxing is evil..
Sanne
10 years
Early Access builds for JDK 9 b51 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 9 b51 <https://jdk9.java.net/download/>
available on java.net, summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b51.html>
I'd also like to use this opportunity to point you to JEP 238:
Multi-Version JAR Files [0],
which is currently a Candidate JEP for JDK 9.
It's goal is to extend the JAR file format to allow multiple, JDK
release-specific versions of class
files to coexist in a single file. An additional goal is to backport the
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing list. [1]
Please keep in mind that a JEP in the Candidate state is merely an idea
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment that
it will be delivered in
any particular release.
Comments, questions, and suggestions are welcome on the corelibs-dev
mailing list. (If you
haven’t already subscribed to that list then please do so first,
otherwise your message will be
discarded as spam.)
Rgds,Rory
[0] http://openjdk.java.net/jeps/238
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years
WildFly CI processing moved to Java 8
by Tomaž Cerar
Hi folks,
Pull processing for WildFly and WildFly core was just moved to JDK 8.
This was done as part of effort allow testing also java 8 features as part
of testsuite.
PR https://github.com/wildfly/wildfly/pull/7183 adds "java8" integration
testsuite module.
This module uses java 8 as source & target where all tests utilizing java8
features should be added.
WildFly source level is still at 7 with exception of this new module ^^
Master & Master-ignore jobs on brontes will still use JDK7 for running
to make sure no JDK8 APIs slip into code base by mistake.
--
tomaz
10 years
ConcurrentAccessTimeoutException with JBPM demo
by Gandikota, Murthy
Hi All
I am trying to run the JBPM2 demo on WildFly using "ant start.demo" and getting a bunch of errors :
2015-02-25 12:38:03,365 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 2) JBAS014134: EJB Invocation failed on component SimpleAsyncExecutorService for method public void org.uberfire.commons.async.SimpleAsyncExecutorService.execute(java.lang.Runnable): javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@5af21532 - could not obtain lock within 5000MILLISECONDS
2015-02-25 12:38:03,532 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component SimpleAsyncExecutorService for method public void org.uberfire.commons.async.SimpleAsyncExecutorService.execute(java.lang.Runnable): javax.ejb.ConcurrentAccessTimeoutException: JBAS014373: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on org.jboss.invocation.InterceptorContext$Invocation@114dac71 - could not obtain lock within 5000MILLISECONDS
10 years
JBoss AS 7 - JDK8 compatibility
by Michael Bilalis
Hello,
We have some existing legacy app-server running JBoss AS 7 and I would like to know if AS 7 is JDK8 compatible or are there some issues with it ?
Kind Regards
Michael
10 years
Batch Deployments
by James R. Perkins
I'm working on allowing batch jobs to be viewed in the management model
and I'm running into some issues.
Batch jobs require a XML file to start. Per the batch spec that the XML
files can be found outside of the archive, for example somewhere on the
file system. If the job XML isn't found there it looks in the
META-INF/batch-jobs directory for the job XML.
Batch repositories are global for all applications. All deployments can
see all other deployments job status and query information about the
jobs. They can't start or restart jobs for other deployments, but
they're viewable.
Here lies the problem. It seems batch jobs, at least from the management
view, should be limited to the deployment the job was run on. I'm
considering only allowing job XML files in the META-INF/batch-jobs to be
viewable via management. Though there is still a chance two different
deployments could use the same job name (the name of the job XML file)
which would show the jobs run by the two different deployments with the
same job name.
I can't think of another way to isolate jobs from the repository to link
to a deployment. If anyone else has any ideas let me know. There is no
spec for the repository so we can do whatever we want really.
--
James R. Perkins
JBoss by Red Hat
10 years
timer service for extension modules?
by Carl Harris
My extension module creates a (MSC) service that needs to get periodic timer callbacks to clean up cruft that accumulates while it is being used by a deployed application. I could create a java.util.Timer when the service is created and cancel it when the service is removed, but I’m wondering of there already a timer service that I should be using for this sort of thing.
Thanks for any tips or guidance,
carl
10 years
