arquillian-container-karaf-managed
by Steve Ebersole
Anyone know of tutorials or guides on
using arquillian-container-karaf-managed? Or willing to help me figure out
using that in hibernate-osgi tests?
9 years, 7 months
Call For Final Component Upgrades
by Jason Greene
If you haven’t already, please send in a PR updating your component to Final status, as we hope to release 9 Final this month.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 7 months
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, 7 months
Should management interfaces be in a subsystem?
by Darran Lofthouse
The reason this is coming up now is I am working on adding references to
Elytron services from the interfaces, also I know there is plenty of
demand for additional configuration options on these.
So the question is should the management interface definitions be a part
of a subsystem of their own or should they remain a top level?
My vote would be make them a part of a subsystem, my main justifications
being: -
- They are going to be dependent on capabilities supplied by other
subsystems.
- We already have non-optimal code in there to access subsystem
supplied services so can clean this up.
- In standalone mode they should not be strictly necessary, it should
be possible to remove all remote administration for standalone.
Even in the case of a slave host controller, if that host controller
pulls it's Elytron definition from the master it could also pull it's
management interface definitions from master.
Regards,
Darran Lofthouse.
9 years, 7 months
WFLY-1192 - Volunteering to work on this
by Brandon Gaisford
If no one is actively working on WFLY-1192, I’ll give it a go. Not sure how quickly I’ll be able to turn it around. Sources appear to be under wildly-core. Let me know if you’d like to me to work on this.
Thanks,
Brandon
9 years, 7 months
Java 8 API Warning
by Darran Lofthouse
Quick warning for anyone developing using Java 8 but on projects still
dependent on Java 7.
Normally this is fine, as an engineer you make sure you don't use any
new language features or call new APIs and generally it all works.
With Java 8 there is one addition gotcha, Java 8 adds support for
default method implementations on interfaces, to add to this some
pre-existing methods have now been replaced with default
implementations. The side effect being it is easy to miss that you have
a method missing from a class and it will not be picked up till it is
compiled on Java 7.
e.g. On java.util.Iterator the remove method is now default so classes
that implement this interface no longer need to implement that method
unless they really are providing an implementation of that method.
Regards,
Darran Lofthouse.
9 years, 7 months
Default resource adapter in Wildfly
by sridhar thiyagarajan
Hi,
I am migrating my application from JBoss 6 to Wildfly 8. MDB in my
application uses "jms-ra.rar" as resource adapter and the rar archive is
present in *server/deploy *directory of JBoss 6.
Can anyone help me about the default resource adapter in Wildfly that can
be used. There is a module *org.hornetq.ra* I observed and please anyone
explain about how to use the default resource adapter in Wildfly.
Many thanks in advance.
Sridhar Thiyagarajan
9 years, 7 months
EJB Client branch changes
by David M. Lloyd
The JBoss EJB Client project at GitHub [1] has undergone a couple of
administrative changes in anticipation of WildFly 10 development.
The 'master' branch, which was previously versioned at 2.1.x, is now for
3.x development. The 2.x development branch has been moved to the '2.x'
branch. Development of the 1.0.x series is still in the existing 1.0
branch and will remain there, as will the 2.0 branch for 2.0.x development.
The 3.x code is presently reasonably stable but it does rely on a
snapshot of JBoss Remoting 5.x at the moment.
The JIRA project [2] has been updated with a 3.0.0.Beta1 release.
[1] https://github.com/jbossas/jboss-ejb-client
[2] https://issues.jboss.org/browse/EJBCLIENT
--
- DML
9 years, 7 months