JPA container and IronJacamar Synchronizations are registered using org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry but the Hibernate ORM Synchronizations are registered via org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper
by Scott Marlow
Hi,
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 [1] 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. [2] shows that the JCA + JPA
Synchronizations are registered via
org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry
and Hibernate ORM Synchronization is registered via the
org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper
Should
org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry
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
org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper?
Is there a WildFly service that represents the
org.wildfly.transaction.client.ContextTransactionSynchronizationRegistry
lifecycle? The JPA persistence unit service (or global JPA service)
should depend on that service, so that applications undeploy if the TSR
is stopped.
[3] is also related to the the [1] effort and would be impacted by the
above mentioned changes.
Scott
[1] EntityManager caching https://issues.jboss.org/browse/WFLY-11233
[2] https://paste.fedoraproject.org/paste/-wHaYB3mzR2yTXTfU3LbZA
[3] Ensure that Hibernate uses direct reference to TSR for better
performance https://issues.jboss.org/browse/WFLY-11243
6 years
-Djboss.modules.system.pkgs=class1, class2 runtime equivalent
by Sam Thomas
Hi guys!
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
Sam Thomas
6 years
Elytron 4.0 (Wildfly 14)
by Nikola Malenic
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?
6 years
WELD/CDI event clarifications
by Eric B
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
container:
- BeforeBeanDiscovery
- ProcessAnnotatedType and ProcessSyntheticAnnotatedType
- AfterTypeDiscovery
- ProcessInjectionTarget and ProcessProducer
- ProcessInjectionPoint
- ProcessBeanAttributes
- ProcessBean, ProcessManagedBean, ProcessSessionBean,
ProcessProducerMethod and ProcessProducerField
- ProcessObserverMethod
- AfterBeanDiscovery
- AfterDeploymentValidation
- BeforeShutdown
Given these events, when are the events which produce
@Initialized(ApplicationScoped.class)
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
place?)?
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.
Thanks,
Eric
6 years
JDK 12 , JDK 8u202 & Project Panama Early-Access builds available
by Rory O'Donnell
Hi David & Richard,*
*
*JDK 12 Early Access build 19 is available at : - jdk.java.net/12/*
* These early-access, open-source builds are provided under the GNU
General Public License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Release Notes updates since last email
o Build 18 – JDK-8211883: Disable anon and NULL cipher suites
+ Crypto Roadmap
<https://java.com/en/jre-jdk-cryptoroadmap.html> Updated
o Build 17 – JDK-8211806: TLS 1.3 handshake server name indication
is missing on a session resume
o Build 16 – JDK-8211866: TLS 1.3 CertificateRequest message
sometimes offers disallowed signature algorithms
o Build 17 – JDK-8195793 : Remove GTE CyberTrust Global Root
o Build 16 - JDK-8191053 : Provide a mechanism to make system's
security manager immutable
* JEPs proposed for JDK 12 so far:
o JEP 230 - Microbenchmark Suite <https://openjdk.java.net/jeps/230>
* JEPs targeted to JDK 12, so far
o 325: Switch Expressions (Preview) <http://openjdk.java.net/jeps/325>
o 326: Raw String Literals (Preview)
<http://openjdk.java.net/jeps/326>
o 340: One AArch64 Port, Not Two <http://openjdk.java.net/jeps/340>
o 341: Default CDS Archives <http://openjdk.java.net/jeps/341>
*JDK 8u202 Early Access build 03 is available at : -
**http://jdk.java.net/8/*
* JDK 8u202 timeline is available [1]
o GA is scheduled for January 2019
*Project Panama Early-Access build 0 ***is available at : -
http://jdk.java.net/panama/
**
* Early access builds from Project Panama
<https://openjdk.java.net/projects/panama/>
* Early-access builds are provided under the GNU General Public
License, version 2, with the Classpath Exception
<http://openjdk.java.net/legal/gplv2+ce.html>.
* Feedback - Please send feedback via e-mail to
panama-dev(a)openjdk.java.net <mailto:panama-dev@openjdk.java.net>.
* To send e-mail to this address you must first subscribe to the
mailing list
<http://mail.openjdk.java.net/mailman/listinfo/panama-dev>.
*Crypto Roadmap Updated [2]
*
Rgds,Rory
[1] http://openjdk.java.net/projects/jdk8u/releases/8u202.html
[2] https://java.com/en/jre-jdk-cryptoroadmap.html
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
6 years
Standalone EJB client configuration - maximumConnectedClusterNodes
by Tomas Hofman
Hi,
there's a request to simplify jboss-ejb-client configuration:
https://issues.jboss.org/browse/JBEAP-15407
The issue specifically deals with setting "maximumConnectedClusterNodes", which
is not possible to set via wildfly-config.xml and neither via
jboss-ejb-client.properties.
(The old client accepted property
"remote.cluster.xxx.max-allowed-connected-nodes" in
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()
.setMaximumConnectedClusterNodes(5)
.addTransportProvider(new RemoteTransportProvider())
.build();
EJBClientContext.getContextManager().setDefault(context);
// 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
options?
Thanks!
--
Tomas Hofman
Software Engineer, JBoss SET
Red Hat
6 years
WildFly 15 Feature Freeze
by Kabir Khan
Hi all,
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
week.
Thanks,
Kabir
6 years, 1 month
Slack?
by Kabir Khan
Hi,
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?
Thanks,
Kabir
6 years, 1 month
