Elytron integration tests in WildFly testsuite
by Josef Cacek
Hi,
EAP QE and Elytron Dev teams would like to raise a discussion about how the Elytron integration tests will be added to the WildFly/EAP testsuite.
We would like to agree on a unified approach across the testsuite, so we don't end up in situation where each component comes with its own "best-fitting" solution.
We see following requirements:
1. new features which come with Elytron need to be covered by integration tests
2. existing scenarios have to stay working when Elytron is configured as the default security subsystem
3. legacy security subsystem must stay working in parallel
Our teams came to agreement that the safest way would be to copy whole existing testsuite modules into new ones. E.g.
cp -r testsuite/integration/basic testsuite/integration/basic-legacy-security
# + Reconfigure testsuite/integration/basic to use Elytron
# + Add @Ignore to all tests which fail with Elytron or use directly the old security configuration
The modules would just live side by side - basic would use Elytron configuration, basic-legacy-security would use configuration similar to (or same as) the current server configuration.
In the next step we will go through the Ignored tests (the TODO list) for Elytron and rewrite them or report issues if necessary.
By this way we would keep all the test coverage for legacy security. We would also have all existing scenarios covered (or at least present) for Elytron configuration.
Are there any objections to this suggestion?
Thanks,
-- Josef
9 years, 1 month
EJB Transactions Graceful Shutdown
by Flavia Rainone
Hi,
I'm creating this thread to discuss the remaining details of graceful
shutdown for ejb transactions.
This is more or less what I've done so far:
https://github.com/fl4via/wildfly/commit/7017146522af9a979a8a8e0c92039e6a...
While discussing this in the hip chat yesterday, Stuart mentioned that
maybe we could have the transactions subsystem responsible for keeping
track of how many active transactions we have, instead of putting that
code in EjbRemoteTransactionsRepository.
Stuart, does that include having the suspend callback being done at
transactions subsystem as well? I'm thinking maybe not, because there
are two points in the ejb subsystem we need to know if transactions
suspension is over:
- at EjbSuspendInterceptor if it is over, no request is allowed, if it
is not over, we need to check if current invocation contains a reference
to an active transaction
- at some point, we need to let control point notify that the ejb module
is no longer available to ejb client after transaction suspension is
over, i.e., we need to do that when suspend has been requested and there
are no remaining active transactions available.
On the other hand, it is hard to draw the line between what should be in
the transactions subsystem and what shouldn't. If the callback is done
at transactions subsystem, we need a way of having ejb3 notified that it
is done. If it is not done at transactions subsystem, ejb3 has to be
notified of the active transactions going to zero, which seems a lot of
overhead, so from this point of view maybe the callback should be in the
transactions system after all.
Stuart and Gytis, any thoughts?
--
Flavia Rainone
Principal Software Engineer
JBoss EAP/WildFly Team
M: (+55) 11 981-225-466
Red Hat.
Better technology.
Faster innovation.
Powered by community collaboration.
9 years, 1 month
Proposal: Batch Job Visibility Restrictions
by James Perkins
Currently a deployment can view, stop, restart or abandon any batch job
that has been submitted or has been executed that exists in the job
repository. This includes batch jobs from other deployments if the job
repository is shared, which is the default. I cannot however start a batch
job from another deployment.
I'm proposing we limit visibility so that a deployment can only access jobs
which belong to that deployment.
I'd like to get some opinions on this.
There are some, possibly unacceptable, repercussions. For example if a user
has a deployment that displays information about batch jobs for all
deployments this change would break that. However it does seem wrong to
allow any deployment using a shared repository to stop, start or abandon a
job from a different deployment.
One, probably more complicated, option would be to have an attribute on the
job-repository to allow jobs to be visible to any deployment with access to
the job-repository.
--
James R. Perkins
JBoss by Red Hat
9 years, 1 month
Jandex - Retrieving meta-annotations
by Gunnar Morling
Hi,
Two questions on Jandex usage:
* When having a org.jboss.jandex.AnnotationInstance, how could one obtain
any meta-annotations given for the annotation's *type*?
* Is there any example for obtaining Java 8 type annotations, e.g. from a
FieldInfo?
Thanks for any pointers,
--Gunnar
9 years, 1 month
