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.
12 years, 9 months
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
12 years, 10 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
12 years, 12 months
Resolving JIRAs
by Brian Stansberry
If you have a JIRA assigned to you and it's in "Pull Request Sent"
status in JIRA[1] but you know the PR has been merged and the issue can
be resolved, can you resolve the JIRA, please?
I normally make an effort to do this when I merge PRs, as do the other
mergers, but it's been slipping a bit lately. So if folks can take care
of their own that will clean JIRA up a bit.
[1]
https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%...
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
13 years
Jenkins job to run build using victims-scan profile
by David Jorm
Hi All
Since this PR was merged:
https://github.com/wildfly/wildfly/pull/4939
We now have the "victims-scan" profile in the main POM, which will scan for known vulnerable dependencies at build time. The rationale behind putting this scan into a separate profile was to ensure that it had no deleterious impact on day-to-day development. To ensure that we do get some regular scans performed, the missing step is to create a jenkins job which regularly runs builds using the victims-scan profile, and then emails output to an appropriate list if the build fails due to the victims scan. I think an appropriate trigger for the job would be a weekly timer. Would it be possible to create such a job? Is there any way I can assist to make it happen?
Thanks
--
David Jorm / Red Hat Security Response Team
13 years
Copies of LazyValidatorFactory
by Farah Juma
Hi,
I recently worked on CDI and Bean Validation integration for method validation (WFLY-529). As described in [1], part of this work involved replacing the delegate of the EE LazyValidatorFactory with a CDI-enabled ValidatorFactory. However, JCA and JPA still currently use copied versions of the old EE LazyValidatorFactory. Since JCA and JPA should also have access to the CDI-enabled ValidatorFactory, it would be good if we could remove the copies (i.e., remove JCAValidatorFactory and JPALazyValidatorFactory) and use the current EE LazyValidatorFactory directly instead. As discussed with Scott Marlow, for JPA, it looks like we can access the EE LazyValidatorFactory from the deployment unit attachment (i.e., via deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY)), as described in WFLY-1705 [2]. However, for JCA, it doesn't seem like this will be possible since the code that currently instantiates the JCAValidatorFactory doesn't have access to the deploymentUnit (and it seems like there isn't a way to modify the code to be able to access this). Another option might be to register the ValidatorFactory as a service and then perform a manual lookup on the service.
I was wondering if anyone had any thoughts about what approach to take for JCA or how to go about removing the JCAValidatorFactory. I've created WFLY-1882 [3] to track this. In addition to JCA and JPA, we'll need to consider what should be done for JSF since it will also need to be able to access the CDI-enabled ValidatorFactory. Note that JSF doesn't use a copy of the EE LazyValidatorFactory and so it seems to be bootstrapping Bean Validation in another way.
[1] https://issues.jboss.org/browse/WFLY-529?focusedCommentId=12787076&page=c...
[2] https://issues.jboss.org/browse/WFLY-1705
[3] https://issues.jboss.org/browse/WFLY-1882
Thanks,
Farah
13 years
Accessing Admin Console
by Shelly McGowan
When I attempt to access any information from the Admin Console using WildFly 8.0.0.Beta1-SNAPSHOT,
I get: Authorisation Required: You do not have permission to access these resources.
Error can be seen here: http://pastebin.com/TVyYguSM
Is this a known issue and, if so, is there a workaround to access information exposed by the Console?
Shelly McGowan
JBoss, by Red Hat
13 years
web console error
by luca boncompagni
Hi,
after pulling the last git, the web console does not work anymore. Every
link that I click I get the following error in the log:
11:35:34,203 ERROR [org.jboss.as.controller.management-operation] (XNIO-1
task-3) JBAS014612: Operation ("read-resource-description") failed -
address: ([
("core-service" => "platform-mbean"),
("type" => "runtime")
]): java.lang.IllegalArgumentException: No enum constant
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.AccessControl.TRUE
at java.lang.Enum.valueOf(Enum.java:236) [rt.jar:1.7.0_21]
at
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$AccessControl.valueOf(ReadResourceDescriptionHandler.java:704)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler$AccessControl.forName(ReadResourceDescriptionHandler.java:726)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecuteInternal(ReadResourceDescriptionHandler.java:172)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.doExecute(ReadResourceDescriptionHandler.java:145)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.operations.global.ReadResourceDescriptionHandler.execute(ReadResourceDescriptionHandler.java:138)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:251)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:138)
[wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at
org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:154)
[wildfly-domain-http-interface-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
I think that the problem was caused by:
commit 8973b52ba4831ce5b937ec496a268795a74578b5
Author: kabir <kkhan(a)redhat.com>
Date: Tue Aug 13 17:18:58 2013 +0100
[WFLY-490] Get rid of the attributes parameter, and make access-control
an enum for more control over the output
Thanks,
Luca
13 years
Licence evolution
by Michael Bilalis
Hello,
I'm an happy user of JBoss AS7 and I'm waiting for a Wildfly release.
I've heard that licence concerning Fuse has evolved and it can be only
used for development. Is same evolution will be apply to JBoss AS7 and
Wildfly in the future ?
Kinds regards.
Michaël
13 years
