Marina Vatkina wrote:
> Vince,
>
> Thinking more about it... if the user doesn't want/need to package the
> ejbs, s/he can keep them under WEB-INF/classes. Is it a problem for an
> IDE?
Sometimes an IDE builds a portable version of something and deploys a
different equivalent version of that something to speed up iterative
development.
vbk
>
> thanks,
> -marina
>
> Vince Kraemer wrote:
>> Tim Quinn wrote:
>>
>>> Sorry, I did not notice the original posting, Vince.
>>>
>>> Marina Vatkina wrote:
>>>
>>>> I don't think we explode jars in the lib directory (either in an
>>>> ear or a war).
>>>
>>> Marina is correct; currently neither v2 nor v3 prelude expands
>>> library JARs, nor does it expect them to be pre-expanded for
>>> directory deployment.
>>
>>
>> OK.
>>
>>>
>>> The guiding principle - at least up to now - is to expand submodules
>>> nested within EARs (such as WARs, EJBs, etc.) but to leave other
>>> JARs alone.
>>
>>
>> Right.... and that is what generated the question.... It looks like
>> Java EE 6 blurs the "line" between a WAR and an EAR. I am just trying
>> to see how that blurring translates from spec into a development
>> environment.
>>
>>>
>>> I am not sure if much thinking has gone into whether it makes sense
>>> to treat EJB JARs inside a WAR as a "submodule" in the same sense,
>>> at least as far as directory deployment is concerned. One possible
>>> wrinkle is that, historically, the submodule JAR has been expanded
>>> into a directory which resides in the same place as the original
>>> JAR file. If v3 followed that approach then, for the EJB-in-WAR
>>> case, the directory structure would change from this:
>>>
>>> WEB-INF/lib/myejbs.jar
>>>
>>> to this
>>>
>>> WEB-INF/lib/myejbs_jar/x/y/z.class (or something like that)
>>>
>>> and so now we have broken the rule that items in WEB-INF/lib are JARs.
>>>
>>> There might be other changes in how archives are handled in v3 that
>>> might open the door to doing something with this. I like the idea
>>> of avoiding JARring up the EJBs in the development environment if
>>> it's avoidable but I think this needs more careful thought than I've
>>> been able to give to it here.
>>
>>
>> I was pretty sure this wasn't a "worked" detail at this this point...
>> but I was willing to be wrong.
>>
>>>
>>> How about opening an enhancement request?
>>
>>
>> Me: (Slaps forhead) I coulda hada V8!
>>
>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6620
>>
>> vbk
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>