Activation config annotation property replacement
by luca boncompagni
Hi to all,
I need to be able to do property replacement inside an MDB, for instance:
@MessageDriven(activationConfig = {
@ActivationConfigProperty(
propertyName = "destinationLookup",
propertyValue = "java:global/jms/myAsyncQueue${short-postfix}"
),
@ActivationConfigProperty(
propertyName="connectionFactoryLookup",
propertyValue="java:jboss/exported/jms/RemoteConnectionFactory"
)
})
public class TestMDB implements MessageListener {
I do this small patch:
diff --git
a/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/MessageDrivenComponentDescriptionFactory.java
b/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/MessageDrivenComponentDescriptionFactory.java
index 5d01865..7494d0f 100644
---
a/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/MessageDrivenComponentDescriptionFactory.java
+++
b/ejb3/src/main/java/org/jboss/as/ejb3/deployment/processors/MessageDrivenComponentDescriptionFactory.java
@@ -52,6 +52,9 @@
import org.jboss.metadata.ejb.spec.ActivationConfigPropertyMetaData;
import org.jboss.metadata.ejb.spec.EnterpriseBeanMetaData;
import org.jboss.metadata.ejb.spec.MessageDrivenBeanMetaData;
+import org.jboss.metadata.property.PropertyReplacer;
+import org.jboss.metadata.property.PropertyReplacers;
+import org.jboss.metadata.property.PropertyResolver;
import org.jboss.msc.service.ServiceController;
import org.jboss.msc.service.ServiceName;
import org.jboss.msc.service.ServiceRegistry;
@@ -108,7 +111,9 @@
final MessageDrivenBeanMetaData beanMetaData =
getEnterpriseBeanMetaData(deploymentUnit, beanName,
MessageDrivenBeanMetaData.class);
final String beanClassName;
final String messageListenerInterfaceName;
- final Properties activationConfigProperties =
getActivationConfigProperties(messageBeanAnnotation);
+ final PropertyResolver propertyResolver =
deploymentUnit.getAttachment(org.jboss.as.ee.metadata.property.Attachments.FINAL_PROPERTY_RESOLVER);
+ final PropertyReplacer propertyReplacer =
PropertyReplacers.resolvingReplacer(propertyResolver);
+ final Properties activationConfigProperties =
getActivationConfigProperties(messageBeanAnnotation, propertyReplacer);
final String messagingType;
if (beanMetaData != null) {
beanClassName = override(beanClassInfo.name().toString(),
beanMetaData.getEjbClass());
@@ -244,13 +249,13 @@
addComponent(deploymentUnit, mdbComponentDescription);
}
- private Properties getActivationConfigProperties(final
AnnotationInstance messageBeanAnnotation) {
+ private Properties getActivationConfigProperties(final
AnnotationInstance messageBeanAnnotation, PropertyReplacer
propertyReplacer) {
final Properties props = new Properties();
final AnnotationValue activationConfig =
messageBeanAnnotation.value("activationConfig");
if (activationConfig == null)
return props;
for (final AnnotationInstance propAnnotation :
activationConfig.asNestedArray()) {
- props.put(propAnnotation.value("propertyName").asString(),
propAnnotation.value("propertyValue").asString());
+ props.put(propAnnotation.value("propertyName").asString(),
propertyReplacer.replaceProperties(propAnnotation.value("propertyValue").asString()));
}
return props;
}
Do you have any suggestions?
Luca
10 years, 5 months
deployment-scanner rollback behavior change
by Emanuel Muckenhuber
As part of WFLY-364 [1] we changed the default behavior of the
deployment-scanner to not rollback on deployment failures.
The main reason behind this is that a deployment failure would also
trigger the rollback of a potentially unrelated deployment, if it's
deployed as part of the same "scan". This basically means failed
deployments remain visible through the management model in in a failed
state. This is also the same behavior used when booting WildFly.
Beside that we still write the appropriate .failure marker for the
failed deployment(s), so there should be no other impact from a user
POV. There is also a configuration attribute in the deployment-scanner
subsystem to disable this if this is not wanted.
Given that changes to the deployment-scanner often caused issues for
people, i wanted to double check that there are not objections to this.
Thanks,
Emanuel
[1] https://issues.jboss.org/browse/WFLY-364
10 years, 5 months
CLI Default Controller / Protocol and additional Aliases
by Darran Lofthouse
Hello,
Could someone please take a look into the following pull request
following the discussion we had here on default address handling within
the CLI: -
https://github.com/wildfly/wildfly/pull/5435
I now have an additional set of changes almost ready to send over
regarding HTTP Upgrade and SSL but really it is partially going to be
built on these changes so would like to get this one in first.
Regards,
Darran Lofthouse.
10 years, 5 months
Adding attributes where the default value is different from the legacy implied behaviour
by Kabir Khan
The https://github.com/wildfly/wildfly/pull/5460 (and the linked PR within) below illustrates the ‘problem’. Although Infinispan is where this popped up, this is bound to have happened in other places as well.
The latest version of the infinispan subsystem adds a boolean ‘statistics’ which allows us to turn off statistics gathering in the infinispan subsystem. Previously this was always on, i.e. ’true’. We want the user to have to explicitly turn it on, so its default value is ‘false’.
However, in the old parsers, it struck me that they do not expose this attribute in their versions of the xsd, and so they before https://github.com/wildfly/wildfly/pull/5460 would have ended up always not setting the attribute, which means ‘false’. This is different behaviour than running the old xml in an older version of AS where this would have resulted in ‘true’, hence this fix.
10 years, 5 months
Re: [wildfly-dev] [jboss-as7-dev] how to set context path in jboss AS 7
by weiqigao＠gmail.com
Hi jboss-as-7-dev (and wildfly-dev),
I signed up to the mailing lists to follow up on a post made on Fri Apr 20 05:13:56 EDT 2012 by Tom Fonteyne (tom.fonteyne at redhat.com):
http://lists.jboss.org/pipermail/jboss-as7-dev/2012-April/005870.html
> you'll need to do this on a per application basis now :(
>
> On 04/19/2012 07:44 PM, M. Steven wrote:
> >Hi,
> >>I am working on migrating an app from jboss 4.2 to 7.1.x. We used to
> > >map our static files using server.xml under jboss-web.deployer.
> > >Doing something like:
> > ><Context path="/photo" docBase="c:/test/images" reloadable="true"
> > >override="true">
> > ></Context>
> >>within server.xml.
> >>Now I can not figure out how to do it within Jboss AS 7. Can someone
> > >please help me on the issue?
> >>Thanks in advance.
> >>Regards,
> >>Mike
> --
> Tom Fonteyne
> Red Hat - UK
> EMEA GSS-SEG-Middleware
I have a client that is dealing with the same JBoss 4.2.x to JBoss 7.1.x migration issue, and I would appreciate it if a pointer can be given as to *How* to do this on a per application basis in JBoss AS 7.1.x. Similar questions on the JBoss.org forums and on StackOverflow are either Not Answered or provide answers that does not address exactly the same problem.
The desired result is to have JBoss AS 7.1.x installed in one location on a host my-host, say, in /opt/appservers/jboss-as-7.1.x, and store some static web files (HTML files, images, and some such) in another location on the same host, say, in /var/myapp/{foo.html,picture.png, etc.}, and have JBoss configured so that the static files can be accessed through the JBoss AS 7.1.x instance at some URL, say, http://my-host:8080/photo/{foo.html,picture.png, etc.} .
My current understanding of the situation is that the configuration/static-resources element in subsystem:web section of the standalone.xml (or domain.xml) file is used to control how static resources are handled within all deployed webapps. But that applies only to the static resources that are part of the deployment (things that’s in the *.war file or exploded directory).
Is there an easy way to achieve what I wanted with JBoss AS 7.1.x configuration?
This issue constitutes lost functionality from an earlier version of JBoss to JBoss AS 7.1.x. Is the elimination of the functionality intentional or merely a side effect of the changing configuration mechanism? Is it the case that the underlying web container, (JBoss Web 7.0.14 I believe), still supports this functionality? If so, are there plans to expose this functionality through some new element in the JBoss AS 7.1.x configuration files?
How will WildFly behave with regard to this scenario?
Regards,
--
Weiqi Gao
weiqigao(a)gmail.com
http://weiqigao.blogspot.com/
10 years, 5 months
Thread Pools
by James R. Perkins
Why do we include thread pools in the extensions that need them rather
than have a central place to configure them? I'm sure there is a reason
and I think I even asked before on IRC. I just don't remember the answer.
--
James R. Perkins
Red Hat JBoss Middleware
10 years, 5 months
WildFly Jira links in PRs
by Kabir Khan
To slightly relieve the burden on the mergers, it would be helpful if when opening a WFLY pull request, if you could include the links to the JIRA issues solved by your pull request.
This is not a hard requirement like for product, since there is no process in play here. Still, when reviewing and wanting to merge something where the issue is not so known to whoever merges, it would help streamline things a bit to be able to simply click a link rather than having to find the issue manually from the issue id.
10 years, 5 months
ClassCastException when get Object from Replicated Cache after redeploy
by Domenico Briganti
Hi all,
I'm using an Infinispan Replicated cache with WildFly Beta 1. It happen
that when I get a value from cache after a redeploy a get a
ClassCastException:
a.b.C cannot be cast to a.b.C.
Certainly this is for modular class loader of WildFly.
Now I resolved the issue cloning the object on ClassCastException:
try {
AuthUserEntry authUserEntry = getCache().get(key);
return authUserEntry;
} catch (ClassCastException e) {
return DeepCopy.copy(getCache().get(key));
}
Not so elegant, but it works.
There is a better solution?
Thank you,
Domenico
10 years, 5 months
Java EE 7 Hands-on Lab Deployment Report
by Arun Gupta
I deploy Java EE 7 hands-on lab
(https://github.com/arun-gupta/javaee7-hol) on WildFly beta2 snapshot.
This lab was built using GlassFish 4 and has been delivered multiple
times around the world. I'll prepare instructions on how to get this
lab working using WildFly. But first step is deployment on WildFly.
The deployment went through fine but several blocking issues.
1). Clicking on "Book a movie" scenario throws the following exception:
23:59:36,542 FATAL
[javax.enterprise.resource.webcontainer.jsf.context] (default task-8)
/booking/booking.xhtml @58,105 value="#{booking.movieId}": Target
Unreachable, identifier 'booking' resolved to null:
javax.faces.FacesException: /booking/booking.xhtml @58,105
value="#{booking.movieId}": Target Unreachable, identifier 'booking'
resolved to null
at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:84)
[jsf-impl-2.2.4-jbossorg-1.jar:]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
[jsf-impl-2.2.4-jbossorg-1.jar:]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
[jsf-impl-2.2.4-jbossorg-1.jar:]
Booking class looks like:
@Named
@FlowScoped("booking")
public class Booking {
...
}
2). Clicking on "Movie" menu item throws:
00:03:10,012 FATAL
[javax.enterprise.resource.webcontainer.jsf.context] (default task-9)
/client/movies.xhtml @59,78 items="#{movieClientBean.movies}":
javax.ws.rs.NotFoundException: HTTP 404 Not Found:
javax.el.ELException: /client/movies.xhtml @59,78
items="#{movieClientBean.movies}": javax.ws.rs.NotFoundException: HTTP
404 Not Found
3). "Sales" scenario uses Batch APIs and that worked fine.
4). "Points" scenario uses JMS2. Sending a message seems to work but
consuming a single message seems to clear up the entire queue.
5). Not able to test the WebSocket scenario because of legacy browsers
on this loaner laptop. Can somebody try it and let me know if it works
?
Thanks,
Arun
--
http://blog.arungupta.me
http://twitter.com/arungupta
10 years, 5 months
