StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>There's no standard way to do it and as far as I know, no common vendor-specific way to do it.</p> <p>This is something i tried to get in in EJB 3.1 for EJB and JPA refs: if an injection point works using the default rules because there's only one <code>SomeType</code> bean, but then some day a second <code>SomeType</code> bean is added... to be blunt, you're hosed :) This problem also exists for <code>@PersistenceContext</code> and <code>@PersistenceUnit</code> refs. The idea was/is to have some "this is the default impl of <code>SomeType</code> option in the standard deployment descriptors and bail people out of these situations.</p> <p>We should still get this into the specification. If this is your problem, I'll repost that proposal and if you can please follow up with information on how much of a nightmare this is for you, I can almost guarantee we'll get this fixed for EJB.next.</p> <h1>Get your canonical xml</h1> <p>For now, one possible approach is to temporarily deploy this ear in TomEE using the flag <code>openejb.descriptors.output=true</code>. TomEE/OpenEJB will actually give you all the effective deployment descriptors for your application. Could save you several hours or days if your application is as large as you state. Internally we 1) read in the deployment descriptors, 2) use the annotations to "fill out" the deployment descriptors. The result is we have a tree which is the canonical set of "metadata" for each EJB module. With the <code>openejb.descriptors.output=true</code> flag set, we will write each of these ejb-jar.xml files to disk and log the location.</p> <p>Once you have your ejb-jar.xml files in hand, you can modify at will and go back to GlassFish and perhaps have better luck.</p> <h1>Overriding: Control your reference counts</h1> <p>In terms of how to actually manage this in Java EE, you have to understand how to be successful in overriding references. There's a critical bit of info one needs to know in how annotation references translate to xml. The goal is to have 1 reference and not N.</p> <p>When your reference is unnamed like so:</p> <pre><code>package org.some.awesome.code; public class Foo { @EJB SomeType orange; </code></pre> <p>... there's a fixed rule that the default name of this must be <code>org.some.awesome.code.Foo/orange</code>. The class name and package become part of the name so as to give you the most fine grained control in overriding. The following xml will override this reference:</p> <pre><code><ejb-local-ref> <ejb-ref-name>org.some.awesome.code.Foo/orange</ejb-ref-name> <local>org.some.awesome.code.SomeType</local> <ejb-link>Fred</ejb-link> </ejb-local-ref> </code></pre> <p>This reference will now link to the EJB of type <code>SomeType</code> with the beanName 'Fred'.</p> <p>The disadvantage of this is that if you have 100 references like this and you want to change them all, you will need 100 declarations in xml to do so.</p> <p>There's no way out of this problem that doesn't involve changing your code -- this is where my "use this as the default" proposal has value, it would allow one xml change to handle all 100 cases with no code change. It's as simple as being able to say "when I'm not specific in my code, I really mean use X" via the deployment descriptor. </p> <p>Perhaps by making it legal to declare overrides in xml using just the type, like so:</p> <pre><code><ejb-local-ref> <local>org.some.awesome.code.SomeType</local> <ejb-link>Fred</ejb-link> </ejb-local-ref> </code></pre> <p>As mentioned, this is currently not legal.</p> <h2>Changing your code</h2> <p>There are a few code change approaches available, but one of them is to give each <code>@EJB</code> ref the same name. Then you will end up with just 1 reference rather than N.</p> <pre><code>package org.some.awesome.code; public class Foo { @EJB(name "purple") SomeType orange; </code></pre> <p>Here the name of the reference is explicitly given so overriding it in xml can be done more simply as follows:</p> <pre><code><ejb-local-ref> <ejb-ref-name>purple</ejb-ref-name> <local>org.some.awesome.code.SomeType</local> <ejb-link>Fred</ejb-link> </ejb-local-ref> </code></pre> <p>If there are 100 <code>@EJB(name="purple")</code> references, all of them would be overridden by the above declaration.</p> <h1>Conclusion</h1> <p>Short answer, there's currently no easy way out. You're looking at either extensive xml or extensive code change.</p> <p>Long term, we can hopefully improve this part of the specification so people aren't punished when they grow out of the default matching rules.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload