So you want to invoke a :read-attribute management op from a servlet initializer?
That shouldn’t deadlock, as it’s a read that won’t need the exclusive management lock that
the thread controlling the deploy controls.
It won’t see the correct value at boot though, or in any composite op (e.g. CLI batch)
where the attribute you are reading has been modified in the same overall op as the deploy
step. That change is not visible to other threads until the op that made it commits. And
it won’t commit until deploy completes.
On May 28, 2015, at 5:37 AM, Tomaž Cerar
<tomaz.cerar(a)gmail.com> wrote:
On Wed, May 27, 2015 at 12:17 AM, Stan Silvert <ssilvert(a)redhat.com
<mailto:ssilvert@redhat.com>> wrote:
Thanks. I just need the servlet to read a flag that I put into the
owner attribute of the deployment. So I should be OK.
Incidentally, I find that this is something I run into once in awhile.
I need a subsystem to communicate with a deployment's application code.
The other way I've done this is to stuff things into the ServletContext
using a DeploymentUnitProcessor and the JBossWebMetaData.
If anyone knows a third option I'd love to hear it.
The DPU with extra jbossmetadata sounds a reasonable way to do this.
you could even go further and provide this data only to your servlet instead whole
ServletContext
but if all you need is to pass one attribute around, no need to complicate it more.
--
tomaz
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat