I made a local change to JCAOrderedLastSynchronizationList, to have the
JPA container (TransactionUtil$SessionSynchronization) afterCompletion()
always be run after Hibernate afterCompletion() but before the JCA
afterCompletion(). As I am implementing EntityManager caching  and
want to ensure that the EntityManager instances are only returned to the
cache after the EntityManager is expected to be available for reuse.
In my debugging, I noticed that the JCAOrderedLastSynchronizationList
only has the Hibernate synchronizations being added but not the JCA or
JPA container synchronizations.  shows that the JCA + JPA
Synchronizations are registered via
and Hibernate ORM Synchronization is registered via the
be changed to use JCAOrderedLastSynchronizationList as well, so that
IronJacamar (JCA) Synchronizations are run in the correct order?
Should we change the JPA subsystem/container to also ensure that
Hibernate ORM 5.3 uses the ContextTransactionSynchronizationRegistry
instead of the
Is there a WildFly service that represents the
lifecycle? The JPA persistence unit service (or global JPA service)
should depend on that service, so that applications undeploy if the TSR
 is also related to the the  effort and would be impacted by the
above mentioned changes.
 EntityManager caching https://issues.jboss.org/browse/WFLY-11233
 Ensure that Hibernate uses direct reference to TSR for better
When an agent starts up with the JVM (through premain()) we can specify in
the command to start up jboss, classes to be added to jboss system packages
by setting the above property.
I am looking to replicate the effect of setting that system property after
jboss has started up, i.e, an agent will be loaded through agentmain()
after jboss is up and running.
All help is appreciated.
Thanks and Regards
Is it possible to put only root CA's certificate in the server truststore
and to let users authenticate with certificates signed by this CA?
Currently, it throws an error when it tries to bind decoded user principal
to the alias in truststore, which has only CA's certificate.
I suppose this is possible, but is there any easy(detailed) tutorial on this
since I'm not familiar with the whole architecture of the Elytron, and
documentation is pretty modest?
I apologize if this not the correct forum to post this question, but I
tried looking at the Weld forums and everything appears dormant (even the
link to the user's forum is 404 on the Weld site). So I suspected this
would be the second best place to ask for some clarity.
I'm trying to understand the sequencing of CDI events vs bean
initialization. I'm currently concentrating on CDI 1.2/Weld 2.3.5, but
figure that this information will be applicable to CDI2.0 as well. I've
tried finding documentation online and posting on StackOverflow and neither
have produced any results. Specifically, I am confused about the
sequencing of CDI events vs when/how bean methods are called. Given what I
have read, the following are the events that are triggered by the CDI
- ProcessAnnotatedType and ProcessSyntheticAnnotatedType
- ProcessInjectionTarget and ProcessProducer
- ProcessBean, ProcessManagedBean, ProcessSessionBean,
ProcessProducerMethod and ProcessProducerField
Given these events, when are the events which produce
and @Destroyer(ApplicationScoped.class) triggered? In which part of the
lifecycle? Are they triggered in the @PostConstruct equivalent of the
Scoping bean (what is the bean backing the ApplicationScope? I cannot find
the implementation in the Weld core - am I even looking in the right
Which brings me to the next question - in which stage of the container
setup are the @PostConstruct methods on the beans called? Are they called
in the `AfterDeploymentValidation` phase? Or is it somewhat asynchronous -
in that the @PostConstruct of an ApplicationScoped bean will be called only
when initialized; and that could happen during any of the stages? From
what I understand, the BeanManager.getReference() is not allowed prior to
the AfterDeploymentValidation event being fired, which to me would imply
that beans can only be instantiated (and therefore @PostConstruct'ed) after
the `AfterDeploymentValidation` phase.
Can anyone direct me towards some clarification of these points? I've
tried reading the CDI 1.2 user guide (
https://docs.jboss.org/cdi/learn/userguide/CDI-user-guide.html), but that
hasn't provided the details I am looking for. Additionally, I've tried
reading through the Weld code but can't find the answers I'm looking for.
there's a request to simplify jboss-ejb-client configuration:
The issue specifically deals with setting "maximumConnectedClusterNodes", which
is not possible to set via wildfly-config.xml and neither via
(The old client accepted property
jboss-ejb-client.properties, but it's not recognized by the current client.)
I pointed out in the ticket that setting maximumConnectedClusterNodes is
possible via programmatic API, like:
EJBClientContext context = new EJBClientContext.Builder()
// lookup etc...
but Jorg considers that to be a workaround and thinks that "simple property
given to the InitialContext should be sufficient".
Now to the solutions:
1) I don't think that passing configuration properties directly to the
InitialContext is the way we want to support. At least I didn't see that
anywhere in current docs, and I didn't see any code (in ejb client) that would
provide for that. Correct?
2) I would like to fix current client to again support
"remote.cluster.xxx.max-allowed-connected-nodes" in jboss-ejb-client.properties.
3) Is it desirable to extend wildfly-config.xml schema to support more config
Software Engineer, JBoss SET
Just a quick reminder that the WildFly 15 feature freeze is next Wednesday
14 November. After that we will only accept bug fixes until the tag which
is planned on 28th November.
For WildFly Core RFEs this effectively means the cut-off is the end of this
I want to play a bit with Slack. I see https://wildfly.slack.com is already
taken, and that is where it makes most sense to play. If anybody here owns
that, can you invite me and make me an admin?