Code complexity survey
by Vard Antinyan
Dear wildfly developers,
We have undertaken a task to assess code complexity triggers and generate recommendations for developing simple and understandable code. Our intension is to share the results with you, developers, so everyone can learn the triggers behind complex software.
We need your help for rigorous results. My request to you is - if you get 5-10 min. time, would you please consider to answer the questions of this survey on code complexity?
https://goo.gl/forms/h9WXZ8VSEw7BUyHg1
You are welcome to learn preliminary results through this link:
https://www.facebook.com/SoftwareCodeQuality/photos/?tab=album&album_id=1...
The results will be shared in a public webpage and everyone possible will be invited to learn and discuss them.
Your knowledge and experience is vital for achieving substantial and generalizable results, and your effort is much appreciated!
Sincerely
Vard Antinyan
PhD candidate in University of Gothenburg, Sweden
Tel: 0046317725707
10 years
Early Access build 136 for JDK 9 & JDK 9 with Project Jigsaw are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access b136 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+136.html>.
Early Access b136 <https://jdk9.java.net/jigsaw/> (#5506) for JDK 9 with
Project Jigsaw is available on java.net, summary of changes are listed
here
<http://www.java.net/download/java/jigsaw/archive/136/binaries/jdk-9+136.html>.
There have been a number of fixes to bugs reported by Open Source
projects since the last availability email :
* 8165723 - b136 - core-libs JarFile::isMultiRelease() method returns
false when it should return true
* 8165116 - b136 - xml redirect function is not allowed even with
enableExtensionFunctions
NOTE:- Build 135 included a fix for JDK-8161016 which *has introduced a
behavioral change to HttpURLConnection, more info:*
The behavior of HttpURLConnection when using a ProxySelector has been
modified with this JDK release. Currently, HttpURLConnection.connect()
call would fallback to a DIRECT connection attempt if the configured
proxy/proxies failed to make a connection. This release introduces a
change whereby no DIRECT connection will be attempted in such a
scenario. Instead, the HttpURLConnection.connect() method will fail and
throw an IOException which occurred from the last proxy tested. This
behavior now matches with the HTTP connections made by popular web
browsers. But this change will bring compatibility issues for the
applications expecting a DIRECT connection when a proxy server is down
or when wrong proxies are provided.
*
JDK 9 Outreach Survey*
In order to encourage and receive additional feedback from developers
testing their applications with JDK 9,
the OpenJDK Quality Outreach effort has put together a very brief survey
about your experiences with JDK 9 so far.
It is available at***https://www.surveymonkey.de/r/JDK9EA*
We would love to hear feedback from you!
Rgds,Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 1 month
Re: [wildfly-dev] Proposing capabiities at completion time
by Brian Stansberry
I’m adding wildfly-dev in cc.
Yes, the names of the parameters are ambiguous. And it’s not necessary for them to be ambiguous, as the “alternatives”, “required” and “requires" stuff lets us use clearly named params for different cases:
“attribute” — required=true, alternatives=[parameter]
“parameter - required=true, alternatives=[attribute], requires=[operation]
“operation” - required=false
An alternative is we could just drop all of those. The operation and attribute params are not necessary if the client has already done a read-resource-description or read-operation-description and already knows the value of the “capability-reference” descriptor. Then it could simply be
/core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],static-name=org.wildfly.network.socket-binding)
{
“outcome” => “success”,
“result” => [
“http”,
“https”
]
}
When thinking about this we should remember the dot/bracket syntax we allow for updating details of complex attributes via write-attribute:
:write-attribute(name=complex.nested[2].field,value=http)
For the CLI, just passing through “attribute”=>"complex.nested[2].field” is easier as there is no need for it to unpack the ‘.’ and ‘[]' syntax and find the description of ‘field’ and get the capabiity-reference.
For the console, it may be easier to get the capability-reference and pass it instead. Easier than going from some code backing a gui widget and synthesizing "complex.nested[2].field” to pass to the server.
> On Sep 15, 2016, at 6:40 AM, Jean-Francois Denise <jdenise(a)redhat.com> wrote:
>
> The operation argument is an optional argument that contains the resource operation name. In case the operation is present, the attribute argument means operation argument. Otherwise the attribute contains the name of an attribute. This is a draft of operation, the operation naming could be reviewed.
> I don't think that this operation updates the capabilities registry, this is a readonly operation to retrieve capabilities.
> JF
>
> On 15/09/16 12:41, Harald Pehl wrote:
>> That looks very promising. Having such an operation would also cover the requirements of HAL. What's behind the "operation" parameter? Does it allow add / modify?
>>
>> On Thu, Sep 15, 2016 at 12:04 PM, Jean-Francois Denise <jdenise(a)redhat.com> wrote:
>> Hi,
>>
>> I have spent some time looking at the semantic of the capability scopes (thanks to Brian help).
>> A client "could" try to base its capability resolution by looking at capabilities present in the capabilities registry. Scope can be very complex, are possibly not fully modeled yet, and semantic could evolve in the future. So difficult for a client to rely on scopes to resolve the accessible capabilities.
>>
>> The server side has the logic to check the capabilities and could expose part of its engine logic to clients for capabilities resolution. Brian is proposing that the capabilities registry would expose a new operation:
>> /core-service=capability-registry:suggest-capabilities(address=[(subsystem=foo),(child=bar)],operation=add,
>> attribute=socket-binding)
>> {
>> “outcome” => “success”,
>> “result” => [
>> “http”,
>> “https”
>> ]
>> }
>>
>> It seems that the CLI "completion requirements" would be covered by this addition. I am wandering if it would also cover the HAL ones?
>>
>> Thanks.
>>
>> JF
>>
>>
>> On 13/09/16 21:50, Harald Pehl wrote:
>>> See my answers inline.
>>> On Tue, Sep 13, 2016 at 12:04 PM, Jean-Francois Denise <jdenise(a)redhat.com> wrote:
>>> Hi Claudio and Harald, thank you for your reply. Some questions in-lined. I am just discovering the capabilities topic ;-) On 12/09/16 19:47, Claudio Miranda wrote:
>>> Your suggested approach looks similar to the way HAL does, however there are some differences. 1) There are many attributes that doesn't declare the capability-reference, (example: subsystem=transactions, attribute jdbc-store-datasource), then we emulate it.
>>> How do you emulate this? You are hard coding the list of attributes that are reference to capabilities? You can point me to some code? Harald, what is the technical difficulty there? Are they real capabilities? If the referenced resource can't register capabilities, are they actual capabilities?
>>> We have an internal registry [1] which is basically a map with the capability name as key and a class holding information about the capability as value [2]. Most entries in our registry are taken from /core-service=capability-registry, but to provide the capabilities also for WildFly < 11, we need to manually add entries to our registry during startup [3].
>>>
>>> 2) The capabilities and addresses are associated at bootstrap, this way HAL associates all capability-reference names to the target address it should lookup on at runtime. https://github.com/hal/core/blob/26bb90653f60cfad2f3c3aac5964c4f125e18777...
>>> This is the information that the capabilities registry contains? Right? I should be able to retrieve all that from the registry?
>>> Yes we read everything from /core-service=capability-registry
>>> 3) For domain mode, the attributes that declares capabilities resources out of profile, as socket-bindings, there is a small inconvenient, we need to display the full resource address, as there is no way to associate the profile to the socket-binding, we need to show all socket-binding of all socket-binding-groups, see http://i.imgur.com/86VP1F9.png
>>> The /<profile>/subsystem=transactions/process-id-socket-binding should be tagged with "capability-reference". Right? And it doesn't seem to be. Do you now the rational?
>>> Right, the r-r-d result for /<profile>/subsystem=transactions does not contain a "capabilities-reference" for the attribute "process-id-socket-binding". This seems to be a bug in the transactions subsystem. But actually it's a good example how we can still provide typeahead support for attributes which do not have a "capability-reference" info [4]. This does not involve the capabilities registry. It's just about adding typeahead support for attributes which reference some other resources, but do not yet have a "capabilities-reference"
>>> Once the user has chosen a value, what are you setting as the value for the process-id-socket-binding attribute? Harald, you are saying that the resource name is taken as form input. So it means that only the last part of the resource address is stored? For example only "ajp"? Is it enough to fully identify the actual resource? Don't you need (full capabilities name + scope)?
>>> Yes that's right, only the resource name is stored. Let's take the server-group resource as an example. It has the attribute "profile" which declares the "capability-reference" "org.wildfly.domain.profile". When adding the resource, only the profile name is stored. AIUI to identify / verify the profile the attribute value and the information from the capabilities-regisrty are used.
>>>
>>> Thank-you.
>>> [1] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss...
>>> [2] https://github.com/hal/hal.next/blob/develop/meta/src/main/java/org/jboss...
>>> [3] https://github.com/hal/hal.next/blob/develop/app/src/main/java/org/jboss/...
>>> [4] https://github.com/hal/hal.next/blob/develop/app/src/main/resources/org/j...
>>> --- Harald Pehl JBoss by Red Hat http://hpehl.info
>> --
>> --- Harald Pehl JBoss by Red Hat http://hpehl.info
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
10 years, 1 month
Subsystems changing their own configuration model
by Tristan Tarrant
We would like to allow a subsystem to modify its configuration model by
itself at runtime. The use case for this is that we would like to let a
remote Hot Rod client create a cache on an Infinispan server and making
that configuration persistent across restarts. I understand this is
creating management ops which are orthogonal to the server's.
I guess that in standalone mode this wouldn't be too much of an issue,
with two caveats:
- all nodes in a cluster should apply the changes to their own
configuration, leveraging the model rollback mechanism to handle
failures on other nodes
- new nodes joining the cluster (and therefore with a possibly outdated
configuration) would receive the configuration of caches already running
in the cluster and applying them locally
The real tricky bit is obviously domain mode. The server receiving the
cache creation request would need to delegate it to the DC who would
then apply it across the profile. However this clashes with the fact
that, as far as I know, there is no way for a server to communicate with
its DC. Is this type of functionality planned ?
I have created a document which describes what we'd like to do at [1]
Tristan
[1] https://github.com/infinispan/infinispan/wiki/Create-Cache-over-HotRod
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 1 month
question 2 sec boot time of WISE
by Rebecca Searls
Wise was pulled from wfly because it was adding 2 sec to boot time.
Wise is a utility with a GWT interface. It was added to wfly as an extension.
It is provided as a WAR file.
Is there any more detail of the boot of this app?
Here are a few options we have thought of.
What would be the best way to address this so that the user can have access to this tool?
1. lazy deployment of the utility
2. Only provide it in standalone-full.xml
3. Handle it the way xts subsystem was with a standalone-xts conf
10 years, 1 month
WildFly's transaction subsystem needs a diet (too much Artemis!)
by Tristan Tarrant
Hi all,
ever since wildfly-core was conceived I've wanted to deliver an
Infinispan Server distribution based on it using a feature-pack.
Unfortunately this has not been possible because we depend on two
subsystems which are not part of core: datasource and transactions.
Our current approach, therefore, implements a feature pack based on the
full wildfly. We then use some scripts to build a tree of module
dependencies, we identify unused modules and we trim them from the final
distribution.
Unfortunately this trimming is not effective as it could be because of
the org.jboss.as.transactions module which pulls in a ton of
nono-optional dependencies. You can find the dependency tree at the end
of this e-mail.
In particular the culprit seems to be org.jboss.jts which depends on
org.apache.activemq.artemis which in turn is a kitchen-sink of artemis-*
dependencies. [1]
I guess Narayana is only really interested in Artemis' journal, so the
laziness of the artemis module is particularly painful.
Can the artemis-journal/artemis-native jars be split out into their own
independent module ? This might be harder than it seems as the journal
classes seem to depend on artemis-server, so deeper surgery is needed.
Tristan
[1]
https://github.com/wildfly/wildfly/blob/master/feature-pack/src/main/reso...
org.jboss.as.transactions
org.jboss.jboss-transaction-spi
javax.resource.api
org.jboss.jts
org.omg.api
javax.orb.api
org.wildfly.iiop-openjdk
org.jboss.metadata.ejb
org.jboss.jts.integration
org.jboss.iiop-client
javax.ejb.api
javax.xml.rpc.api
javax.xml.soap.api
javax.rmi.api
org.apache.activemq.artemis
com.google.guava
javax.jms.api
org.apache.commons.beanutils
org.wildfly.extension.messaging-activemq
org.apache.activemq.artemis.ra
org.jboss.as.cli
org.jboss.aesh
org.fusesource.jansi
org.wildfly.embedded
org.jboss.as.weld
ch.qos.cal10n
javax.persistence.api
org.hibernate.validator.cdi
org.hibernate.validator
com.fasterxml.classmate
org.jboss.weld.core
org.jboss.weld.api
org.jboss.weld.spi
org.jsoup
org.wildfly.extension.bean-validation
org.jboss.as.ejb3
org.hibernate
org.wildfly.clustering.api
org.wildfly.clustering.ee.spi
org.wildfly.clustering.ejb.spi
org.jboss.ejb-client
org.wildfly.clustering.service
org.wildfly.clustering.marshalling.api
org.wildfly.clustering.marshalling.jboss
org.wildfly.clustering.spi
org.wildfly.clustering.ejb.infinispan
org.wildfly.clustering.ee.infinispan
org.wildfly.clustering.infinispan.spi
org.wildfly.clustering.server
org.wildfly.clustering.jgroups.spi
org.wildfly.clustering.jgroups.api
org.wildfly.clustering.singleton
org.wildfly.clustering.web.infinispan
net.jcip
org.wildfly.clustering.web.api
org.wildfly.clustering.web.spi
org.jboss.as.connector
org.jboss.ironjacamar.api
org.jboss.ironjacamar.impl
org.jboss.ironjacamar.jdbcadapters
org.jboss.ejb3
org.jboss.as.webservices.server.integration
asm.asm
javax.jws.api
javax.wsdl4j.api
javax.xml.ws.api
org.jboss.as.webservices
com.sun.xml.messaging.saaj
org.apache.ws.security
org.apache.neethi
org.opensaml
org.bouncycastle
org.jboss.xts
org.jboss.narayana.compensations
org.jboss.narayana.txframework
org.slf4j.ext
org.hornetq.client
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years, 1 month
Re: [wildfly-dev] Fixing handling of 'required' attributes with 'alternatives'
by Brian Stansberry
> On Sep 12, 2016, at 7:44 AM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
>
> On 6 Sep 2016, at 15:10, Brian Stansberry wrote:
>
>> It’s not an uncommon thing to have a management attribute A that is required; i.e. must be set, but also has an alternative attribute B, where setting B satisfies the requirement for A, making an undefined value for A legal.
>
> Would this also include cases where e.g. a logger has an
> attribute 'mode' which could be one of file, console, rsyslog
> and then dependent attributes that are only usable with
> one of the modes. Something like filename for 'file',
> none for 'console' and 'remote-socket-binding' for 'rsyslog' ?
> Both 'filename' and 'remote-socket-binding' would be
> required only for their mode (and even forbidden otherwise).
No, that kind of thing is not covered by this work. We have ‘requires’ metadata for an attribute that names other attributes that must be set if the given attribute is set, but that’s just a relationship based on defined vs undefined, not on any particular defined value. There would need to be some sort of new metadata added to cover what you describe. Perhaps something like
“requires-if => [
{
“value” => true,
“attributes” => [“another”, “athird”]
},
{
“value” => false,
“attributes” => [“afourth”, “afifth”]
},
]
Note that for something like that we couldn’t support it for attributes that allow expressions, as the validation of the constraint would need to happen before we’re able to accurately resolve expressions. But for enum attributes like your example I don’t think that would be an issue. I don’t imagine using an expression to control an enum would be a typical thing.
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
10 years, 1 month
Early Access builds of JDK 9 b134 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access b134 <https://jdk9.java.net/download/> for JDK 9 is
available on java.net, summary of changes are listed here
<http://www.java.net/download/java/jdk9/changes/jdk-9+134.html>.
There have been a number of fixes , since the last availability email
, to bugs reported by Open Source projects :
* 8156841 sun.security.pkcs11.SunPKCS11 poller thread retains a
strong reference to the context class loader
* 8146961 Fix PermGen memory leaks caused by static final Exceptions
* 8163353 NPE in ConcurrentHashMap.removeAll()
* 8160328 ClassCastException: sun.awt.image.BufImgSurfaceData cannot
be cast to sun.java2d.xr.XRSurfaceData after xrandr change output
Secondly, there are a number of interesting items to bring to our attention
* JDK 9 Rampdown Phase 1: Process proposal [1]
* The Java team has published the “Oracle JRE and JDK Cryptographic
Roadmap” [2] java.com/cryptoroadmap <http://java.com/cryptoroadmap>
* The Quality Report for September 2016 is now available [3], thank
you for your continued support!
Highlights from the Quality Report for September :
* 21 new Open Source projects have joined the Outreach program
* Projects filed 35 new issues in the JDK Bug System, this is almost
double the number of bugs in the previous six months!
* Continuing to provide excellent feedback via the OpenJDK dev mailing
lists
Thank you!
Rgds,Rory
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html
[2] java.com/cryptoroadmap <http://java.com/cryptoroadmap>
[3]
https://wiki.openjdk.java.net/display/quality/Quality+Outreach+Report+Sep...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years, 1 month
