WF10 Deployment Changes
by Jason T. Greene
Currently we are a bit inconsistent with whether or not partial deployment services are allowed to restart. This is because most require metadata that is intended to be temporary and is intended to be wiped out at the end of deployment. A major exception is JPA which is holding on to jandex annotation indexes, so that if its underlying JCA datasource bounces, it's able to restart.
This is bad though because it wastes more memory than is actually needed (the state that JPA requires is less …
[View More]than the combined state of all annotation indexes and other deployment info). It's particular bad when we upgrade to jandex 2 since it stores a lot more information (generics, all method and field signatures, type annotations etc).
IMO based on this inconsistency and the time we have on the schedule, I think we need to momentarily suspend the not really attained goal of partial restart-ability. We should change JPA to stop keeping a hard reference to the indexes, and once that service goes down, a full redeployment is required. Stuart has a hack that can restart this automatically as part of a listener. We should probably look at extending this further.
Longer term I think we need to redesign the deployment service hierarchy to better represent the reality that restarting a portion deployment requires rerunning the initial scanning phases.
Thoughts?
Sent from my iPhone
[View Less]
10 years
problem binding to JNDI in subsystem extension
by John Mazzitelli
I have a custom subsystem extension I'm deploying in Wildfly 8.2. I hit a problem when trying to bind an object to JNDI.
In my AbstractAddStepHandler.performRuntime() (the Subsystem Add handler), I want to bind an object to JNDI, like this:
InitialContext initialContext = new InitialContext();
WritableServiceBasedNamingStore.pushOwner(context.getServiceTarget());
try {
initialContext.bind(jndiName, jndiObject); // <--- this sometimes throws exception you see below
} …
[View More]finally {
WritableServiceBasedNamingStore.popOwner();
}
where "context" is the first parameter passed to the performRuntime() method, and "jndiName" is "java:global/example/demo/myname" and "jndiObject" is just a java.lang.String, like "hello".
The use of WritableServiceBasedNamingStore is recommended on the wiki: https://docs.jboss.org/author/display/WFLY8/JNDI+Reference - though I have no idea what it is doing :)
The problem is - each time I start my wildfly server, sometimes it works, other times it doesn't. It is as if there is a race condition somewhere on startup of the wildfly server. If it works, my JNDI object is bound properly; when it fails, this bombs with the exception I show below.
Anyone know what the problem is and how to fix?
====
javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662) [rt.jar:1.8.0_31]
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) [rt.jar:1.8.0_31]
at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:350) [rt.jar:1.8.0_31]
at javax.naming.InitialContext.bind(InitialContext.java:425) [rt.jar:1.8.0_31]
at org.demo.extension.SubsystemAdd.performRuntime(SubsystemAdd.java:153)
at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:75) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:660) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:501) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:298) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:293) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:354) [wildfly-controller-8.2.0.Final.jar:8.2.0.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_31]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_31]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
[View Less]
10 years
How to make a service MBean depend on singleton stateless session bean using jboss-service.xml in wildfly 8
by sridhar thiyagarajan
Hi,
I am trying to make a service mbean depend on a singleton stateless session
bean by configuring in *jboss-service.xml *using *<depends> *in *wildfly AS
8 *but getting the below error:
*ERROR [org.jboss.as.controller.management-operation] (Controller Boot
Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment"
=> "TestEAR.ear")]) - failure description: {"JBAS014771: Services with
missing/unavailable dependencies" =>
["jboss.mbean.service.TestService.start …
[View More]is missing
[jboss.mbean.service.\"jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3\".start]","jboss.mbean.service.TestService.create
is missing
[jboss.mbean.service.\"jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3\".create]"*
Please find below the details on the code employed: Please help me to
resolve the error. Many thanks.
*project structure*
TestEAR (ear)
--- module-A (ejb jar containing singleton stateless session bean)
--- module-B (jar containing service mbean)
--- meta-inf/jboss-service.xml
*singleton stateless session bean (under module-A JAR)*
@Local(TestLocal.class)
@Resource(name="TestConfig", mappedName="java:/ConnectionFactory")
public class TestConfig {
... code ...
}
*jboss-service.xml (under meta-inf folder in TestEAR.ear)*
<server>
<mbean code="com.test.TestService" name="TestService">
<depends>jboss.j2ee:ear=TestEAR.ear,jar=module-A.jar,name=TestConfig,service=EJB3</depends>
</mbean>
*TestService.java (MBean) (under module-B JAR)*
public class TestService extends ServiceMBeanSupport implements TestMBean {
protected void startService() throws Exception {
...code...
}
protected void stopService() throws Exception {
...code...
}
protected void createService() throws Exception {
...code...
}
protected void destroyService() throws Exception {
...code...
}
}
*TestMBean.java (MBean interface) (under module-B JAR)*
public interface TestMBean extends org.jboss.system.ServiceMBean { }
Thanks.
Sridhar Thiyagarajan
[View Less]
10 years
Early Access builds for JDK 9 b53 and JDK 8u60 b05 are available on java.net
by Rory O'Donnell
Hi Jason/Tomaz,
Early Access build for JDK 9 b53 <https://jdk9.java.net/download/>
available on java.net, summary of changes are listed here
<http://www.java.net/download/jdk9/changes/jdk9-b53.html>
Early Access build for JDK 8u60 b05 <http://jdk8.java.net/download.html>
is available on java.net, summary of changes are listed here.
<http://www.java.net/download/jdk8u60/changes/jdk8u60-b05.html>
I'd also like to use this opportunity to point you to JEP 238:
Multi-…
[View More]Version JAR Files [0],
which is currently a Candidate JEP for JDK 9.
It's goal is to extend the JAR file format to allow multiple, JDK
release-specific versions of class
files to coexist in a single file. An additional goal is to backport the
run-time changes to
JDK 8u60, thereby enabling JDK 8 to consume multi-version JARs. For a
detailed discussion,
please see the corresponding thread on the core-libs-dev mailing list. [1]
Please keep in mind that a JEP in the Candidate state is merely an idea
worthy of consideration
by JDK Release Projects and related efforts; there is no commitment that
it will be delivered in
any particular release.
Comments, questions, and suggestions are welcome on the corelibs-dev
mailing list. (If you
haven’t already subscribed to that list then please do so first,
otherwise your message will be
discarded as spam.)
Rgds,Rory
[0] http://openjdk.java.net/jeps/238
[1]
http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-February/031461...
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
[View Less]
10 years
Heads up on JBoss Logger 3.2 : more changed than what it looks like
by Sanne Grinovero
Hi all,
today I've upgraded jboss-logging from version 3.1.4.GA to 3.2.1.Final
in an Hibernate project, and got some integration test failures.
The surprising aspect is that everything seemed fine at compile level:
just switch the version in the pom, and without needing any further
changes it compiles fine and runs all unit tests successfully.. but
fails when using the freshly built libraries in WildFly 8.2.
It's not a regression of jboss-logging, but one of its improvements
require a bit of …
[View More]attention.
This is what happened to us:
we have some log statements which look like this in source code (after
simplifying):
int i = ...
log.debugf( "Number: %d", i );
This does of course compile fine in both old an new versions of JBoss
Logger. And it all works as expected in unit tests.
But when deploying the modified version of this Hibernate library in
WildFly 8.2, you'd get some of these:
- java.lang.NoSuchMethodError:
org.hibernate.search.util.logging.impl.Log.debugf(Ljava/lang/String;J)V"}}
When using the older version of JBoss Logger (at compile time), the
above line of code is compiled as an invocation to:
void debugf(String format, Object param1);
(which is a method present in both versions)
When using the new version of JBoss Logger (at compile time), the same
line of code is interpreted as the (better) invocation to:
void debugf(String format, int arg);
So that's what the library is going to invoke at runtime - and that
method doesn't exist in WildFly 8.2.
Be aware of this when upgrading as it might look like a trivial
version bump but it makes it quite hard to guarantee backwards
compatibility with older versions of the logger.
Personally since I want to upgrade the logger but don't want to drop
compatibility with existing WildFly releases, I'm trying to figure how
to reliably validate that no logging statement is going to invoke one
of the new ones.. for now.
I guess this also means that users won't actually benefit from the
better performance of the new logging methods until we recompile all
of its client libraries using the new version ;-)
Auto-boxing is evil..
Sanne
[View Less]
10 years, 1 month
