Beta delayed for Batch (around a week)
by Jason Greene
Hi,
I just wanted to quick update everyone that we are delaying the Beta to get enough time for the Batch API to finish integration.
Thanks, and sorry for the inconvenience!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 2 months
ARQ container cannot fetch deployment from client side any more
by Thomas Diesler
Folks,
lately lots of wildfly integration tests fail because the ARQ service cannot fetch a deployment from the client side any more
java.lang.RuntimeException: Could not communicate with client side
at org.jboss.arquillian.protocol.jmx.JMXCommandService.execute(JMXCommandService.java:60)
at org.jboss.arquillian.container.test.impl.client.deployment.ContainerDeployer.getDeployment(ContainerDeployer.java:58)
would you know what causes this?
cheers
--thomas
11 years, 2 months
WFLY-261 & inconsistency in JDK code
by Bartosz Baranowski
Hey guys.
There seems to be inconsistency in GenericURLContext wrt how it handles lookup. This breaks lookups done from AS7/Wfly. Said lookup methods [1] & [2].
The wrongdoer is code in GenericURLContext(so this probably has impact on all URL contexts).
In case of argument like "rmi://127.0.0.1:1190/jmxrmi" there are two different results.
If [2] is invoked with above argument it works as expected. It goes down into getURLContext which parse URL part: "rmi://127.0.0.1:1190"
create proper stub( according to URL part ) and gives back ResolveResult.
After above, it nicely asks ResolveResult for context and "remainingName" [4] - in this case, its last bit of original URL: "jmxrmi". This call does not fail.
However if the [1] is used, it goes wrong. Lookup method calls "getContinuationContext" which strips part of URL and call lookup(String) with only "rmi:" [5].
This creates URL stub with default values( in case of RMI for instance ) since implementation assume that if there is no host:port pair, it sets
those values to localhost:1090(which may be different in URL).
This leads to [6] ( since context lookup on remainingName does not give result ). The suffix, which is argument of this call has three parts ["","127.0.0.1:1199","jmxrmi"].
Trick is that object on which [6] is invoked takes only first part of this name, which is empty string. Code which does that [7]. This results in exception which indicates
that URL is not accessible, while the lookup(String) will return valid object.
Initial stack trace for [1]:
rmiURLContext.getRootURLContext(String, Hashtable) line: 63
rmiURLContext(GenericURLContext).lookup(String) line: 200
rmiURLContext(GenericURLContext).getContinuationContext(Name) line: 192
rmiURLContext(GenericURLContext).lookup(Name) line: 213
InitialContext.lookup(Name, boolean) line: 112
Current wildfly code calls the lookup(Name) method[8], which will fail as described above. This PR [9] has testcase which reproduce problem.
Im not quite sure if we can wait for JDK fix( if ever ) since this piece of code is present in JDK7 and 6. Either this piece of code in WFLY remains as is, failing for non localhost:1090 or
there will be nasty Name.toString() in WFLY InitialContext impl( as in [9]).
Any thoughts on this?
[1] http://docs.oracle.com/javase/7/docs/api/javax/naming/InitialContext.html...
[2] http://docs.oracle.com/javase/7/docs/api/javax/naming/InitialContext.html...
[3] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-...
[4] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-...
[5] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-...
[6] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-...
[7] http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-...
[8] https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j...
[9] https://github.com/wildfly/wildfly/pull/4477
11 years, 2 months
Congratulations!
by Heiko Braun
Today we've had the 5000th pull request and the 2000th bug report.
Happy birthday wildfly.
11 years, 2 months
Re: [wildfly-dev] [jboss-as7-dev] WFLY-1396 - File upload/manipulation through management API - modules, config files
by Tomaž Cerar
This should be discussed on wildfly-dev mailing list....
----
In any case, this is useful feature that many people / projects could use.
I know that gatein team would love to have this to address their deployment
scenario in domain mode.
But given time constraints / features list for WF8 I cannot see this
happening before WF9/10
Unless someone sends PR with this implemented :-)
--
tomaz
On Tue, Sep 3, 2013 at 1:58 PM, Ondrej Zizka <ozizka(a)redhat.com> wrote:
> Hi everyone,
>
> I'd like to bring some attention to an issue which would greatly improve
> remote manageability of WildFly / EAP:
> https://issues.jboss.org/browse/WFLY-1396
>
> The thing is, for some management tasks, you need to have SSH access (or
> similar) in addition to management API - to upload e.g. modules or SSH
> related files.
> To make the server completely manageable through the API, one of the
> things needed is ability to upload files.
> Is there some progress on this? Is it planned?
>
> In the issue, there are some ideas how it could look. If you have a
> minute, please comment on the issue or here.
>
> Thanks,
> Ondra
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
11 years, 2 months
Re: [wildfly-dev] WildFly 8 Schedule
by Wesley,Justin J
Is there an updated release schedule? According to these dates, Beta1 should have come last month and Beta2 should arrive next week.
________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.
TRVDiscDefault::1201
11 years, 2 months
Smoothing the move from JDK 6 to 7
by David M. Lloyd
At this point in time, I'd say just about everyone wants to move ahead
with Java 7 syntax because let's face it: there's a lot of nice stuff in
there. But until now, doing so meant that projects which rely on
running on JDK 6 until the heat-death of the universe are on a fast road
to pain and suffering.
Well, all that ends today... introducing "seven2six" [1], a tiny tool
(only two source files) which losslessly converts version 51.0 (1.7)
class files to version 50.0 (1.6).
With this tool in your build, you can switch your language level to 1.7
without alienating your 1.6 users. I've already got this integrated
with JBoss Modules (it's quite simple to do as the README describes).
This could end Brian's major pet peeve of rooting out diamond operator
usage in new WildFly files, among other issues. I want to know what you
guys think of bringing this in to WildFly (maybe even in to
jboss-parent, honestly). The initial version is released to Maven
already at org.jboss.seven2six:seven2six:1.0.Final so feel free to mess
with it and suggest improvements (just use the GH bug tracker for now I
guess).
Thanks to Kabir Khan for the original idea and implementation/POC (I
just polished it up with ASM), and James Perkins for the Maven
integration code.
[1] https://github.com/dmlloyd/seven2six
--
- DML
11 years, 2 months
