Hi Chase,
Chase wrote:
> 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
Yes. That's the key point. mappedName is just a hint that says you'd
like to use a particular string to map the resource/dependency to the
deployment environment. The idea is that in the common case that will
work, which removes one more vendor-specific configuration step. If
it's either not supported by the vendor or for some reason that string
is already used for something else, you just do what you've always done,
which is express the mapping using a vendor-specific config file.
There should never be a case where the *only* way to successfully deploy
your app is to make a change to a mappedName attribute or mapped-name
element in a standard .xml file (ejb-jar.xml, web.xml,
application-client.xml)
> but non-portable must-have annotations
In the spec, mappedName is an optional attribute wherever it appears.
> 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?
We already have a way to assign the physical destination via activation
config, but it's more confusing b/c it's one more special vendor-specfic
name the developer has to learn. It also doesn't address the general
case. mappedName appears in many contexts other than MDBs. Sprinkling
in sun-specific annotations in all those places wasn't seen as that much
of an overall improvement.
> I guess this might in part be a spec limitation. Or do you see
> mappedName on a MDB becoming a defacto standard?
I doubt it. mappedName really isn't that big a deal. It's just an
acknowledgement that in a large percentage of cases the process of
mapping logical resources/dependencies to a particular deployment
environment invovles assigning some kind of string. That's it.
> Is not having a key a benefit because it encourages vendors to agree?
> Are there any other app servers that support mappedName yet?
I don't know. I assume most of them will.
>
>
> 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.
Yes.
> 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.
If the tool is providing the ability to actually deploy the MDB to
glassfish/Java EE 5 SDK/AS 9.x then it definitely needs to gather the
JNDI name of the MDB's queue/topic. It could choose to express that
mapping using a sun-ejb-jar.xml rather than mappedName but it doesn't
seem like a big issue. The fact that mappedName has a value doesn't
prevent you from deploying on a different implementation. It might even
make it easier.
> 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
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ejb-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: ejb-help_at_glassfish.dev.java.net
>