Change CLI to Default to Remoting
by Darran Lofthouse
Hello all,
I am currently working on the following issue: -
https://issues.jboss.org/browse/WFLY-1664
Recent changes to the CLI mean that it is assuming unless told otherwise
that a HTTP Upgrade is going to be used when connecting to the server,
this means that command already used in scripts to connect to servers
are going to fail unless the scheme is included in the URI.
I chatted with David to see if there were any options to auto detect
this and fall back to pure Remoting if the remote side of the connection
is pure Remoting - however of the two options available they were both
fairly hacky or unreliable.
So the alternative is to drop the CLI back to assuming a pure Remoting
connection unless told otherwise.
- Calling connect or starting with -c will still use http-remoting
against the local server as that is defined in the jboss-cli.xml
- Calling connect or --controller with a host and port will assume
connecting directly to remoting.
- Users wanting HTTP upgrade to other servers will need to specify
http-remoting or https-remoting as the scheme when specifying the remote
address.
One other idea that I have had for the CLI if end users do want the
parameter to the connect command to be as short as possible is to add
multiple host aliases to the jboss-cli.xml - that way the protocol host
and port can be specified in the config and the alias passed to the
connect command. Additionally this would allow us to place different
SSL configuration against each host but.
Regards,
Darran Lofthouse.
11 years
Reading Logs from Web Console
by James R. Perkins
I had posted this to another list, but this is a more appropriate place
for it. I think there needs to be a general discussion around this as
it's been mentioned, at least to me, a few times here and there and I
know Heiko raised the issue some time a go now.
The original JIRA, WFLY-280[1], is to display the last 10 error messages
only. To be honest I wouldn't find that very useful. To me if I'm
looking for logs I want to see all logs, but that's not always so easy.
Like the syslog-handler which doesn't log to a file so there is no way
to read those messages back.
The current plan for the last 10 error messages is we store messages in
a queue that can be accessed via an operation. This works fine until the
error message you're interested in is 11 or you want to see warning
messages.
Another option I had come up with is reading back the contents of the
file, for example the server.log. This could be problematic too in that
there is no way to filter information like only see error messages or
only see warning messages. To solve this I have considered creating a
JSON formatter so the results could be queried, but I don't think it
should be a default which would mean it's not reliable for the console
to assume it's getting back JSON.
I've also thought about, haven't tested this and it may not work at all,
creating a handler that uses websockets to send messages. I'm not sure
how well this would work and it's possible it may not even work for
bootstrap logging.
With regards to audit logging, we're probably going to have to do
something totally different from what we'll do in the logging subsystem
since it doesn't use standard logging.
I guess the bottom line is what does the console want to see? Do you
want to see all raw text log messages? Do you want all messages but in a
format like JSON that you can query/filter? Do you really want only the
last 10 error messages only? All or none of these might be possible, but
I really need to understand the needs before I can explore more in depth
what the best option would be.
[1]: https://issues.jboss.org/browse/WFLY-280
--
James R. Perkins
Red Hat JBoss Middleware
11 years, 1 month
wildfly 8 client library now requires Java 7 ?
by Max Rydahl Andersen
I bumped into this error while trying out wildfly 8.
An internal error occurred during: "Starting wildfly-8.0.0.Alpha4".
org/jboss/as/controller/client/helpers/standalone/DeploymentPlanBuilder : Unsupported major.minor version 51.0
Seems like the client library we use to control present and past servers now require Java 7.
Is this expected ?
We can go back using older libraries for JBoss AS 7/EAP 6 and would have to mark that you can't actually talk with
Wildfly 8 libraries without Java 7 - but before doing that I wanted to check if this is expected or not?
Thanks,
/max
11 years, 1 month
Patching WSDL4J (or perhaps forking?)
by Alessio Soldano
Folks,
when running the jbossws testsuite against WFLY master with security
manager enabled, I've noticed that the following permission is required
to build up JAXWS clients (actually to be able to parse any WSDL):
<permission class="java.io.FilePermission"
name="/usr/java/jdk1.7.0_17/jre/lib/wsdl.properties" actions="read"/>
That's basically a non existing file in my java.home. The reason is in
WSDL4J, which seems to be missing a SecurityException catch block in
javax.wsdl.factory.WSDLFactory#findFactoryImplName().
I thought about reporting the issue, but afaics the project "lives" at
sourceforge.net (on cvs scm...) and, more important, since Oct 2011
there's already a patch proposal [1] for the issue which has never been
commented / considered.
How should we move forward here? Suggestions / proposals? Anybody here
is in the JSR-110 EG and can get in touch with the WSDL4J devs?
Alessio
[1] http://sourceforge.net/p/wsdl4j/patches/1/
--
Alessio Soldano
Web Service Lead, JBoss
11 years, 1 month
Re: [wildfly-dev] Merge Commits
by Jason Greene
Which tools?
On Sep 30, 2013, at 9:19 AM, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> Merge over rebase of course messes up many history tools.
>
> I actually asked of GitHub support for the ability to rebase pull requests through the UI in much the same way we can merge already. I cannm let you know if/when i hear back.
>
>
> On Mon 30 Sep 2013 09:15:39 AM CDT, Jason Greene wrote:
>>
>> On Sep 30, 2013, at 5:03 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com> wrote:
>>
>>> Hello all,
>>>
>>> Is it intentional we have switched to 'Merge' commits for pull requests?
>>
>> I'm exploring them as a way to speed up our merge process and provide better auditing. No decision yet.
>>
>>>
>>> e.g.
>>>
>>> https://github.com/wildfly/wildfly/commit/97ce5300f4277be023a112531b00dfa...
>>>
>>> Jason it is going to look like you have authored everything and in the
>>> future using annotate or browsing the history it is going to be more
>>> complex to identify why previous lines of code were written ;-)
>>
>> That's not true. A merge commit links to the original author history. Github just displays the delta to be friendly. Git annotate also will show the original author sha1 and not the merge sha1.
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
11 years, 1 month
EE level java:comp/DefaultDataSource for WildFly 8...
by Scott Marlow
Hi,
Lincoln was just asking why WildFly 8 doesn't yet have a
java:comp/DefaultDataSource that is talked about in EE.5.20 and [1].
Lincoln created WFLY-2027 for the JPA part of EE.5.20 (if we add support
for a default datasource in WildFly 8.)
I'm kind of caught on this requirement, since we already have a JPA
level default datasource setting (for JPA container deployment). I need
to know if we are going to add a default datasource
(java:comp/DefaultDataSource) setting to WildFly, so I can align with that.
Steve Ebersole, already offered to add a Hibernate ORM way [2] for this
(defaultDatasource) change to not break OGM, which we would need to use
in WildFly 8 (or WF 9) and JipiJapa. Since we are talking about going
to Beta with WildFly 8, I assume this change is too late, but then
again, it sounds like its expected for EE 7 ;)
Scott
[1] https://blogs.oracle.com/arungupta/entry/default_datasource_in_java_ee
[2] https://gist.github.com/scottmarlow/6497927
11 years, 1 month
Has Undertow changed the way it processes Link headers
by Michael Musgrove
The BlackTie (an XATMI implementation) software uses the REST interface
to JBoss transactions and sends HTTP requests down a plain C socket.
Around about the time undertow was upgraded to Beta13
(https://github.com/wildfly/wildfly/commit/8feb7d7d86e2a9619dbf7997b22d163...
- just over a week ago) the Link header is no longer being passed to our
Resteasy transaction coordinator (the header is coming through as null).
I was wondering if anyone is aware of a recent change that may have
caused this change.
I get the same behaviour if I use cURL to send the header.
Note that it works fine if I send Link headers using
java.net.HttpURLConnection.
Mike
11 years, 1 month
WFLY-1786
by Frank Langelage
It would be very nice if someone (Jason or someone else) could have a
look at this problem.
Without complete support port-offset I cannot have JBoss and WildFly
online the same time.
Thanks in advance!
11 years, 1 month
Error invoking DataSourceStatisticsListener
by Frank Langelage
A recent commit (possibly
https://github.com/wildfly/wildfly/commit/6958572eab1c7ee6f3a6916eb1d3d64...)
introduced this problem:
19.09. 15:38:00,638 INFO [org.jboss.as.server.deployment#start]
JBAS015876: Starting deployment of "hgm2e-langfr-sb2000-ipc-ifx-ds.xml"
(runtime-name: "hgm2e-langfr-sb2000-ipc-ifx-ds.xml")
19.09. 15:38:00,702 ERROR [org.jboss.msc.service#invokeListener]
MSC000002: Invocation of listener
"org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener@193180c"
failed: java.lang.IllegalArgumentException: JBAS014809: A node is
already registered at '(deployment => *)(subsystem =>
datasources)(data-source => *)(statistics => jdbc)'
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:142)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:88)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72)
[wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
19.09. 15:38:00,733 INFO
[org.jboss.as.connector.subsystems.datasources#transition] JBAS010400:
Bound data source [java:/hgm2e-langfr-sb2000-ipc]
19.09. 15:38:00,728 INFO
[org.jboss.as.connector.subsystems.datasources#transition] JBAS010400:
Bound data source [java:/hgm2e-langfr-sb2000-ipc-ems]
19.09. 15:38:00,722 ERROR [org.jboss.msc.service#invokeListener]
MSC000002: Invocation of listener
"org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener@1c72116"
failed: java.lang.IllegalArgumentException: JBAS014809: A node is
already registered at '(deployment => *)(subsystem =>
datasources)(data-source => *)(statistics => jdbc)'
at
org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:142)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:88)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72)
[wildfly-connector-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2095)
[jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[rt.jar:1.7.0_40]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[rt.jar:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
19.09. 15:38:00,925 INFO [org.jboss.as.server#handleResult] JBAS018559:
Deployed "hgm2e-langfr-sb2000-ipc-ifx-ds.xml" (runtime-name :
"hgm2e-langfr-sb2000-ipc-ifx-ds.xml")
There 3 datasources defined in -ds.xml files in deployments folder.
First file DefaultDS-ds.xml wich contains DefaultDS deploys fine.
Second file named, hgm2e-langfr-sb2000-ipc-ifx-ds.xml in this case,
defines 2 more datasources which raise these errors.
These more likely warnings, because the application including database
access work fine. But they should go away again.
Stefano / Brian?
11 years, 2 months
