While investigating a jira (https://issues.jboss.org/browse/JBIDE-22141)
I tried to make a minimalist jboss-application xml, and it had a really
strange validation error:
cvc-complex-type.3.1: Value '7.0' of attribute 'version' of element
'jboss-app' is not valid with respect to the corresponding attribute
use. Attribute 'version' has a fixed value of '6'.
When I dug into the current jboss-app_7_0.xsd to see what was going on
I saw the following:
<!-- Import the Java EE6 xsd -->
<!-- Include the common JBoss EE elements -->
Shouldn't this be pulling from application_7.xsd at least? Also we
don't seem to have a jboss-common_7_0.xsd. So these version
inconsistancies are really angering the eclipse validator.
Is there anything that can be done here at all? It really seems our
schema have this recurring problem of not validating in eclipse, and
often times it seems the problems lead back to our very own schema as
the cause. It ends up causing errors in eclipse and our users get very
confused why all our example projects or snippets of xml on redhat
access often fail to validate.
- Rob Stryker
I'm having problems when using wildfly-maven-plugin with port-offset. If I specify pom.xml like below, server does start up, but shutsdown after a minute, because it was allegedly not started up (which is not true). When server-args are omitted, everything works. If it's like below, everything works as well, but only for a minute. Can you advice how correct port-offset usage looks like? Thanks.
I've be doing some tests with WF 10.
I've noticed that are some connections being established intra-process to
and from ephemeral ports. This is without having any application deployed.
C:\>netstat -nao | findstr 28692
TCP 127.0.0.1:8280 0.0.0.0:0 LISTENING 28692
TCP 127.0.0.1:10190 0.0.0.0:0 LISTENING 28692
TCP 127.0.0.1:64778 127.0.0.1:64779 ESTABLISHED 28692
TCP 127.0.0.1:64779 127.0.0.1:64778 ESTABLISHED 28692
TCP 127.0.0.1:64780 127.0.0.1:64781 ESTABLISHED 28692
TCP 127.0.0.1:64781 127.0.0.1:64780 ESTABLISHED 28692
TCP 127.0.0.1:64782 127.0.0.1:64783 ESTABLISHED 28692
TCP 127.0.0.1:64783 127.0.0.1:64782 ESTABLISHED 28692
TCP 127.0.0.1:64784 127.0.0.1:64785 ESTABLISHED 28692
TCP 127.0.0.1:64785 127.0.0.1:64784 ESTABLISHED 28692
TCP 127.0.0.1:64786 127.0.0.1:64787 ESTABLISHED 28692
TCP 127.0.0.1:64787 127.0.0.1:64786 ESTABLISHED 28692
TCP 127.0.0.1:64788 127.0.0.1:64789 ESTABLISHED 28692
TCP 127.0.0.1:64789 127.0.0.1:64788 ESTABLISHED 28692
TCP 127.0.0.1:64790 127.0.0.1:64791 ESTABLISHED 28692
TCP 127.0.0.1:64791 127.0.0.1:64790 ESTABLISHED 28692
TCP 127.0.0.1:64792 127.0.0.1:64793 ESTABLISHED 28692
TCP 127.0.0.1:64793 127.0.0.1:64792 ESTABLISHED 28692
Wildfly 10 final (just downloaded / no applications deployed / port
Windows 7 64bits
Can someone clarify why is this happening? Or provide some troubleshooting
Using WinCap I was able to identify the communication pattern:
Client Connects [SYN]
Server Ack [SYN, ACK]
Client Ack [ACK]
Client Push [PSH] - It pushes 8 bytes (e.g., in hex, e6202552f2b95f6f)
Optionally the server pushes some data periodically (always the same)
Server Push [PSH] - It pushes 1 bytes (in hex, 1)
I've reported a problem related with this in the user's forum, but I still
don't have a answer.
Luís M. Costa
w/ Java8 and the Stream API, there is parallelStream(), which is based on
the Fork-Join Pool. With JavaEE there a concurrency util, for managed
threads and executors. However, fork-join is imcompatible with those
managed threads, therefore I think (I hope I am not wrong here) it is NOT
recommended to use parallel streams in JavaEE.
Now, that WildFly-10 is Java8 and later I am wondering if there are plans
to support that; e.g. with a non-standard feature/flag which could enable
it, if desired. Sure that would cause issues regarding portablility, but
Just wondering if there are any thoughts around this, for WildFly 10 or 11
I just went through the binaries of JBoss AS-7.20 and found around 320+ jar files (dependencies) in the binaries. It is mentioned in the website that the dependencies are licensed under LGPL V2.1 license or a compatible license. Can you please provide me with the license conditions (other than LGPL V2. 1 license, maybe permissive ones if any) and copyrights for these jar files if possible so that evaluation of the component could be done? I have attach the list of jar files found in binaries along with this mail.
With best regards,
CT DD DS AA TEC CON-PR