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
>>
>>
>
>