Containers Representation of the Unauthenticated Identity
by Darran Lofthouse
Do we have a definition of what the containers representation of the
unauthenticated identity actually is?
On the login modules we generally have an option to specify an
unauthenticated identity, regardless of which one you pick the
@SecurityDomain annotations have an unauthenticatedIdentity which
defaults to "".
Should the one set by the domain be taking priority and then fall back
to the one in the annotation if that did not work and then fall back to
a default if that is not set?
Regards,
Darran Lofthouse.
12 years, 10 months
Consolidate Arquillian test infrastructure
by Thomas Diesler
Folks,
the initial work on consolidating the arquillian test infrastructure
(AS7-734 <https://issues.jboss.org/browse/AS7-734>) is done.
What you see in pull request 49
<https://github.com/jbossas/jboss-as/pull/49> installs the latest
arquillian 1.0.0.Beta2 release to use with all test suites. These are
testsuite
+ smoke
+ spec
+ integration
The AS7 instance is started in managed mode (i.e. in a separate VM).
There is no arquillian subsystem any more nor any test related jar
artefacts in modules. Instead the arquillian endpoint is deployed before
the first test. As a side effect of arq managed it is also possible to
manually start up an AS7 instance and run the tests as usual. This is
useful for in container debugging. The maven test goal works as
expected. You can run individual tests with -Dtest=Foo
For this iteration, the focus was on infrastructure not on individual
test failures. All tests were ported to the new arquillian API. Tests
that failed for obvious reasons were fixed the hard ones ignored.
To see which tests were ignored run
> git grep AS7-734
Attached is a snapshot of the ignored tests. I'll take care of the osgi
ones. For the others I'd like to ask the respective authors to have a look.
JSF testing is currently disabled completely because of its dependency
on the arquillian servlet protocol. I'll follow up with the JSF folks so
we can decide how to resurrect those.
Overall writing integration tests should now be much easier.
cheers
-thomas
-
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
12 years, 10 months
Re: [jboss-as7-dev] Datasource name - DefaultDS instead of H2DS?
by Jozef Hartinger
Sorry for reviving an old thread, but I haven't found a final conclusion
anywhere.
I've run into this problem[1] with a Seam 3 sample application. Besides
Seam 3, there are other (even JBoss) projects (Seam 2, perhaps
RichFaces, etc..) which have sample applications that rely on DefaultDS.
It is not likely for these projects to adapt to this change and have a
release before the AS 7 is released. Therefore, I think we should
maintain backwards compatibility as much as possible so that (most of)
the sample applications working on JBoss AS 6 can be used on AS7 out of
the box.
[1] https://issues.jboss.org/browse/AS7-975
12 years, 10 months
Management API changes
by Heiko Braun
Everybody please be aware that all management clients
(CLI, Console, Eclipse) are the last in the food chain when it comes to
changes in the detyped API.
We must prevent last minute changes top the detyped API
in order not to break any of these clients.
The recent changes to the JMS subsystem basically force me to rewrite large parts
of what was considered CR already.
Please think twice next time, communicate planned changes early enough,
and plan ahead at least two weeks for us to incorporate the modifications.
The next time I am going to discover this by coincidence, I am going to force a rollback on these changes.
Ike
12 years, 10 months
Request for review of DomainServletApi bridge
by Scott Stark
I wanted to be able to access the domain api that is currently served up
by the domain-api-http services on localhost:9990/domain-api via the
jbossweb connectors (localhost:8080/domain-api by default), so I created
a org.jboss.as.web.domain.{DomainApiContextService,DomainApiServlet}
pair that does this. I only have the GET access working at the moment,
but wanted feedback on how to proceed as the DomainApiServlet has to
duplicate a lot of the domain-api-http
org.jboss.as.domain.http.server.DomainApiHandler because of the servlet
api vs org.jboss.com.sun.net.httpserver differences. It is relatively
easy to refactor the DomainApiHandler to isolate the differences so that
the bulk of the code can be used by the DomainApiServlet, but before
doing that I wanted some feedback on the changes so far:
https://github.com/starksm64/jboss-as/commit/03cc9156e05358f3e1a6d36c4df7...
Should this be in the web module or factored out into a new module that
depends on domain-api-http and web?
12 years, 10 months
Switch to use TransactionSynchronizationRegistry.registerInterposedSynchronization?
by Scott Marlow
We are supposed to be able to use
TransactionSynchronizationRegistry.registerInterposedSynchronization
(TSR) in our containers but I wanted to bring up an ordering issue that
can happen.
If you look at http://pastie.org/1836698, you can see what happened when
Hibernate registered a synchronization object with the TSR and we tried
after to get a database connection from the connection pool.
Basically, once a synchronization object is registered with the TSR, the
other way of registering a synchronization object through the
Transaction registerSynchronization() cannot be used (or you get the
above linked IllegalStateException error).
The short term fix was to avoid registering Hibernate with the TSR and
instead use the Transaction registerSynchronization(). This helped
avoid the ISE exception as the TSR sync ordering check is avoided.
The Transaction registerSynchronization(), has no ordering requirements
but as we have seen, the TSR registerInterposedSynchronization does.
I think we need to be consistent across our projects and either use TSR
or avoid it (to avoid the "Synchronizations are not allowed!" JTA
error). If/when we use it, we need to coordinate the switch over to it,
so that all projects have time to switch to it.
I'm hoping someone will tell me that there is an easier path to use TSR
registerInterposedSynchronization in some of our projects. What do you
think?
The other question, is how/when we should we coordinate a switch over to
use TSR (assuming there is agreement that we should coordinate the switch)?
Scott
12 years, 10 months
Add/Remove Loggers and Handlers
by ssilvert＠redhat.com
I'm trying to add and remove loggers and handlers. Should I be able
to do this in a management operation? "remove-root-logger" works, but
I can't remove an ordinary logger.
[standalone@localhost:9999 /] /subsystem=logging/:remove
{
"outcome" => "failed",
"failure-description" => "No handler for remove at address
[(\"subsystem\" => \"logging\")]"
}
[standalone@localhost:9999 /] /subsystem=logging/logger=com.arjuna/:remove
{
"outcome" => "failed",
"failure-description" => "java.lang.IllegalArgumentException"
}
12 years, 10 months
Server Group equals Cluster?
by Heiko Braun
Can somebody shed some light on the relation between server groups
(or domains in general) and clustering?
Ike
12 years, 10 months
