Thanks for your reply Ken. I have another question or two but if they
are more EJB spec/Netbeans then just let me know and I'll go bug them :)
You state that there shouldn't be any required source code change when
switching app server vendors. If two app servers support mappedName for
a MDB but the meaning is different(hard to imagine but just for
arguments sake) doesn't this require a source code change now? I guess
vendor specific xml files could take precedence but non-portable
must-have annotations just don't sit well with me. Unless there are
deployment tools that can modify the annotation of a class without the
original source code.....?
Wouldn't this be done better with some type of activationconfig
annotation that could have a key like glassfishJndiName? I guess this
might in part be a spec limitation. Or do you see mappedName on a MDB
becoming a defacto standard? Is not having a key a benefit because it
encourages vendors to agree? Are there any other app servers that
support mappedName yet?
I know remote sessions beans could use mappedName for global jndi names
but because of dependence injection I don't even need to care about the
global jndi name half the time. mappedName for a remote session bean
just feels more like a vendor enhancement. But I think I have some crazy
ideas about session bean default jndi names anyway
(
https://glassfish.dev.java.net/issues/show_bug.cgi?id=577).
The only real reason I have problems with it I guess is that I've been
able to learn and just EJB3 on Glassfish by pretty much just reading the
spec until I hit MDBs. I know JMS has always been a little proprietary
but I was hoping to see that fixed in EJB3. I'm guessing that a EJB 2.1
style deployment descriptor with a sun-ejb-jar.xml would still work.
Shorty after making my first MDB in a Java EE 5 project I realized that
Netbeans 5.5 Dev doesn't even create a ejb-jar.xml in a ejb project
automatically anymore but the New MDB wizard does require a mappedName
value. Would you know if this Netbeans behavior is just because of the
relationship between Glassfish and Netbeans(in which case I'd probably
file a Netbeans bug) or is mappedName on a MDB that much of an
unofficial standard?
Thanks,
-Chase
Kenneth Saks wrote:
> Chase wrote:
>
>> I'm trying to make a portable MDB. I can get a MDB work in the style
>> done on https://glassfish.dev.java.net/javaee5/ejb/examples/MDB.html.
>> A snip of the code on your website:
>>
>> @MessageDriven(mappedName="MDBQueue")
>> public class MDB implements MessageListener {
>> ....
>> }
>>
>> After reading the EJB3 spec it doesn't sound like "mappedName" is
>> portable(it maps to a global JNDI name).
>
> Hi Chase,
>
> Use of mappedName does not make an application non-portable in the
> typical sense. The Java EE platform has always left certain vendor
> deployment-environment configuration parameters outside of the spec.
> Examples are Remote EJB Global JNDI names, physical MDB queue JNDI
> names, physical DataSource JNDI names, etc. These have typically been
> set either by vendor-specific configuration files (e.g. SUN's
> sun-ejb-jar.xml) or vendor-specific defaults. The key to portability
> is that the packaged Java EE modules (.ear, ejb-jar, .war, etc.) have
> the same application behavior between vendors. It might be necessary
> to add a new vendor-specific .xml file when moving between vendor A
> and vendor B but there shouldn't be any *required* change to the
> application source or the standard .xml files.
>
> The mappedName was added in Java EE 5 because it turns out almost
> every Java EE vendor has a similar approach for mapping some of the
> most common logical resources/dependencies to physical resources.
> Vendors are not required to support it because there is still no
> mandated notion of global JNDI namespace nor any mandated syntax for
> the mapped names. However, it doesn't really affect application
> portability. In the common case that the vendor does support the
> mappedName for a particular resource type, the packaged application
> will not require any additional vendor-specific configuration. In
> the case that it doesn't, the deployer will need to perform
> *vendor-specific* configuration, which is no different than in
> previous versions of the Java EE platform. A vendor who doesn't
> support mappedName must *ignore* it, which is what allows the deployer
> to leave the application code and standard .xml files untouched.
> --ken
>
>> Is there a way to make a portable MDB? And if so can it be done with
>> just annotations?
>>
>> Thanks,
>> -Chase
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>>
>
>
>