Security Domain Config: JASPI vs Classic?
by Jason T. Greene
Right now the security domain configuration has separate sections for
JASPI and Classic/Basic authentication. The only difference seems to be
that JASPI authentication requires an additional name field per module,
and JASPI authorization requires an additional login-module reference.
So essentially its a superset.
Is there a reason we would not want to just switch to the JASPI style of
specification, and eliminate the classic style. A name per login module
seems useful anyway.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
12 years, 7 months
AS7 management model descr and CLI
by Alexey Loubyansky
Sorry for the long email, it's very unlike me but I'm on PTO and kind of
bored.
Following the call we had, I was going to write about what the CLI needs
from the managed resources to provide easy ways to add resource-specific
commands that would allow to add new and modify/remove existing resources.
In a few words, every resource interested in a proper representation in
management tools has to provide its accurate model description.
Awhile ago quite some were missing even the basic description, e.g.
supported attributes, operations, etc. Now it looks much better. So,
thanks for fixing this!
I'd like to explain once again why this is important and how the model
description is used, so you understand the effects of you put into it.
On the example of [xa-]data-source commands. Each command can add,
remove or modify a resource. These commands work off of the model
description. Even the help content is pulled out from the model
description. So, whatever you put in the resource, attribute or
operation description will appear as help to your users.
Then the tab-completion for argument names. Some resources expose a lot
of operations and attributes and remembering all of them is impossible.
These commands turn operation and attribute names into command arguments
and allow to tab-complete them, given that they are available in the
model description, of course.
Further, there could be alternative configurations for some resources,
e.g. driver-name and driver-class or group-address and socket-binding,
or local-bind-address and socket-binding, i.e. these are choices, the
presence of one attribute (or command argument) excludes the presence of
the other. These relationships between the attributes have to be
available in the model description too. It'll still work if they aren't
but, e.g. the tab-completion will suggest all of them at the same time,
which is confusing and can be considered by the users as a bug. And as a
bug in the CLI, which I don't want to accept :)
Similar thing with some attributes requiring the presence of other
attributes, e.g. exception-sorter-properties shouldn't be present unless
exception-sorter-class is.
There are "alternatives" and "requires" properties in the model
description to express these things.
To help tab-complete values (e.g. of enum types, like tx isolation)
would be nice to extend the model description with allowed values.
Commands like [xa-]data-source are not coded in the CLI specifically for
datasources. They are examples of generic commands. Any subsystem or
resource can have commands like these, given the model description is
complete. You can actually add/remove them at runtime, see Managing
commands at the bottom of
http://community.jboss.org/wiki/GenericTypeCLICommands
At the end, I'd like to mention once again, I'd like to avoid having
commands coded specifically to manage some specific resource. The
advantages for generic commands are:
- avoid duplicated description of resources, their attributes and
operations;
- any changes to the model (attributes, operations, etc) will be
immediately available in the CLI w/o additional changes anywhere;
- and just less code to test and maintain.
There will still be other commands like deploy/undeploy that will have
to be maintained in the CLI itself, though.
Any suggestions or questions, please, let me know.
Alexey
12 years, 7 months
AS7 -b 0.0.0.0
by Jim Tyrrell
Form the core, If I can add something to this discussion or ask a question?
I agree with adding -b to 7.0.2, good catch and fix, and IMHO there are a whole host of options that "used" to be there, that need to just work for making peoples lives easier.
From my clustering labs I have used a command line like this:
./run.sh -c node1 -g A -u 224.0.0.0 -m 1110 -b 192.168.200.2 -Djboss.Domain=A -Djboss.jvmRoute="node2" -Djboss.messaging.ServerPeerID:0=2
Something like this: -Djboss.messaging.ServerPeerID:0=2 is a "macro" that replaces values in the config file, does a feature that like work today?
Potentially I would hope all of those options could be considered for migration, I am not smart enough to know all of the possibilities, but guessing we had a whole lot more.
How do we identify them?
How do we figure out if they should be in the future release/
I would also hope things like this get into a migration guide, although it sounds like they are getting closer.
Jim Tyrrell
Principal JBoss Solutions Architect
Did you see RHT on Cramer?
http://www.cnbc.com/id/39401056
12 years, 7 months
AS 7 Integration Test Suite Pull Request
by Shelly McGowan
There's been work on-going to resolve some final issues with the changes to the Integration Test suite pull request[1].
There are a few additional comments on this request which will be addressed as soon as possible.
If you have requirements or expectations on the test suite behavior be sure to review the pull request and provide feedback.
Otherwise, this email is a "heads up" to inform you of the pending changes. There is accompanying documentation (README files)
and a Test Suite User Guide has been started. It is expected once the initial pull request is in master, work
will continue on enhancing the framework, usability, and more importantly test coverage.
[1]https://github.com/jbossas/jboss-as/pull/320
Shelly McGowan
JBoss, by Red Hat
12 years, 7 months
JCA log message typo?
by Heiko Braun
When the server starts I can see:
"Starting JCS Subsystem (JBoss IronJacamar 1.0.4.Final)"
I guess it should read "JCA Subsystem"....
Ike
12 years, 7 months
WebConnectorService setSendfileSize
by Scott Stark
I was looking at some of the properties in the
org.jboss.as.web.WebConnectorService and how they relate
to the jboss-as-web.xsd, and came across this block of code that seems
incorrect as it does not make sense to relate the setSendfileSize to the
maxConnections:
try {
Method m =
connector.getProtocolHandler().getClass().getMethod("setSendfileSize",
Integer.TYPE);
m.invoke(connector.getProtocolHandler(),
maxConnections);
} catch (NoSuchMethodException e) {
// Not all connectors will have this
}
Is there supposed to be another property exposed for this?
12 years, 7 months
Reg: JNDI support for JBoss v7.
by sachin more
Hi All,
I am a new member in this mailing list. I want to monitor JBoss v7 on SCOM(
which normally use jndi port 1099 to communicate with jboss) but I found
that I am not able to enable this port by default , I guess a bug has been
logged against it
("https://issues.jboss.org/browse/AS7-1338"<https://issues.jboss.org/browse/AS7-1338>).
Is there any work around so as to enable this port on JBoss v7?
And also I am not able to locate jbossall-client.jar and
jboss-management.jar files in the JBOSS_HOME directory (We need this jar
files for collecting data in our monitoring server).
Please help me out with this issue.
Thanks in advance...
--
Sachin.
12 years, 7 months
JBoss Metadata 7.0.0.Beta13 Release
by Richard Opalka
Hi Folks,
could someone responsible release ${subject}, please ?
We'd like to enable bunch of tests in our continuous integration suite.
Thanks in advance,
Rio
--
Richard Opalka
ropalka(a)redhat.com
JBoss, by Red Hat
Mobile: +420 731 186 942
12 years, 7 months
