This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The generated annotation is using "mappedName" attribute. Spec says: "Application servers are not required to support any particular form or type of mapped name, nor the ability to use mapped names." Unfortunately there does not seem to be generic solution. I think that message destinations are supported for GF, WL and JBoss. GF is obviosly happy with mappedName, while JBoss requires ActivationConfigProperty named destination. Not sure about WL, needs testing. My susggestion would be to generate both mappedName and destination property in case the property does not cause GF to fail.
According to Oracle docs and few 3rd party tutorials, there should be two ways for WL 10.3+: mappedName or destinationJndiName AC property http://docs.oracle.com/cd/E12840_01/wls/docs103/ejb30/annotations.html#wp1416916 http://docs.oracle.com/cd/E21764_01/web.1111/e15493/annotations.htm There could be second way to generate it server specific and implement also hint for that. But if it would work with only "destination" ACP and "MappenName" on all supported app. servers I agree with the solution to achieve the best portability.
Practicals: - WL doesn't take care about additional properties, so "destination" is OK to it - GF does, :/ so we can't generate "destination" ACP for its MDBs since it fails: Caused by: java.lang.IllegalArgumentException: MQJMSRA_AS4001: setDestination:Invalid destination name=jms/myQueue at com.sun.messaging.jms.ra.ActivationSpec.setDestination(ActivationSpec.java:406) ... 44 more Let's talk about another solution. On the first look it seems that we will need generation specific per application server. Maybe JmsSupport API/SPI of the javaee.spec.support. WL, GF could use default implementation then, JBoss would get its own.
Created attachment 132598 [details] API + ejb usage patch The situation changed a little bit with arrival of the JavaEE7 specification. JavaEE7 defines activation config property 'destinationLookup' which is used for purposes of mapping the bean to the location. Anyway it doesn't still resolve our issue for JavaEE6- projects. I prototyped API patch into the javaee.spec.support which could resolve this. I would like to mention that all properties obtained from platform lookup will be used just in case of JavaEE6 and lower. In case JavaEE7 is forced the recommended way. Petre, client code can still change but could you take a look on the three files for the javaee.spec.support if they look OK to you? Thanks a lot.
Perhaps I would avoid one level of indirection. Just put the methods to JmsSupportImplementation directly. Perhaps there should be boolean useDestinationLookup() (servers would return true for Java EE 7). I know it might look pointless, but there are at least two things justifying this: 1) Historically there were semi-compliant servers we wanted to support. 2) By stating in javadoc that in Java EE 7 it is not used you indirectly put spec version dependency into the API created to avoid that.
Thanks a lot Petr for reviewing. I removed the MessageDrivenMapping interface and added method 'useDestinationLookup()' which I also finally used in the client. So any non-ee7 complied server is able to say "sorry, not EE7 compatible, use the old way for MessageDestination definition". web-main #4011a87a1061
Integrated into 'releases', will be available in build *201304242201* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/4011a87a1061 User: Martin Fousek <marfous@netbeans.org> Log: #225112 - @MessageDriven generated by new message driven bean
Integrated into 'main-golden', will be available in build *201304252301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4011a87a1061 User: Martin Fousek <marfous@netbeans.org> Log: #225112 - @MessageDriven generated by new message driven bean