[wildfly-dev] Reading Mgt Model from a Servlet
Brian Stansberry
brian.stansberry at redhat.com
Thu Jul 14 11:08:28 EDT 2016
The DUP approach you mention may be best anyway. If we add a mechanism to do an async read of the model held by an uncommitted op, the hook to let your initializer do that will very likely involve a DUP passing in some object anyway. To avoid that there would need to be some “read uncommitted” API added to ModelController that anyone could use.
> On Jul 14, 2016, at 9:41 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>
> 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 at gmail.com <mailto:tomaz.cerar at gmail.com>> wrote:
>>
>>
>> On Wed, May 27, 2015 at 12:17 AM, Stan Silvert <ssilvert at redhat.com <mailto:ssilvert at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160714/98582924/attachment.html
More information about the wildfly-dev
mailing list