Question on version of wildfly-protocol jars
by Rob Stryker
Hey all:
Here's a table of wf releases and what protocol jar version it has. I
was just curious if there was a discussion on this, and going backwards
in version was intentional? Is there anyone (customers, clients, etc)
out there likely to be confused by this? Or are we just considering it
internal details and not relevant?
Wildfly Release
wildfly-protocol jar version
8.0
wildfly-protocol-8.0.0.Final.jar
8.1
wildfly-protocol-8.1.0.Final.jar
9.0.CR1
wildfly-protocol-1.0.0.CR1.jar
EAP7 DR3
wildfly-protocol-2.0.0.Alpha3.jar
9 years, 5 months
Early Access builds for JDK 9 b66 and JDK 8u60 b18 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 8u60 b18 <http://jdk8.java.net/download.html>
is available on java.net, summary of changes are listed here.
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b18.html>
As we enter the later phases of development for JDK 8u60, please log any
show stoppers as soon as possible.
Early Access build for JDK 9 b66 <https://jdk9.java.net/download/> is
available on java.net, summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b66.html>.
The JDK 9 schedule of record is available on the JDK 9 Project page:
http://openjdk.java.net/projects/jdk9
At https://wiki.openjdk.java.net/display/Adoption/JDK+9+Outreach you can
find a (preliminary) list of other
changes that might affect your project's code in JDK 9, and other things
to consider when testing with JDK 9.
I'd be curious to know if there is anything on that list you'd consider
to have an effect on your project.
Please keep in mind that as JEPs and others changes are integrated into
(or out of) JDK 9, the list will change
over time.
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
9 years, 5 months
deploying module subsystem extension in wf-swarm
by John Mazzitelli
Is there an example of WildFly Swarm that (instead of deploying a WAR) deploys a module subsystem extension? Today, I have a subsystem that I deploy in WildFly's /modules and add it to standalone.xml via <extension> and <subsystem> and I was wondering how to take that and deploy it in WF-Swarm?
I see some things that are "close" (e.g. https://github.com/wildfly-swarm/example-datasource-subsystem ) but this isn't exactly it, at least it doesn't seem so. Unless I have to write my own subsystem's analogy to "DatasourcesFraction" and related classes?
I see when I build wf-swarm using the mvn plugin, my extension jar goes in "app" and all its dependencies go in m2repo. I see nothing that is analogous to standalone.xml (so I'm not sure how I configure my extension, which I normally do via the child elements under my <subsystem>).
So, if anyone has an example of doing something like this, let me know.
Thanks.
--John Mazz
9 years, 5 months
Question on frozen management client
by Rob Stryker
Hey All:
I've been trying to dig into this for a while but really haven't gotten
very far. Glance at https://issues.jboss.org/browse/JBIDE-19641
It seems our client (jbosstools) appears to have frozen while sending a
large war over mgmt api for deployment. Unfortunately, looking at the
stacks doesn't show anything strange. In fact, it seems the transfer is
still in effect. However, our user indicates that disk activity (ie
transfer) has ceased, and yet the client jar classes have not indicated
the transfer was done or aborted.
The class we use to perform the mgmt publish is
https://github.com/jbosstools/jbosstools-server/blob/master/as/plugins/or...
It's pretty simple, but QE is indicating it freezes and after a short
while, nothing happens.
I was wondering if anyone here might have any insight? QE indicates
the transfer works fine over jboss-cli, but not in jbt.
Thanks in advance.
- Rob Stryker
9 years, 5 months
Capabilities and Requirements - Common Definitions
by Darran Lofthouse
Following on from PR https://github.com/wildfly/wildfly-core/pull/757
and my final comment in the PR we need to have a discussion on how we
coordinate capability and requirement definitions - especially where
multiple components need a common definition.
The first option is to do it all by convention and have no shared
constants, the down side of this is we now need to document this and
keep the document maintained. A document would also make it hard in the
future to flag certain capabilities as deprecated if preferred
alternatives are made available.
The second option would be to just define the Strings somewhere and use
Javadoc to specify if the capability is dynamic and it's service type.
The third option is defining the string and RuntimeCapability instances
in a central place so they can both be referenced as needed.
Any other options?
Where these live will be a second point to discuss but that is heavily
driven based on what we will share in the first place.
Regards,
Darran Lofthouse.
9 years, 5 months
HTTP API support for plain JBoss-CLI commands
by Jairo Junior
I've been working on a Puppet Module for Wildfly [1] that uses his HTTP
Management API to perform operations (manage resources/deploys and execute
commands), but my command execution code is a little bit limited cause I
have to transform from CLI syntax to JSON. e.g.:
:shutdown(restart=true)
becomes
{"operation" : "shutdown", "restart" : "true" }
Is there any specific reason to not support plain CLI commands through HTTP
API? I looked at the code and it didn't see hard to implement this...
[1] https://github.com/biemond/biemond-wildfly
9 years, 5 months
10.0.0.Alpha2 released & 9 status update
by Jason Greene
Hello Everyone,
WildFly 10.0.0.Alpha2 and WildFly Core 2.0.0.Alpha3 are released.
As a reminder, we are doing bi-weekly alpha releases of full, and weekly of core. Due to the high frequency, I am currently not publishing them to the website, so that it does not clutter the WildFly download page.
I plan to redesign the download site in the coming weeks to better fit this new approach.
In the meantime, you can download the Alpha stream from maven:
https://repository.jboss.org/nexus/content/groups/developer/org/wildfly/w...
Next week we are hoping to release 9 CR2. The last blocker is an issue with IIOP shutdown (requires a Naryana update). If all goes well it will be the last CR.
Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
9 years, 5 months
Model attributes and default values
by Alessio Soldano
Hi,
QA has been testing various value transitions on the attributes in the
webservices subsystem of the model and found something unexpected for
attributes with default values. I had a look and found that when running
the following commands:
/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
reload
/subsystem=webservices:undefine-attribute(name=modify-wsdl-address)
for the last command the
WSServerConfigAttributeHandler#applyUpdateToRuntime method is passed
true as resolvedValue and undefined as currentValue. The resolvedValue
being true is because of the default value for that attribute being
true, but is it correct to get undefined as currentValue in that case?
Do I have to manually figure out there's a default value for the
attribute and hence decide nothing was changed if currentValue is
undefined and resolvedValue equals default value... or is there's a
specific way to deal with this scenario?
Thanks
Alessio
--
Alessio Soldano
Web Service Lead, JBoss
9 years, 5 months
Transaction subsystem dependencies
by Tristan Tarrant
Hi all,
I'm reworking the Infinispan Server package so that it is built around
WildFly Core as I want to keep it as lean as possible.
I need to pull in a couple of additional subsystems from WildFly proper
and one of them is causing some head-scratching: the transactions
subsystem. It has a bunch of hard dependencies on a ton of modules which
really sound optional. Examples:
- the IIOP stuff
- Narayana compensations (JAX-WS, JAX-RS, Servlet API, Weld)
- HornetQ
None of the above are really needed by Infinispan Server. I guess I
could apply manual surgery to the module.xml file to remove stuff I
think is unnecessary and let my testsuite verify if I'm being too
aggressive, but I was wondering whether it would be better for the
upstream project to be a bit more careful with the dependencies.
Thanks for any suggestions
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
9 years, 5 months
