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
10 years, 11 months
DMR Scala
by Heiko Braun
FYI, a side project for people who
a) do hardcore wildfly administration and look for proper scripting capabilities
b) embrace scala and look for fun way to extend their horizon
DMR.scala [1] is a DMR port to scala, the DMR.repl [1] provides the REPL shell to create, load, store and execute scripts.
[1] https://github.com/hal/dmr.scala
[2] https://github.com/hal/dmr.repl
Have fun,
Heiko
10 years, 11 months
JMX authentication
by Rob Stryker
Hi All:
One of JBossTools' manual tests is showing something strange in the jmx
framework, and I was wondering if anyone had any ideas. Specifically,
against eap6.2 ER5.
Our code typically just loads jboss-client.jar from the appropriate
server installation's bin/client folder onto the threads classloader,
and then tries to open a jmx connection.
Since JMX is now done over management, I would expect it to behave
similarly to management. When connecting to management apis, credentials
are only requested if you are connecting from a different server, or the
same server but as a user without permissions on the server folder. JMX
is not behaving this way, and is requiring credentials even when
connected to on the same machine by the same user with all appropriate
filesystem permissions.
As far as I can tell, as7x works in the way that's expected (similar to
management). it's only eap6.2 and wildfly that's behaving this way,
requiring credentials even when on the same machine launched from the
same user, same permissions, etc.
Anyone have any ideas?
- Rob Stryker, JBossTools
Is this a regression or is this an intentional change?
10 years, 12 months
About API and leakage
by David M. Lloyd
Guys, when developing an API that is going to be shipped either as part
of WildFly as a module or for end-user consumption, I want you to
remember something:
Every public and protected member of that module *IS* API. That means
you can't ever change it without considering compatibility. "Well I
just made it public because this other module needs access to it" is not
a valid excuse, nor is "Well I needed access from another package".
Both are synonyms for "I screwed up my design at an early stage and now
I want to break the rules to fix my mistake".
The only exception is if you're developing a component specifically and
exclusively for use in the modular environment, and you put all non-API
public members into a specific package or package set which is then
excluded from export in the module.xml descriptor in the shipped
environment.
If you do not fall into this exception then you are volunteering to
personally maintain these non-public public classes for the next 10
years come hell or high water, because people are surely going to use
them, and I sure don't want to be the one to maintain them.
--
- DML
10 years, 12 months
Dependency Changes
by James R. Perkins
Debugging a TCK issue I found that the client jars that shade in their
dependencies were also pulling in the logmanager transitively from a
couple dependencies. This led to look at what else was coming in
transitively and realized, as we probably already know, it goes deep.
I started making some changes [1] after talking to David (which I may
have misunderstood so don't blame him :)) to exclude dependencies for
WildFly maven modules. I'm not really close to be done as it seems this
will take quite a while. The question is do we even want to exclude
dependencies like this? If I continued and did a PR would it be
accepted? I have a feeling it's going to be quite massive.
[1]: https://github.com/jamezp/wildfly/compare/WFLY-2332
--
James R. Perkins
Red Hat JBoss Middleware
10 years, 12 months
Naming, LDAP and a little bit of JMX
by Darran Lofthouse
For a while now the following issue has been bouncing around, I think it
is fair to say it is not going away ;-) : -
javax.naming.NameNotFoundException: rmi://127.0.0.1:1090/jmxrmi thrown
when creating MBeanServerConnection
https://issues.jboss.org/browse/WFLY-794
As I have been working on some LDAP features I agreed to look into an
LDAP issue from within a deployment and now have raised this issue: -
LDAP Search containing URL - InvalidNameException: ldap:: [LDAP: error
code 34 - Invalid root Dn given
https://issues.jboss.org/browse/WFLY-2319
Both of these issue share a common cause, the following default
InitialContext method is not reaching the point where schemes are checked: -
protected Context getURLOrDefaultInitCtx(String name)
throws NamingException {
if (NamingManager.hasInitialContextFactoryBuilder()) {
return getDefaultInitCtx();
}
String scheme = getURLScheme(name);
if (scheme != null) {
Context ctx = NamingManager.getURLContext(scheme, myProps);
if (ctx != null) {
return ctx;
}
}
return getDefaultInitCtx();
}
This is because the Naming subsystem sets the InitialContextFactoryBuilder.
So lookups or searches that are in the form of a URL e.g. rmi:// or
ldap:// are not being handled by their corresponding URLContext.
For the standard JNDI lookups it appears we almost already have support
for what we need: -
https://github.com/wildfly/wildfly/blob/master/naming/src/main/java/org/j...
What we seem to be missing is a registration of the factory for the RMI
url context.
For LDAP we have nothing yet.
When users hit problems in this area it tends to be quite serious for
them although overall only a small subset of users are affected by this.
I am considering if we want the following as a solution although the
purpose of this e-mail is for any additional feedback / ideas.
1 - Enhance the Naming subsystem configuration to allow the definition
of the factories for URL based contexts.
For most users this would not be used, for those that need it there is a
config option - this would also allow for JDK specific class names to be
specified in the users config.
2 - Provide an InitialDirContext implementation that also makes use of
the configuration from #1.
This would be slightly different to what we have already done for naming
in general as this would have to be a wrapper always used by
InitialContextFactoryBuilder to ensure the URL specific context is used
whenever one of it's methods is called.
Regards,
Darran Lofthouse.
11 years
runtime-name locked on management console
by Ben Schofield
I am trying to deploy unmanaged content with the management console on beta1. The runtime name field is locked but validation fails so it is impossible to deploy unmanaged content. Should this be a bug against HAL or WildFly and RBAC?
11 years
How to add deployment information
by Claudio Miranda
Hi, I would like to add more information to deployments artifacts to
be displayed at CLI/GUI (hash, date, time, download link, etc), but
examing the DeploymentData and ModelNode interface they do not have
those information.
What is the wildfly sub project that have the information to change
the deployment information to make it available to CLI/GUI ?
Example: At hal/core class
org.jboss.as.console.client.domain.groups.deployment.ContentRepositoryPanel
it uses DeploymentRecord for each deployment. I want to enhance this
to display more information. But where should I look into to begin
understanding these design ?
First I want to understand it, then discuss it with developers to see
what are acceptable and submit the PR.
Thanks.
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
11 years
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
