You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2008/06/04 03:54:31 UTC
Crazy idea: Context.bind co-opting
This idea just popped into my head and I'm interested in thoughts.
So I've been racking my brain all throughout the 3.x cycle on a
possible good way to get an injection service of some kind into the
mix. Something that would allow you to annotate a test case for
example and say "inject me". Same would go for a standalone app
client or any object really.
We could of course make a class for this say InjectionManager.class
with a method "public void inject(Object o)" but who wants to bind
themselves directly to org.apache.openejb.* classes -- I wouldn't.
Then suddenly this came to me....
The javax.naming.Context.bind(*) methods are off limits anyway for EJB-
land, they don't do anything... So... what if we started co-opting it
for our own evil purposes :) We could start designating special names
that if you "bind" to them will perform specific operations.
Say for example:
context.bind("<some-standard-prefix>/inject", myObject);
We'd take the myObject, scrape the annotations and inject everything
we could into the myObject instance.
Thoughts?
-David
Re: Crazy idea: Context.bind co-opting
Posted by Dain Sundstrom <da...@iq80.com>.
On Jun 3, 2008, at 6:59 PM, David Blevins wrote:
> Possibly going totally off into crazy-land, we could expose other
> apis in this JNDI-RESTful way.
>
> context.bind("<some-standard-prefix>/deploy", myFile);
Very interesting.
> context.bind("<some-standard-prefix>/undeploy", myFile);
If this is rest-like wouldn't we use unbind?
> If we ever get support for manipulating containers or resources at
> runtime, we could even do:
>
> context.bind("<some-standard-prefix>/system/<id>.<property>",
> <value>);
>
> As in:
>
> context.bind("<some-standard-prefix>/system/myContainer.PoolSize",
> 100);
>
> ---
>
> We could also support querying in this sort of JNDI-RESTful way.
> Say for example:
>
> Integer poolSize = (Integer) context.lookup("<some-standard-prefix>/
> system/myContainer.PoolSize");
>
> ---
>
> Certainly, interesting.
Definitely.
-dain
Re: Crazy idea: Context.bind co-opting
Posted by David Blevins <da...@visi.com>.
On Jun 4, 2008, at 5:17 PM, Karan Malhi wrote:
> Point is, if users could create classes which contained public
> fields (or
> properties) which had standard names (same as the properties used in
> the
> Resource element), then they do not need the openejb api to create a
> resource at runtime.
Oh, now that's also a *very* interesting take on how to get the data
passed in.
-David
Re: Crazy idea: Context.bind co-opting
Posted by Karan Malhi <ka...@gmail.com>.
I think this is a great idea!!. I recently saw a post where somebody was
asking about how to add a resource at runtime. This idea of a RESTful JNDI
would allow us to do something like
com.companyA.DataResource dataSource = new com.companyA.DataResource();
dataSource.id = "DataSource";
dataSource.jdbcUrl = "jdbc:derby://localhost/xyz";
...
...
context.bind("custom/resource/myDataSource",dataSource);
And some other user might be able to do something like:-
com.companyB.Resource res = new com.companyB.Resource();
res.id = "DataSource";
res.jdbcUrl = "jdbc:derby://localhost/xyz";
...
...
context.bind("custom/resource/myDS",res);
Point is, if users could create classes which contained public fields (or
properties) which had standard names (same as the properties used in the
Resource element), then they do not need the openejb api to create a
resource at runtime.
I think this thing can grow to something really really powerful.
On Tue, Jun 3, 2008 at 9:59 PM, David Blevins <da...@visi.com>
wrote:
>
> On Jun 3, 2008, at 6:54 PM, David Blevins wrote:
>
> This idea just popped into my head and I'm interested in thoughts.
>>
>> So I've been racking my brain all throughout the 3.x cycle on a possible
>> good way to get an injection service of some kind into the mix. Something
>> that would allow you to annotate a test case for example and say "inject
>> me". Same would go for a standalone app client or any object really.
>>
>> We could of course make a class for this say InjectionManager.class with a
>> method "public void inject(Object o)" but who wants to bind themselves
>> directly to org.apache.openejb.* classes -- I wouldn't. Then suddenly this
>> came to me....
>>
>> The javax.naming.Context.bind(*) methods are off limits anyway for
>> EJB-land, they don't do anything... So... what if we started co-opting it
>> for our own evil purposes :) We could start designating special names that
>> if you "bind" to them will perform specific operations.
>>
>> Say for example:
>>
>> context.bind("<some-standard-prefix>/inject", myObject);
>>
>> We'd take the myObject, scrape the annotations and inject everything we
>> could into the myObject instance.
>>
>>
> Possibly going totally off into crazy-land, we could expose other apis in
> this JNDI-RESTful way.
>
> context.bind("<some-standard-prefix>/deploy", myFile);
> context.bind("<some-standard-prefix>/undeploy", myFile);
>
> If we ever get support for manipulating containers or resources at runtime,
> we could even do:
>
> context.bind("<some-standard-prefix>/system/<id>.<property>", <value>);
>
> As in:
>
> context.bind("<some-standard-prefix>/system/myContainer.PoolSize", 100);
>
> ---
>
> We could also support querying in this sort of JNDI-RESTful way. Say for
> example:
>
> Integer poolSize = (Integer)
> context.lookup("<some-standard-prefix>/system/myContainer.PoolSize");
>
> ---
>
> Certainly, interesting.
>
> -David
>
>
--
Karan Singh Malhi
Re: Crazy idea: Context.bind co-opting
Posted by David Blevins <da...@visi.com>.
On Jun 3, 2008, at 6:54 PM, David Blevins wrote:
> This idea just popped into my head and I'm interested in thoughts.
>
> So I've been racking my brain all throughout the 3.x cycle on a
> possible good way to get an injection service of some kind into the
> mix. Something that would allow you to annotate a test case for
> example and say "inject me". Same would go for a standalone app
> client or any object really.
>
> We could of course make a class for this say InjectionManager.class
> with a method "public void inject(Object o)" but who wants to bind
> themselves directly to org.apache.openejb.* classes -- I wouldn't.
> Then suddenly this came to me....
>
> The javax.naming.Context.bind(*) methods are off limits anyway for
> EJB-land, they don't do anything... So... what if we started co-
> opting it for our own evil purposes :) We could start designating
> special names that if you "bind" to them will perform specific
> operations.
>
> Say for example:
>
> context.bind("<some-standard-prefix>/inject", myObject);
>
> We'd take the myObject, scrape the annotations and inject everything
> we could into the myObject instance.
>
Possibly going totally off into crazy-land, we could expose other apis
in this JNDI-RESTful way.
context.bind("<some-standard-prefix>/deploy", myFile);
context.bind("<some-standard-prefix>/undeploy", myFile);
If we ever get support for manipulating containers or resources at
runtime, we could even do:
context.bind("<some-standard-prefix>/system/<id>.<property>",
<value>);
As in:
context.bind("<some-standard-prefix>/system/myContainer.PoolSize",
100);
---
We could also support querying in this sort of JNDI-RESTful way. Say
for example:
Integer poolSize = (Integer) context.lookup("<some-standard-prefix>/
system/myContainer.PoolSize");
---
Certainly, interesting.
-David