Jerome Dochez wrote:
>
> On Mar 28, 2009, at 8:01 PM, Bill Shannon wrote:
>
>> Jerome Dochez wrote:
>>> On Mar 27, 2009, at 9:28 PM, Bill Shannon wrote:
>>>> Kenneth Saks wrote:
>>>>>> This is what would happen when people do not specify the --type
>>>>>> parameters. From Hong's example, it's clear that the only interest
>>>>>> of specifying the --type parameter would be to say that you want
>>>>>> to deploy the web-app part but not the EJB (used as pojo) for
>>>>>> instance
>>>>>>
>>>>>> so you can do
>>>>>>
>>>>>> deploy --type ejb,web -> would deploy in both container.
>>>>>> deploy --type web -> only web container
>>>>>> deploy --type ejb -> only ejb container
>>>>> Would the deployment framework still be processing the web.xml /
>>>>> sun-web.xml in this last case? The EJB
>>>>> code could contain dependencies on it. For example : component
>>>>> environment entries, EE 6 <module-name> , etc.
>>>>> I'm not sure I understand the real value of this. If someone
>>>>> really wants ejb components completely
>>>>> separated from web components they can just package them in a
>>>>> separate ejb-jar.
>>>>
>>>> I agree.
>>>>
>>>> I understand specifying a type when the server can't unambiguously
>>>> figure out the type on its own, but using it to "turn off" part of
>>>> the functionality seems wrong.
>>>>
>>>> If I deploy something of type "web", I want it to do everything the
>>>> web container is supposed to do, which currently includes supporting
>>>> EJBs.
>>> so what solution do you propose for people who do not own the
>>> packaging of what they are deploying, reusing off the shelves
>>> components which packaging may not reflect their exact usage ?
>>
>> Sorry, I don't understand the use case.
>>
>> Are you worried about someone who is given a war file that contains
>> EJBs, but they want to deploy it without allowing the EJBs to work?
>> Doesn't seem important to me. If they really wanted to do that,
>> why couldn't the repackage the war file to remove the components they
>> don't want to work, or why couldn't they deploy it using an alternate
>> deployment descriptor that turns off the EJB components?
> they have to repackage, that was the point I was making
Seems like a rare case.
> but more importantly, if you agree that there can be some ambiguity not
> resolvable by the server, if you change type to have an additive
> behaviour, how would this resolve the ambiguity ? It seems to me that
> you are thinking packaging (war, jar, ear, osgi) while the --type was
> targeted to containers (web, ejb, jpa...).
I think the concept of "container" is disappearing, or at least being
separated from the concept of "runtime". EJBs in a war file aren't
running in the EJB container, they're just using the EJB runtime. They
don't use the EJB container's packaging format, they don't have the EJB
container's JNDI namespace support.
I don't want to choose whether to turn on or off the EJB runtime support,
but in cases where it's ambiguous I'm willing to say "yes, it really is a
war file" or "yes, it really is an EJB jar file".
> Take the following example :
> I have an OSGi war file that has both servlet.xml (for deployment in a
> Java EE appserver) and a bundle activator to use the OSGi HttpService to
> deploy its servlets (when running in OSGi env.). If we somehow don't
> segregate the containers, we can happen to deploy this web application
> twice...
Well, we still need to decide if and how we're supporting Java EE
applications also being OSGi bundles. If we support that, and we run
into a lot of cases like what you describe, we may need a way to turn
off OSGi bundle recognition for Java EE deployment units.
> I know this might be a stretch but the open composition of components of
> all kind, I think it might be useful. At the very least we need a bundle
> type segregator (war vs osgi) which would resolve the case above (the
> user would choose the deployment method by specifying the type).
>
> I can live with that for now and see if that's enough.
I think that's a good place to start.