How to resolve resource names in JavaEE

Home

News: How to resolve resource names in JavaEE

  1. How to resolve resource names in JavaEE (18 messages)

    In "How to resolve resource names with JNDI when using javax.annotation.Resource," Java EE evangelist Debu Panda walks through how Java EE resolves JNDI names with the @Resource annotation. The spec documents it, but not in easily understood language, so this is a welcomed blog entry.

    First he shows how the class name factors into the JNDI reference, and how to resolve that into a global JNDI name (using Oracle's mapping mechanism), and then shows how to do so with @Resource at the class level, which is similar to the older (classic?) way to use JNDI.

    Threaded Messages (18)

  2. we do it differently[ Go to top ]

    JBoss EJB 3.0 maps resources to global JNDI names using the mappedName() attribute of @Resource.

    So, if the global JNDI binding of our datasource was "java:/DefaultDS", then the annotation would look like this:


    public class MyBean {

       @Resource(mappedName="java:/DefaultDS") DataSource ds;
    }

    This can be overridden in ejb-jar.xml if desired:

    <resource-ref>
       <res-ref-name>
               org.jboss.MyBean/ds
       </res-ref-name>
       <res-type>javax.sql.DataSource</res-type>
       <res-auth>Container</res-auth>
       <mapped-name>java:/AnotherDS</mapped-name>
    </resource-ref>
  3. we do it differently[ Go to top ]

    JBoss EJB 3.0 maps resources to global JNDI names using the mappedName() attribute of @Resource.So, if the global JNDI binding of our datasource was "java:/DefaultDS", then the annotation would look like this:

    public class MyBean {
       @Resource(mappedName="java:/DefaultDS")
       DataSource ds;
    }

    This can be overridden in ejb-jar.xml if desired:

    <resource-ref>
       <res-ref-name>
           org.jboss.MyBean/ds
       </res-ref-name>
       <res-type>javax.sql.DataSource</res-type>
       <res-auth>Container</res-auth>
       <mapped-name>java:/AnotherDS</mapped-name>
    </resource-ref>
    When this bad habit of setting deployment configuration attributes at development time will stop ?
    We already have awful examples with ORM annotations for table names, table columns etc.
    Obviously WebServices (JAX-WS) cannot be less with endpoint specification.
    Now, JNDI.
    Annotations ? A gun (Uzi ?) in the hands of babies.

    Guido
  4. we do it differently[ Go to top ]

    When this bad habit of setting deployment configuration attributes at development time will stop ?We already have awful examples with ORM annotations for table names, table columns etc.Obviously WebServices (JAX-WS) cannot be less with endpoint specification.Now, JNDI.Annotations ? A gun (Uzi ?) in the hands of babies.

    Um. Dude.

    A JNDI name is a *logical name*! How can a logical name *possibly* be something that needs to change at deployment time??! LOL

    And, if you did for some strange bizarre reason, want to change the mappedName at deployment time, EJB lets you provide a partial XML deployment descriptor to override the annotation value!

    The same goes for table and column names (ie. they may be overridden in XML), which are another perfact example of something which almost *never* changes at deployment time.

    When are we going to get over this totally irrational fear of the new? ;)
  5. we do it differently[ Go to top ]

    The same goes for table and column names (ie. they may be overridden in XML), which are another perfact example of something which almost *never* changes at deployment time.
    Have you ever heard of name clash ?
    Never deployed a service in an existing DB ?
    Some DB might perform better with different mapping strategy.
    I am sure I can go on for a while.
    When are we going to get over this totally irrational fear of the new? ;)
    It is not a matter of fear of new.
    The problem, as usual, is not the gun, but the man (or the baby) behind.
    AFAIK, but I might be wrong, noone provides XML overriding
    in JPA. I think the same is in JAX-WS.
    Anyway, I think that it is conceptually wrong to put such infos in the source code.
    It doen't matter if you can override or not.
    It should not be there.

    Guido
  6. XML overriding in JPA[ Go to top ]

    AFAIK, but I might be wrong, noone provides XML overridingin JPA.

    Kodo certainly allows XML overriding of JPA annotations. And all implementations must do this in order to be spec-compliant (although it's anyone's guess as to whether or not the TCK, if such a beast is made available, will test that functionality).

    -Patrick

    --
    Patrick Linskey
    http://bea.com
  7. XML overriding in JPA[ Go to top ]

    AFAIK, but I might be wrong, noone provides XML overridingin JPA.
    Kodo certainly allows XML overriding of JPA annotations. And all implementations must do this in order to be spec-compliant (although it's anyone's guess as to whether or not the TCK, if such a beast is made available, will test that functionality).-Patrick-- Patrick Linskeyhttp://bea.com
    Yes, I guess (I am/was a happy Kodo JDO user) :))
    Anyway, what I am trying to point out is that the primary
    method should be XML, but this option is normally put
    in a corner.
    Maybe tools to generate XML from Annotations could mitigate
    the potential abuse.

    Guido.
  8. XML overriding in JPA[ Go to top ]

    blockquote>Maybe tools to generate XML from Annotations could mitigate the potential abuse.Guido.

    http://tools.hibernate.org support his, some people use it to get annotations in development on JDK 5 but then deploy XML files on their outdated IBM server that works only with JDK 1.3.
  9. XML overriding in JPA[ Go to top ]

    And all implementations must do this in order to be spec-compliant (although it's anyone's guess as to whether or not the TCK, if such a beast is made available, will test that functionality)
    Why should the TCK *not* be made available ? If it isn't then the final spec cannot be released, according to JCP rules. I don't see why this cannot be easily tested.
  10. we do it differently[ Go to top ]

    AFAIK, but I might be wrong, noone provides XML overridingin JPA.

    I've a prototype in my box for that. I build annotations from the XML files. The Hibernate Annotations binder code remains the same. That's a really nice stuff made possible by the work of Paolo and Davide on the Hibernate Annotations reflection layer.
    I plan to finish it and release as soon as I am back to business.
  11. yo, spiccoli[ Go to top ]

    Um. Dude.A JNDI name is a *logical name*! How can a logical name *possibly* be something that needs to change at deployment time??!

    Uhhh, dude, I am doing deployments where I have an MDB that delegates to a Session Bean, of which there are 2 implementaitons available in my EAR. I find it quite handy to switch the deployment descriptor and avoid having to recompile to point at the different implementation.
    When are we going to get over this totally irrational fear of the new? ;)

    I think these are reasonable concerns from people who have an interest in keeping the roles of developer and deployer separated, and who look at the codeploymentdescriptors produced by develoployers and see it is NOT JUST CODE anymore.

    I've wondered (not yet tried it out) how my code is going to look when I pack in all the EJB3 O/R Mapping and then put in my JAXB Annotations, and then the logging annotations, etc...

    What would be helpful, would be a tool that would maintain this annotation stuff outside of the source code, and insert it into the byte code after compile-time (kind of like JDO).

    Meta-Data in code is not everyone's cup of tea, you see?
  12. yo, spiccoli[ Go to top ]

    Um. Dude.A JNDI name is a *logical name*! How can a logical name *possibly* be something that needs to change at deployment time??!
    Uhhh, dude, I am doing deployments where I have an MDB that delegates to a Session Bean, of which there are 2 implementaitons available in my EAR. I find it quite handy to switch the deployment descriptor and avoid having to recompile to point at the different implementation.

    And here is a perfect example of what I described in the post above!

    Have you heard of the ENC (Environmental Naming Context)?

    If you havn't, then let me explain: EJB provides a naming context which is an *indirection* to the actual global namespace. So you can, if you like, stick the ENC name in your annotation, and then, at deployment time, change what actual EJB that is pointed to by that ENC name.

    Go back and re-read my earlier post in this thread.
    When are we going to get over this totally irrational fear of the new? ;)
    I think these are reasonable concerns from people who have an interest in keeping the roles of developer and deployer separated, and who look at the codeploymentdescriptors produced by develoployers and see it is NOT JUST CODE anymore.

    I think it is far more reasonable if people *actually learn EJB3* before coming out with half-assed criticisms based on their incomplete understanding of what is there.

    Do you really think it is likely that the EJB spec group did not consider these kinds of issues?
    What would be helpful, would be a tool that would maintain this annotation stuff outside of the source code, and insert it into the byte code after compile-time (kind of like JDO).

    Please go and read the damn spec. All facilities that are provided via annotations are also available via XML. You can either:

    (1) Use full XML instead of annotations (nuts)
    (2) Use partial XML to override annotations when and where you need it (smart)

    There is no excuse for people to not understand this, since it has been fully explained here and in many other places (and, of course, the spec document itself) on many occasions.

    Sheesh, I am so damn frustrated hearing the same misconceptions repeated over and over just because no-one who criticises can actually be bothered reading the actual spec.
  13. yo, spiccoli[ Go to top ]

    Do you really think it is likely that the EJB spec group did not consider these kinds of issues?
    I would not ....censored.....
    You can either:(1) Use full XML instead of annotations (nuts)(2) Use partial XML to override annotations when and where you need it (smart)There is no excuse for people to not understand this, since it has been fully explained here and in many other places (and, of course, the spec document itself) on many occasions.Sheesh, I am so damn frustrated hearing the same misconceptions repeated over and over just because no-one who criticises can actually be bothered reading the actual spec.

    Simply we don't like to have these kind of annotations in
    the source code as you do.
    These are not misconceptions, these are citicisms to certain
    use (and abuse) of annotations.
    It is not necessary to read the spec to judge the
    idea of putting configurations info in the source code.
    It is wrong, point.
    It is rather odd that, normally, you can do it wrong (the annotations), but if you really need you can do it right (the XML).

    Guido
  14. yo, spiccoli[ Go to top ]

    Have you heard of the ENC (Environmental Naming Context)?

    My bad, of course I use the com:java/env namespace - I just was blinded my my frustration with you codeployers (I will trademark that) that I forgot that I use double-indirection.
    Do you really think it is likely that the EJB spec group did not consider these kinds of issues?

    I believe they did, but I also believe they were led by rabid (or sheesh, damn frustated) Annotaters who need to generate revenue streams for their shareholders.
    You can either:(1) Use full XML instead of annotations (nuts)

    Guess that's why J2EE sucks so bad as it stands at 1.4 - NOT! Entity Persistence stunk, and thanks to EJB3 we'll get a decent replacement.
    (2) Use partial XML to override annotations when and where you need it (smart)

    Guess that makes me nuts. You is smart.
    I am so damn frustrated hearing the same misconceptions

    It's not a misconception that annotations clutter up code.
    ...before coming out with half-assed criticisms

    If these annotation criticisms are so half-assed, then why even support XML at all?

    I love provoking you guys. Surely I will someday be pulled into the annotation quagmire, screaming like a rabid jbosser all the way...
  15. yo, spiccoli[ Go to top ]

    Posting again in this thread, mainly because I feel I was unneccessarily rude previously and wanted to back up on that a bit. Ahem. Bad me. Sorry.

    I am so damn frustrated hearing the same misconceptions
    It's not a misconception that annotations clutter up code.

    Now that is a perfectly reasonable criticism to make, and in the end comes down to personal taste: what is more understandable? Two files that I need to navigate between, one Java, and the other verbose, ugly XML? Or one file, with the same information intermixed, with less total verbosity? What is the "code" here? Should I think of the XML as a kind of code?

    Obviously this will be a matter of personal preference, and we both know which way our own preferences run. There are actually some decent points on each side here, and one of the things that frameworks need to try and do is strike the right balance between annotations and DSLs.

    But "clutter" was *not* the point that was being made earlier in this thread, and was not the thing that I called a "misconception". I think it's pretty clear that the argument being made was that annotating JNDI names into the code resulted in less flexibility at deployment time. *That* point is in matter of fact incorrect and a misunderstanding of the spec (as it seems you now acknowledge). A JNDI name is a logical name, and may indeed be an indirection to some other name.

    It is certainly not the case that people who would consider using annotations in this particular case are "babies".


    Now, the way I'm describing this debate is actually quite silly. It's not a question of "are annotations good or evil?". Rather it is a question of "WHICH information makes sense in annotations?". (Surely not even the greatest anti-annotation zealot would argue that @Override is a mistake!) Different frameworks make different decisions. For example, Seam uses annotations for dependency management, XML for navigation, and gives you a choice between XML or annotations for scope demarcation. Other frameworks choose differently in these cases (eg. Stripes uses annotations for navigation).

    To totally rule out annotations upfront is as crazy as trying to use them for *everything*.

    If these annotation criticisms are so half-assed, then why even support XML at all?

    This is like saying "if session beans are so good, why support message driven beans?". You support both because there is a time and a place for each, and because people have different personal preferences.

    Surely I will someday be pulled into the annotation quagmire

    This is almost certainly true, mainly because other developers you work with will want to use annotations and will (hopefully) want you to work on their projects.
  16. Question[ Go to top ]

    Hi guys, Interesting discussion. I have a humble question. This is my interpretation: most application servers uses a server specific deployment descriptor (or annotation) element that maps the logical JNDI name as used by the module (EJB,WAR) to the deployment environment JNDI name. This descriptor is defined and packaged in the module, not in the application (EAR). Let's assume I have packaged and tested a set of modules which will be exposed as reusable modules from (for example) a maven repository. I pick appropriate modules to be assembled in applications. I have a hard time understanding how modules containing MDBs can be packaged in multiple applications (deployed in the same server) and still avoid "deployment environment jndi name" conflicts. Servlet context can be bound using application.xml. Deployment environment JNDI names for SLSBs can be generated depending on what application it was deployed in (JBoss works this way?). I think persitence.xml can be packaged in the application and modules can use logical names to reference "application-defined" datasources? All of these approches avoid conflicts by binding the logical name when assembling the application, not when assembling the module. But, for MDBs i have not found any similar way of "lately" bind the logical name of a queue to the deployment environment JNDI name? Am i making any sense? Cheers, -Kristoffer
  17. Question[ Go to top ]

    If this is true, then i guess the following documentation is not valid: Reading from "Development Roles" http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Overview6.html : "For example, in the application component development phase, an enterprise bean software developer delivers EJB JAR files. In the application assembly role, another developer combines these EJB JAR files into a J2EE application and saves it in an EAR file. In the application deployment role, a system administrator at the customer site uses the EAR file to install the J2EE application into a J2EE server." Because there is no way for the "application assembly role" to _freely_ pick EJB JAR files from the "enterprise bean software developer". He will be getting global conflicts if an EJB JAR is assembled inside two EARs and deployed in the same server. Do you see my point? Reusing EJB modules accross applications is not possible. Or have I misunderstood something obvious? Cheers, -Kristoffer
  18. how often, really?[ Go to top ]

    <blobkcquote>
    When this bad habit of setting deployment configuration attributes at development time will stop ?
    We already have awful examples with ORM annotations for table names, table columns etc.
    Obviously WebServices (JAX-WS) cannot be less with endpoint specification.
    Now, JNDI.
    Annotations ? A gun (Uzi ?) in the hands of babies.

    Guido
    From what I've seen of XDoclet use, customers don't ever want to touch XML. Students that learned that XDoclet exists felt the same. With annotations, there's no reason you can't override what you want in XML if you need to anyways. So, fast prototype with annotations, override if you find the need. Many (most?) applications won't have the need.

    Bill
  19. One thing that has been a mess for a long time and that absolutely has to be standardized in the next rev of Java EE is this whole problem of global JNDI names.

    Currently, the spec has the ENC, which provides a standardized indirection to a totally unspecified thing called a "mapped name" which may or may not be the global name of something in JNDI.

    Since this mapped name is totally vendor specific and since (even worse), the metadata for specifying the mapping from the global name to the ENC name is also left unspecified, it is currently not possible to deliver Java EE applications that work transparently across different implementations. You are always going to need to add extra vendor specific metadata.

    The funny thing is, the indirection provided by the ENC is actually a really useful construct, allowing dependencies upon EJB components or resources to be pluggable and swappable. But almost no-one actually takes advantage of this feature, since the fact that it is so underspecified means that people simply don't understand it, and simply don't get it's usefulness.

    What need to be defined is:

    * What is this "mapped name" you speak of? (in practice, this means the spec needs to define that mapped name == global JNDI name)

    * What is the global JNDI name of an EJB component by default? eg. myEarName/mySessionBeanName/local is what we have chosen in JBoss.

    * What is the mechanism for overriding this default? eg. @JNDIBinding or XML in JBoss EJB3.

    * What is the mechanism for mapping the global JNDI name into the ENC? ie. what should the XML descriptor look like?