3:51 p.m.
Some time ago, John Mazzitelli wrote a blog on how to get a local
ModelControllerClient from within a servlet.
http://management-platform.blogspot.com/2012/07/co-located-management-cli...
Is there an easier way to do it these days?
I need to read the attributes under /deployment=mydeployment.war/. Is
there an easier way to do that from the WAR than using a
ModelControllerClient?
Thanks,
Stan
4:51 p.m.
Nope. Although I would use newCachedThreadPool instead, as the fixed thread pool of 5 is
just wasteful.
Keep in mind this API is not something we encourage people to use from deployments, as any
management op that acquires a write lock (some sort of modification), will deadlock the
server if it used in the initialization path of a deployment. For this reason, we don’t
publish it via any simple means
On May 26, 2015, at 3:51 PM, Stan Silvert <ssilvert(a)redhat.com>
wrote:
Some time ago, John Mazzitelli wrote a blog on how to get a local
ModelControllerClient from within a servlet.
http://management-platform.blogspot.com/2012/07/co-located-management-cli...
Is there an easier way to do it these days?
I need to read the attributes under /deployment=mydeployment.war/. Is
there an easier way to do that from the WAR than using a
ModelControllerClient?
Thanks,
Stan
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
5:17 p.m.
On 5/26/2015 5:51 PM, Jason Greene wrote:
Nope. Although I would use newCachedThreadPool instead, as the fixed
thread pool of 5 is just wasteful.
Keep in mind this API is not something we encourage people to use from deployments, as
any management op that acquires a write lock (some sort of modification), will deadlock
the server if it used in the initialization path of a deployment. For this reason, we
don’t publish it via any simple means
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.
> On May 26, 2015, at 3:51 PM, Stan Silvert
<ssilvert(a)redhat.com> wrote:
>
> Some time ago, John Mazzitelli wrote a blog on how to get a local
> ModelControllerClient from within a servlet.
>
http://management-platform.blogspot.com/2012/07/co-located-management-cli...
>
> Is there an easier way to do it these days?
>
> I need to read the attributes under /deployment=mydeployment.war/. Is
> there an easier way to do that from the WAR than using a
> ModelControllerClient?
>
> Thanks,
>
> Stan
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
5:37 a.m.
On Wed, May 27, 2015 at 12:17 AM, Stan Silvert <ssilvert(a)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
9:41 a.m.
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
10:08 a.m.
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(a)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(a)gmail.com
<mailto:tomaz.cerar@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 <mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat
5:44 p.m.
On Tue, 2015-05-26 at 16:51 -0500, Jason Greene wrote:
Keep in mind this API is not something we encourage people to use
from
deployments, as any management op that acquires a write lock (some
sort of modification), will deadlock the server if it used in the
initialization path of a deployment. For this reason, we don’t publish
it via any simple means
It is more than just the initialisation path you need to be worried
about. I'm not sure what the exact rule is, but it wouldn't surprise me
if it is "never block on a management op from any code the container has
called".
For example using a management op from a servlet service method (e.g.
doPost) is dangerous because there may be an op in progress that is
waiting for all servlet processing to finish before it does it's work.
--
James "Doc" Livingston <jlivings(a)redhat.com>
JBoss Support Engineering Group
9:26 a.m.
So now I need to do this from the Keycloak Server WAR. If I assume that
my Keycloak WAR is the only application running on WildFly, can I safely
use Mazzitelli's approach? I need to read and write the management
model from Keycloak.
On 5/26/2015 5:51 PM, Jason Greene wrote:
Nope. Although I would use newCachedThreadPool instead, as the fixed
thread pool of 5 is just wasteful.
Keep in mind this API is not something we encourage people to use from deployments, as
any management op that acquires a write lock (some sort of modification), will deadlock
the server if it used in the initialization path of a deployment. For this reason, we
don’t publish it via any simple means
> On May 26, 2015, at 3:51 PM, Stan Silvert <ssilvert(a)redhat.com> wrote:
>
> Some time ago, John Mazzitelli wrote a blog on how to get a local
> ModelControllerClient from within a servlet.
>
http://management-platform.blogspot.com/2012/07/co-located-management-cli...
>
> Is there an easier way to do it these days?
>
> I need to read the attributes under /deployment=mydeployment.war/. Is
> there an easier way to do that from the WAR than using a
> ModelControllerClient?
>
> Thanks,
>
> Stan
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3052
days inactive
3467
days old
7 comments
5 participants
participants (5)
-
Brian Stansberry -
James Livingston -
Jason Greene -
Stan Silvert -
Tomaž Cerar