Web Security - Performance Considerations
by Anil Saldhana
Hi Remy,
I just wanted to pick your brain on the following:
Web Authorization:
Previously, the JBoss Authorization stack was run by default for access
control unless the user configured not to do so. In JBoss AS7.1, we
have this disabled until the user configures the following in jboss-web.xml
<use-jboss-authorization>true</use-jboss-authorization>
Web Audit:
I had a brief chat with JFClere last week and decided on the following:
JBossWebRealm will send audit events to the audit framework unless the
following setting is in jboss-web.xml
<disable-audit>true</disable-audit>
Audit is the feature that can add miniscule overhead. So if you want to
turn it off the audit by default, you have to change JBossWebRealm to
have: boolean disableAudit = true rather than the current "false". In
that case, we will require the users to configure jboss-web.xml if they
want audit for that particular webapp.
In think the authorization piece does not add any overhead. I just want
to check with you on the audit part.
Regards,
Anil
12 years, 6 months
Configuration conundrum with Express
by Pete Muir
Warning, I may be repeating an existing query, so tell me politely where to go if that is the case ;-)
I've been adding Express support to Forge, in the run up to doing demos at JavaOne. I've hit the point where I want to add an entry (an Infinispan cache) to the standalone.xml (or domain.xml), and I want to do it without having to write a parser. If the node is available via the mgmt interface this is easy - I can use the REST interface etc. However, my node isn't, and the recommended way to configure it is to edit .openshift/configuration/standalone.xml.
Any thoughts on how I can make use of the management capabilities of AS to define this (in a machine controllable way without me reinventing the wheel) for OpenShift Express?
12 years, 6 months
Web Authorization and Audit
by Anil Saldhana
Marcus,
this is in regard to your proposed changes to JBossWebRealm for the
authorization bits.
https://github.com/mmoyses/jboss-as/commit/ba3c43f8dfc9c201098392c5ebf904...
Previously, AS5/6, we had the JBoss Authorization enabled by default.
IMO for AS7, you have taken the right approach to allow user to
configure whether to use JBoss Authz via jboss-web.xml setting.
We need to get this merged asap such that I can finish the auditing task
I am currently working on.
Regards,
Anil
12 years, 6 months
Better handling of transaction leaks?
by Jaikiran Pai
While looking into a test failure I noticed that currently user
applications can end up leaking transactions (associated with the
invocation thread):
Servlet {
doGet() {
UserTransaction.begin();
doSomeOp();
fail();
// no tx rollback/commit
}
}
Subsequent transactions on that thread can lead to failures and other
sorts of issues. Looking back at previous versions of AS, we had a valve
http://anonsvn.jboss.org/repos/jbossas/trunk/tomcat/src/main/java/org/jbo...
which used to cleanup (and log an error) about the leaking transactions.
Do we want something similar for AS7? Also, are there other "entry
points" (like servlets for web requests) where such leaks can happen and
needs to be taken care off?
-Jaikiran
12 years, 6 months
JNDI lookup and EJB invocation from a remote client
by Jaikiran Pai
Now that we have some kind of stability on the EJB remote client API and
its implementation (ofcourse on our individual git branches), I was
looking around to see how easy/seamless the JNDI interaction from a
remote client is going to be from a user point of view. So I've got this
testcase (which runs as a remote client) which does lookup of a SLSB via
the ejb: jndi naming scheme that we have introduced:
@RunWith(Arquillian.class)
@RunAsClient
public class RemoteEJBJNDIAccessTestCase {
...
private Context initialContext;
@Before
public void beforeTest() throws Exception {
final Properties initCtxProps = new Properties();
initCtxProps.put(Context.URL_PKG_PREFIXES,
"org.jboss.ejb.client.naming");
this.initialContext = new InitialContext(initCtxProps);
}
... // trimmed some code which creates and deploys the deployment via
Arquillian @Deployment
...
@Test
public void testSLSBInvocation() throws Exception {
final String distinctName = "";
final EchoRemote echoRemote = (EchoRemote)
this.initialContext.lookup("ejb:" + APP_NAME + "/" + MODULE_NAME + "/" +
distinctName + "/" + EchoBean.class.getSimpleName() + "!" +
EchoRemote.class.getName());
Assert.assertNotNull("Received a null proxy", echoRemote);
final String message = "Hello world from a really remote client
via a proxy from JNDI";
final String echo = echoRemote.echo(message);
Assert.assertEquals("Unexpected echo message", message, echo);
}
}
So the test first looks a up proxy using ejb:<...blah> and then invokes
on that bean proxy. The invocation on the proxy fails with:
java.lang.IllegalStateException: No EJB client context is set for this
thread
at
org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:150)
at
org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:77)
at $Proxy18.echo(Unknown Source)
at
org.jboss.as.testsuite.integration.ejb.remote.client.api.RemoteEJBJNDIAccessTestCase.testSLSBInvocation(RemoteEJBJNDIAccessTestCase.java:79)
That's expected because we haven't configured any EJBClientContext for
this invoking thread.
So the questions I had was:
1) Do we want the JNDI invocations to be really seamless (i.e. the above
code to functional)? I'm very much in favour of letting the users invoke
via JNDI without any explicit use of EJB client API in their code. I
don't see a point of using JNDI as well as EJB client API to get it to work.
2) My idea of making this work was to use the Context.PROVIDER_URL as
our remote receiver uri. So the jndi.properties or even the properties
passed to the InitialContext could contain (comma separated list)
something like remote://localhost:9999 (just an example) to point to the
remote EJB connector. The EJBNamingContext would then be smart enough to
first setup a (remoting) EJB receiver during context creation and then
setup a EJB client context on the invoking thread, when the proxy is
invoked (this would require the lookup to return a wrapper over the
invocation handler to intercept the calls on the proxy and just do a
EJBClientContext.setCurrent(...) before passing on the control to the
EJBInvocationHandler).
#2 is all impl details and actually has numerous issues with it:
a) It assumes that it would be OK to setup the remoting connection
ourselves and not mandate the user to provide one (we could actually
allow users to pass configurations for the connection). David has
mentioned that it wouldn't be a good idea creating the connection
ourselves. But that was in the context of pure native EJB client API
design. Does it make sense to somehow relax that require in this JNDI case?
b) The Context.PROVIDER_URL used in the jndi.properties or the
properties being passed to the InitialContext apply to the entire
context and aren't anything specific to EJB invocations. i.e. the user
could use that context to do lookup/invocations on non-EJB objects bound
to JNDI. I'm not sure how non-EJB JNDI lookup outside of the server VM
is being implemented/planned, so using that EJB specific(?) remoting
connector info (remote://<localhost:ejb-remote-connector-port>) in the
jndi.properties isn't probably a good idea.
So how do we go about this?
-Jaikiran
12 years, 6 months
Why is my clone missing recent tags?
by Scott Stark
For some reason a pull is no longer getting the tags from the
jbossas/jboss-as repo. I just pulled down the latest changes, but only
picked up one new tag. All of the release tags are missing.
[59](ironmaiden:jboss-as) > git pull upstream master
From git://github.com/jbossas/jboss-as
* branch master -> FETCH_HEAD
Already up-to-date.
[60](ironmaiden:jboss-as) > git tag -l
7.0.0.Alpha1
7.0.0.Alpha1-final
7.0.0.Beta1
7.0.0.Beta1-prerelease
7.0.0.Beta2
7.0.0.Beta2-prerelease
7.0.0.Beta3
7.0.0.Beta6OS
7.0.0.CR1
7.0.0.Final
7.0.0.Final-prerelease
7.0.0.Final-prerelease2
7.0.0.Final-prerelease3
7.1.0.Alpha1
12 years, 6 months
"Scaled count" in thread pool configs
by Brian Stansberry
Apparently we've gotten feedback from management that the "scaled-count"
notion in the jboss-as-threads-1_0.xsd[1] is confusing and should be
replaced with a simple single attribute.
I planned to do this, but I see that the JCA subsystem has picked up
this element type and incorporates it in their config.
I propose we eliminate this in JCA as well. We want consistency in how
threads are configured across subsystems. The parser for a version 1_0
document can just convert to a single value and log a WARN.
[1]
https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/...
On 9/30/11 2:41 PM, Brian Stansberry wrote:
> Ok, the "per-cpu" option will go, which will break old configs who used
> it (unlikely.)
>
>
> Brian Stansberry 2:33 PM
> thread subsystem question...
> 2:34 PM
> The "count" and "per-cpu" notions
> David M. Lloyd 2:35 PM
> they should go away, they've been poo-pooed for EAP 6
> Brian Stansberry 2:35 PM
> 1) do we want them 2) even if not, we can't get rid of them w/o breaking
> old configs
> David M. Lloyd 2:35 PM
> should just be count
> 2:35 PM
> well, we can just blame our own managers
> Brian Stansberry 2:35 PM
> ok, cool
> David M. Lloyd 2:35 PM
> I still like the per-cpu thing but apparently it's too confusing
> Brian Stansberry 2:36 PM
> I like the idea too, but not enough to spend any energy defending it
> David M. Lloyd 2:37 PM
> exactly
> Brian Stansberry 2:37 PM
> and I'm in a discussion where i'd have to defend it
> 2:38 PM
> so speak now or forever hold your peace!
> 2:38 PM
> David M. Lloyd holds his peace
> Brian Stansberry 2:38 PM
> gavel slams
>
>
> On 9/30/11 12:22 PM, ssilvert(a)redhat.com wrote:
>> I agree. The flatter representation is easier to understand. Do you need
>> a suffix at all?
>>
>> core-threads
>> queue-length
>> max-threads
>>
>> This is similar to the names we see in Tomcat connectors and everyone
>> understands.
>>
>>
>> Quoting Brian Stansberry <brian.stansberry(a)redhat.com>:
>>
>>> Merged. http://github.com/jbossas/jboss-as/compare/d95cd7f...20e7427
>>>
>>> There's some other work I want to do on this related to expressions
>>> support, but that shouldn't impact the management API except for the
>>> fact that some attributes/operations will support expressions.
>>>
>>> One thing where I'd like your input though is on some "complex
>>> attributes". If you look for uses of the method at [1] you'll see what
>>> I mean. They all deal with a complex attribute that represents an
>>> instance of the xsd type shown at [2].
>>>
>>> I think we should look at those usages and see if we can flatten that
>>> complex attribute out into 2 simple attributes, e.g.
>>>
>>> core-threads-count
>>> core-threads-per-cpu
>>>
>>> queue-length-count
>>> queue-length-per-cpu
>>>
>>> max-threads-count
>>> max-threads-per-cpu
>>>
>>> The term "count" isn't so great in those attribute names though. Maybe
>>> "base" ??
>>>
>>> [1]
>>> https://github.com/jbossas/jboss-as/blob/master/threads/src/main/java/org...
>>>
>>>
>>>
>>> [2]
>>> https://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/...
>>>
>>>
>>>
>>> On 9/29/11 9:33 AM, Brian Stansberry wrote:
>>>> Alexey has a pull request in; I'll get it merged this morning.
>>>>
>>>>
>>>> On 9/29/11 8:38 AM, ssilvert(a)redhat.com wrote:
>>>>> What is the status? Is there enough there for me to get started on
>>>>> console support for the threading subsystem?
>>>>>
>>>>> Quoting Brian Stansberry <brian.stansberry(a)redhat.com>:
>>>>>
>>>>>> On 9/28/11 4:38 PM, Alexey Loubyansky wrote:
>>>>>>> I'm flying to Ukraine tomorrow and actually will be on vacation
>>>>>>> until
>>>>>>> the 7th of Oct. But I'll be checking emails and looking what's going
>>>>>>> on.
>>>>>>> If anything, I'll be able to fix things.
>>>>>>>
>>>>>>
>>>>>> Ok, have a good trip!
>>>>>>
>>>>>>> What's missing (in my master) is support for expressions. Parsing is
>>>>>>> used only during the boot time, afaics. At run-time using
>>>>>>> expressions in
>>>>>>> write-attribute doesn't work. I actually am not sure whether it
>>>>>>> should
>>>>>>> at all but I'd expect it to. Anyway, I'm gonna look into this more.
>>>>>>>
>>>>>>
>>>>>> For it to work the client would have to send a node of
>>>>>> ModelType.EXPRESSION.
>>>>>>
>>>>>> Maybe we could do something with that in AttributeDefinition; e.g. if
>>>>>> the node is ModelType.STRING and expression is allowed, see if we can
>>>>>> it has ${...} and convert it.
>>>>>>
>>>>>>> Sorry again for being late,
>>>>>>
>>>>>> No worries; I was out sick Monday and have behind ever since.
>>>>>>
>>>>>> Thanks for taking this on!
>>>>>>
>>>>>>> Alexey
>>>>>>>
>>>>>>> On 09/27/2011 05:49 PM, Brian Stansberry wrote:
>>>>>>>> On 9/27/11 10:39 AM, Alexey Loubyansky wrote:
>>>>>>>>> On 09/27/2011 05:33 PM, Brian Stansberry wrote:
>>>>>>>>>> On 9/26/11 12:11 PM, Alexey Loubyansky wrote:
>>>>>>>>>>> I've re-written attributes registration, write handlers and add
>>>>>>>>>>> handler
>>>>>>>>>>> following the jms example.
>>>>>>>>>>>
>>>>>>>>>>> The problem I see (perhaps, I'm missing something) is that the
>>>>>>>>>>> default
>>>>>>>>>>> value, for e.g. priority for thread factory, which is -1, is not
>>>>>>>>>>> set on
>>>>>>>>>>> the factory instance during the add operation, if the priority
>>>>>>>>>>> value
>>>>>>>>>>> isn't provided by the user. But I do see
>>>>>>>>>>> AttributeDefinition.validateResolvedOperation and the default
>>>>>>>>>>> being
>>>>>>>>>>> set.
>>>>>>>>>>> Still read-attribute returns "undefined" with
>>>>>>>>>>> include-defaults=true.
>>>>>>>>>>> I'm
>>>>>>>>>>> gonna look further though.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'll look at your pull request, as I'm not clear what the
>>>>>>>>>> issue is
>>>>>>>>>> and
>>>>>>>>>> maybe you've sorted it out?
>>>>>>>>>
>>>>>>>>> Yes, the default value is fixed now. Although, I discovered that
>>>>>>>>> invoking read-attribute on an attribute that has a default value
>>>>>>>>> on a
>>>>>>>>> node that doesn't exist works well and returns the default value.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks. https://issues.jboss.org/browse/AS7-1960
>>>>>>>>
>>>>>>>>>>> Should I add system property replacement for all the attributes?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Generally, yes. Thread pool configs in general are a classic use
>>>>>>>>>> case
>>>>>>>>>> for expressions. If you see some attribute where it makes you
>>>>>>>>>> uncomfortable, then it's ok not to. For example, in the web
>>>>>>>>>> subsystem
>>>>>>>>>>
>>>>>>>>>> <connector socket-binding="http" .../>
>>>>>>>>>>
>>>>>>>>>> I don't like allowing an expression there as it's a ref to
>>>>>>>>>> another
>>>>>>>>>> part
>>>>>>>>>> of the model. Technically it could work, but it just makes me
>>>>>>>>>> uncomfortable and doesn't feel like a "must have."
>>>>>>>>>>
>>>>>>>>>> For any attribute we can always add the ability to use an
>>>>>>>>>> expression in
>>>>>>>>>> a later release, but we can't take it away.
>>>>>>>>>
>>>>>>>>> Expressions are not included in my pull request. I am looking at
>>>>>>>>> them
>>>>>>>>> now. And talked to Emanuel about them. EXPRESSION type is a bit
>>>>>>>>> confusing. I.e. it's not clear what the target type is, be it INT,
>>>>>>>>> STRING, etc, this info should be there in the attribute
>>>>>>>>> description.
>>>>>>>>> Just a flag allows-expressions would be good. Anyway, I'm looking
>>>>>>>>> into
>>>>>>>>> this now.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If your attribute definition has the "allowExpression" property
>>>>>>>> set to
>>>>>>>> true, the generated metadata for the attribute or operation
>>>>>>>> parameter
>>>>>>>> will include "expressions-allowed" => true.
>>>>>>>>
>>>>>>>> The "type" => ModelType.XXX metadata will be whatever ModelType you
>>>>>>>> pass
>>>>>>>> into the AttributeDefinition, which should not be
>>>>>>>> ModelType.EXPRESSION;
>>>>>>>> it should be INT, STRING, whatever.
>>>>>>>>
>>>>>>>> The "parse" methods in SimpleAttributeDefinition are helpful --
>>>>>>>> they
>>>>>>>> can
>>>>>>>> be called by the parser and will automatically detect
>>>>>>>> expressions in
>>>>>>>> the
>>>>>>>> string read from the parser and create a model node of
>>>>>>>> ModelType.EXPRESSION.
>>>>>>>>
>>>>>>>>>>> And "3) the various pools expose metrics; we need to add runtime
>>>>>>>>>>> attributes for those". Do they actually exist for threads? Or
>>>>>>>>>>> are
>>>>>>>>>>> they
>>>>>>>>>>> planned? I don't see them.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> org.jboss.threads.QueueExecutor, QueuelessExecutor,
>>>>>>>>>> JBossThreadPoolExecutor expose metrics. The MSC services we are
>>>>>>>>>> adding
>>>>>>>>>> (e.g. BoundedQueueThreadPoolService) return an ExecutorService
>>>>>>>>>> from
>>>>>>>>>> getValue() -- we may need to return a sub-interface that includes
>>>>>>>>>> the
>>>>>>>>>> metrics.
>>>>>>>>>
>>>>>>>>> I'll have a look, thanks.
>>>>>>>>>
>>>>>>>>> Alexey
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Principal Software Engineer
>>>>>> JBoss by Red Hat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Principal Software Engineer
>>> JBoss by Red Hat
>>
>>
>>
>>
>>
>
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
12 years, 6 months
JBoss modules definition for Envers
by Dimitris Andreadis
Hi there,
I am looking at the org.hibernate modules definition in AS7:
- <module xmlns="urn:jboss:module:1.0" name="org.hibernate">
...
- <dependencies>
...
<module name="org.hibernate.envers" services="import" optional="true" />
</dependencies>
</module>
Then at envers:
- <module xmlns="urn:jboss:module:1.0" name="org.hibernate.envers">
...
- <dependencies>
<module name="org.hibernate" />
...
</dependencies>
</module>
Are cyclical dependencies allowed?
Also, what's the service="import" clause really about? What's a service in this context?
From the doc:
https://docs.jboss.org/author/display/MODULES/Module+descriptors:
Specify whether this dependency's services* are imported and/or exported. Possible values
are "none", "import", or "export"; defaults to "none".
Thanks in advance
/D
12 years, 6 months
