jsr345-experts@ejb-spec.java.net

[jsr345-experts] Re: Keeping on track (Application Assembler role/responsibility)

From: Reza Rahman <reza_rahman_at_lycos.com>
Date: Sat, 10 Sep 2011 00:16:04 -0400

Marina,

Looks fine I think.

Cheers,
Reza


On 9/9/2011 10:27 PM, Marina Vatkina wrote:
> Reza, (all),
>
> As there are (unnecessary) duplications in the spec, I used your text
> to improve the 2.2.2 section (Roles):
>
> =======================================================================================================================
>
> "The Application Assembler combines enterprise beans into larger
> deployable application units. The input to the Application Assembler
> is a set of enterprise beans, their interfaces, and metadata, as
> produced by the Bean Provider(s). The Bean Provider's output may also
> simply be un-assembled enterprise beans that must be packaged in an
> ejb-jar or.war file. The Application Assembler may insert the
> application assembly instructions into the deployment descriptors. The
> Application Assembler will create one or more ejb-jar and/or.war files
> from the input artifacts together with their application assembly
> instructions as needed.
>
> All of the input could be combined into a single output ejb-jar or
> .war file. Similarly, the input could also be split into multiple
> output ejb-jar and/or .war files. For example, the Application
> Assembler could combine ejb1.jar and ejb2.jar into ejb3.jar, combine
> ejb1.jar and web1.war into web2.war, split ejb1.jar into ejb2.jar and
> ejb3.jar, split web1.war into ejb1.jar and web2.jar, and so forth.
> Each output ejb-jar or .war file is either a deployment unit intended
> for the Deployer or a partially assembled application that is intended
> for another Application Assembler.
>
> The Application Assembler can also combine enterprise beans with other
> types of application components when composing an application."
> =======================================================================================================================
>
>
> and in 14.3 (Responsibility for DD) came up with this:
>
> =======================================================================================================================
>
> "The Application Assembler assembles enterprise beans into deployment
> units. The Application Assembler’s input is one or more enterprise
> beans, un-assembled or contained in one or more ejb-jar and/or .war
> files provided by one or more Bean Providers. All of the input could
> be combined into a single output ejb-jar or .war file, or could be be
> split into multiple output ejb-jar and/or .war files. Each output
> ejb-jar or .war file is either a deployment unit intended for the
> Deployer or a partially assembled application that is intended for
> another Application Assembler."
> =======================================================================================================================
>
>
> Let me know if it looks ok or need/can be improved.
>
> thanks,
> -marina
>
> Reza Rahman wrote:
>> Marina,
>>
>> Sorry for the delay. There were a few other things on my end that
>> could not wait. Here is the modified text:
>>
>> ============================================================================================================================================================
>>
>> The Application Assembler assembles enterprise beans into deployment
>> units. The Application Assembler’s input is one or more enterprise
>> beans contained in one or more ejb-jar and/or .war files provided by
>> one or more Bean Providers. The Bean Provider's output may also
>> simply be un-assembled enterprise beans that must be packaged in an
>> ejb-jar or .war file. The Application Assembler will create one or
>> more ejb-jar and/or .war files from the input artifacts as needed.
>> All of the input could be combined into a single output ejb-jar or
>> .war file. Similarly, the input could also be split into multiple
>> output ejb-jar and/or .war files. For example, the Application
>> Assembler could combine ejb1.jar and ejb2.jar into ejb3.jar, combine
>> ejb1.jar and web1.war into web2.war, split ejb1.jar into ejb2.jar and
>> ejb3.jar, split web1.war into ejb1.jar and web2.jar, and so forth.
>> Each output ejb-jar or .war file is either a deployment unit intended
>> for the Deployer or a partially assembled application that is
>> intended for another Application Assembler.
>> ============================================================================================================================================================
>>
>>
>> I tried not to go too overboard and keep things consistent with the
>> rest of the spec sections that are similar.
>>
>> Hope it helps. Feel free to use it in whatever way makes the best
>> sense. If the text still feels too dense, I would split the sentences
>> further and add more examples/diagrams.
>>
>> Cheers,
>> Reza
>>
>>
>> On 8/2/2011 9:34 PM, Marina Vatkina wrote:
>>> Reza,
>>>
>>> Reza Rahman wrote:
>>>> Marina,
>>>>
>>>> Responses below:
>>>>
>>>> * Yes :-(. Any suggestions?
>>>> - The basic problem is that the text is too dense. I would add some
>>>> specific examples and perhaps diagrams.
>>>
>>> Do you mind writing something up?
>>>
>>> thanks,
>>> -marina
>>>> * I agree. Should I just remove both XXX comments?
>>>> - I think so.
>>>> * A Java SE client won't find classes if they are part of a .war
>>>> file...
>>>> - I see...
>>>> * The problem is with the rules about the should/must/are/etc.
>>>> words in the spec. Only "must" is a requirement. If this
>>>> bootstrapping process is not a must, what will be a portable way to
>>>> do so?
>>>> - OK - in that case we could add "must" to the text there.
>>>> * Let's start a separate discussion on that.
>>>> - OK
>>>>
>>>> Cheers,
>>>> Reza
>>>>
>>>>
>>>> On 8/1/2011 8:53 PM, Marina Vatkina wrote:
>>>>> Sending my replies as an attachment in the hope to bypass my mail
>>>>> client weird truncations... If this doesn't work, will send them
>>>>> one-by-one...
>>>>>
>>>>> -marina
>>>>
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 10.0.1390 / Virus Database: 1518/3806 - Release Date: 08/02/11
>>>
>>>
>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1392 / Virus Database: 1520/3886 - Release Date: 09/09/11
>
>