[
https://issues.apache.org/jira/browse/OPENEJB-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416379#comment-13416379
]
David Blevins commented on OPENEJB-127:
---------------------------------------
Marked as "Won't Fix" as it was never implemented. We can still do it if
someone wants it. The basic functionality would have gone like this:
in web.xml or ejb-jar.xml:
{code:xml}
<env-entry>
<env-entry-name>myServerLocation</env-entry-name>
<env-entry-value>192.168.0.42</env-entry-value>
<env-entry-type>java.net.InetAddress</env-entry-type>
</env-entry>
{code}
Then you could look that up as an java.net.InetAddress with the following:
{code}
InetAddress address = (InetAddress) new
InitialContext().lookup("java:comp/env/myServerLocation");
{code}
Currently, it is not possible to do this lookup as the <env-entry-type> of
InetAddress is not supported.
What is implemented makes it possible to use the <env-entry-type> of
java.lang.String and have the value converted automatically on injection:
{code}
@Resource(name="myServerLocation)
private InetAddress address;
{code}
When the bean is injected xbean-finder will see the data types don't match and
convert the String to an InetAddress. However the type in JNDI will still be a
String and this conversion will happen on the creation of every new bean that
has "myServerLocation" injected as something other than String.
This issue was about eagerly converting the String to InetAddress just once
when it is bound to JNDI allowing for lookups of InetAddress to occur as well
as skipping the on-the-fly conversion done on each bean creation.
We can still add it if anyone wants, but it seems unlikely.
> Expanded types for env-entries in JNDI
> --------------------------------------
>
> Key: OPENEJB-127
> URL: https://issues.apache.org/jira/browse/OPENEJB-127
> Project: OpenEJB
> Issue Type: Wish
> Components: container system, deployment
> Affects Versions: 3.1.x
> Reporter: David Blevins
> Assignee: Mohammad Nour
> Fix For: 3.1.x
>
>
> If you have a properties editor for it. We'll support it.
> Build-in support should include these extended <env-entry-type> values:
> java.math.BigDecimal
> java.math.BigInteger
> java.lang.Class
> java.util.Date
> java.io.File
> java.net.InetAddress
> java.net.Inet4Address
> java.net.Inet6Address
> javax.management.ObjectName
> java.util.Properties
> java.net.URI
> java.net.URL
> ... as well as arrays, lists, or maps of any of the above.
> xbean-reflect has all of these editors so implementing this is initially a
> matter of simply plumbing in support for reusing that property editor support.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
