>> Will it be OK if we first upgrade to s2b.jar from NB 4.1 release
>> and then later on take up the changes to use Pure Beans? I thought it
>> was better to separate these two tasks because the use of the so
>> called "runtimeless" beans is an enhancement, whereas the upgrade to
>> the latest s2b.jar is a must.
>
> that's absolutely fine with me as long as we don't drop the effort
> after *this* integration.
OK. We have to think more about the II part. For now, we will proceed
with part I (upgrade to s2b from NB 4.1). I will send a document that
describes the part I in detail.
>
>>
>> What Alex meant regarding version mismatch was there is at least
>> one class in the latest s2b.jar that is changed in an incompatible
>> manner from earlier release (Version.class). So, all the classes in
>> GlassFish source that depend on this class must be regenerated.
>
> I assumed we would regenerate all the sources when we would switch to
> "pure" anyhow so what you are telling me is that we would regenerated
> twice, right ? I don't see that as a problem as long as the contract
> offered by those beans (at least the contract used by the appserver
> components) remains compatible.
The answer depends upon our findings (numbers) from the *real* gain by
using the "runtimeless" (aka "pure") beans. If there is a significant
difference in those numbers, we will have to regenerate the beans.
>>
>> Please let us know.
>>
>> Regards,
>> Kedar
>>
>>
>> Jerome Dochez wrote:
>>
>>> Alex Kravtchenko wrote:
>>>
>>>> Hi Jerome,
>>>>
>>>> Sorry for the delay.
>>>> What do you mean under "pure" JavaBeans? Self-contained beans,
>>>> not requiring the thick base classes(s2b runtime)?
>>>
>>>
>>> yes
>>>
>>>> ConfigBeans are following the JavaBeans getters/setters
>>>> signature, but they extend s2b's BaseBean class, so probably they
>>>> could no be called "pure" JavaBeans. Meanwile, these beans are
>>>> tightly bound to xml file and these rintime classes actually take
>>>> care of such beans persistance (mapping/reading/writting of the
>>>> xml-tree/file). Anyway this functioality should be implemented
>>>> whether in admin or in beans theirselves.
>>>
>>>
>>> I understand that s2b has the functionality to generate "pure"
>>> JavaBeans (look at the link below) that will have these features
>>> wired on the beans themselves rather than relying on the runtime
>>> library. That would allow us to not have to ship the s2b runtime and
>>> free us from yet another binary dependency.
>>>
>>>> After discussion on admin team meeting with Kedar and Abhijit, we
>>>> decided not to run to "pure" standalone java beans, if their
>>>> generation is possible (we do not know if shema2beans can generate
>>>> standalone, not requiring runtime lib , beans at all).
>>>
>>>
>>> http://schema2beans.netbeans.org/docs.html#GenerateRuntimeless
>>>
>>>>
>>>>
>>>> Regarding schema2beans versions. This issue appears because we
>>>> use s2b runtime.
>>>> Even if we will use s2b runtime lib, then hopefully 4.0 generated
>>>> beans will be compatible with any runtime libraries of later
>>>> versions. Unfortunately, it is not true for beans generated under
>>>> erier version (v.3.5 beans are not compatible with later libs).
>>>> That was the main reason to move to recent schema2beans version.
>>>
>>>
>>> I am not sure I understand why you mean. I think you should use
>>> anything after 4.0, the more recent is probably the better. Would
>>> that be an issue ?
>>>
>>>>
>>>> Kedar, could you please add your comments.
>>>> Thanks,
>>>> Alex
>>>>
>>>> Jerome Dochez wrote:
>>>>
>>>>> Hi Alex,
>>>>>
>>>>> I have not seen an answer to this email...
>>>>>
>>>>> Jerome Dochez wrote:
>>>>>
>>>>>> This is great.
>>>>>>
>>>>>> + have you tried to generate the pure JavaBeans to see if the
>>>>>> added footprint is smaller that 300K ?
>>>>>> + still not clear why the version we would use is important.
>>>>>>
>>>>>> Thanks, Jerome
>>>>>>
>>>>>> Alex Kravtchenko wrote:
>>>>>>
>>>>>>> Hi Jerome,
>>>>>>>
>>>>>>> Beans, generated by s2b still extend schema2bean's BaseBean
>>>>>>> class and require schema2beans run-time library.
>>>>>>> Starting from netbeans 4.x, schema2beans module is divided
>>>>>>> onto two jar files - schema2beans.jar (~300Mb) and
>>>>>>> schema2beansdev.jar (~900Mb).
>>>>>>> The second jar file is needed only for beans generation phase.
>>>>>>> The first one (runtime) is merging into appserv-rt.jar during
>>>>>>> bootstraping.
>>>>>>> So, switching to recent versions will eliminate a lot of
>>>>>>> appserver's runtime footprint.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>> Jerome Dochez wrote:
>>>>>>>
>>>>>>>> Hi Alex
>>>>>>>>
>>>>>>>> why this important ?
>>>>>>>>
>>>>>>>> I suggested we should be generating pure JavaBeans (no runtime
>>>>>>>> dependency of class libraries) and therefore the s2b would only
>>>>>>>> be used a build time. Is this not happening yet ?
>>>>>>>>
>>>>>>>> Jerome
>>>>>>>>
>>>>>>>> Alex Kravtchenko wrote:
>>>>>>>>
>>>>>>>>> Hi Jerome,
>>>>>>>>>
>>>>>>>>> No, we did not integrated new schema2beans yet. It can be
>>>>>>>>> done by the next week beginnig.
>>>>>>>>> Unfortunately, we still have not received answer on
>>>>>>>>> question: " Which Netbeans version should be incorporated with
>>>>>>>>> glassfish - 4.1, 4.2 or 5.0?"
>>>>>>>>> I prepared and tested usage s2b of netbeans_4.1 because
>>>>>>>>> this version has synchronized binaries and sources on
>>>>>>>>> netbeans.org.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --Alex
>>>>>>>>>
>>>>>>>>> Jerome Dochez wrote:
>>>>>>>>>
>>>>>>>>>> Kedar
>>>>>>>>>>
>>>>>>>>>> Have you integrated this in the trunk ?
>>>>>>>>>>
>>>>>>>>>> Jerome
>>>>>>>>>>
>>>>>>>>>> Kedar Mhaswade wrote:
>>>>>>>>>>
>>>>>>>>>>> We have Beta Hard Code Freeze (HCF) coming up on Monday,
>>>>>>>>>>> 12/18/2005. Hence, we are postponing this integration until
>>>>>>>>>>> after that so that there are no stability issues. A separate
>>>>>>>>>>> notice will be sent when we take this up after the HCF.
>>>>>>>>>>>
>>>>>>>>>>> Thanks and Regards,
>>>>>>>>>>> Kedar
>>>>>>>>>>>
>>>>>>>>>>> Kedar Mhaswade wrote:
>>>>>>>>>>>
>>>>>>>>>>>> All,
>>>>>>>>>>>> Alexandre Kravtchenko and I are planning to upgrade the
>>>>>>>>>>>> schema2beans.jar that is part of Glassfish binary
>>>>>>>>>>>> dependencies. This will be done by December 18, 2005. We
>>>>>>>>>>>> are planning to use the latest 4.2.0 version of this jar
>>>>>>>>>>>> that will be staged in the process. More could be found
>>>>>>>>>>>> about this jar at
>>>>>>>>>>>> http://schema2beans.netbeans.org/servlets/ProjectDocumentList.
>>>>>>>>>>>>
>>>>>>>>>>>> Note that we have serverbeans (used by the server
>>>>>>>>>>>> runtime to modify and persist domain.xml) and clientbeans
>>>>>>>>>>>> (required by the application client container) depending
>>>>>>>>>>>> upon this jar. We will make sure that the generation of
>>>>>>>>>>>> beans is successful and will make minor modifications to
>>>>>>>>>>>> the base classes to make the beans work with the changes in
>>>>>>>>>>>> latest schema2beans.jar.
>>>>>>>>>>>>
>>>>>>>>>>>> We will run the Quicklook and other required tests. Note
>>>>>>>>>>>> that we have not modified other parts of server that might
>>>>>>>>>>>> be using other versions of Netbeans for their purpose. We
>>>>>>>>>>>> think that nothing else is impacted because of this.
>>>>>>>>>>>>
>>>>>>>>>>>> As a result of this integration, classes from new
>>>>>>>>>>>> schema2beans.jar will be made part of appserv-admin.jar,
>>>>>>>>>>>> new serverbeans and clientbeans will be generated and
>>>>>>>>>>>> checked in to Glassfish sources.
>>>>>>>>>>>>
>>>>>>>>>>>> The basic reason for this upgrade is to use the latest
>>>>>>>>>>>> from schema2beans and to try to reduce the footprint of
>>>>>>>>>>>> server by not using the classes in earlier version of this
>>>>>>>>>>>> jar that are useful only to generate the beans and not
>>>>>>>>>>>> required at runtime.
>>>>>>>>>>>>
>>>>>>>>>>>> Let us know if you see any concerns.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Kedar/Alex.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>