Tim,
Please read inline.
Timothy Quinn wrote:
> Hi, Bhakti.
>
> Yes, I am aware of the current arrangement. That's why I asked
> whether it would make sense to split the classes up along
> client/server lines. I discussed this briefly with Harold some time
> ago and his feeling then was that there would be little savings
> because so many of the classes would be needed in the client partition
> anyway.
> I just wanted to revisit this in case there had been any changes that
> would make such a division more worthwhile.
I agree with Harold there are many classes that clients depends on at
runtime to split into two jars so there would not be much benefit in
this case
>
> So app clients that use web services and therefore need the Metro
> classes will still need to rely on the already-resident version in the
> JRE or put up with the download of some more recent build that's part
> of GlassFish, right?
Yes
> In the second case, we can encounter the situation again that we had
> early in Java SE 6 in which the Metro that was part of the JRE (2.0 at
> that time) was incompatible with what GlassFish checked for (2.1).
> Java Web Start launches of app clients that used web services failed
> due to the way Java Web Start manages the class loading - the JRE
> classes were loaded before the GlassFish logic could intercept the
> requests and provide the ones bundled with GlassFish.
Actually JDK 6 u4 will have JAXB/JAXWS 2.1 bundled with the
distributions so then things maybe better but I agree for previous
releases there is a problem and that there is no good way to get a Java
Web Start-launched program use JAX-WS 2.1 if a public release of Java SE
6 is in use.
Getting back to the thread , I plan to make these changes locally and
once things look good will remove dependencies on individual metro
components and just have metro module in v3 and commit it in the workspace.
Regards,
Bhakti
>
> Thanks.
>
> - Tim
>
> Bhakti Mehta wrote:
>> Tim,
>> FYI We do not separate client runtime from server runtime. If there
>> is an appclient built with metro it will need webservices-rt.jar in
>> classpath at runtime.
>>
>> Regards,
>> Bhakti
>>
>> Timothy Quinn wrote:
>>> My (predictable) contribution to this topic is to ask whether it
>>> makes sense to have a JAR (or set of JARs) that supports what
>>> clients need separate from what servers need. This comes from the
>>> continuing effort we all need to share to keep the footprint for app
>>> clients as small as possible. In the past I've heard that there is
>>> not much possibility for improvement in this, but I will continue to
>>> raise the issue at every chance! Especially as long as GlassFish
>>> needs a different version of such JARs vs. what is in the JRE the
>>> size of these JARs will remain an issue for app clients.
>>>
>>> - Tim
>>>
>>> Kohsuke Kawaguchi wrote:
>>>>
>>>> Putting my Metro hat on here,
>>>>
>>>> Really *the* motivation for Metro to deliver things as one big blob
>>>> is so that we can release one set of binaries as stand-alone and
>>>> then deliver the same bits to v2 and v3.
>>>>
>>>> Metro needs to keep delivering into v2 and v3 for some time to
>>>> come, and we do stand-alone releases for foreseeable future. If we
>>>> can deliver our bits in the exact same fashion into two versions of
>>>> GF, that would considerably simplify our build qualification and
>>>> testing effort. And this is one area where we are really stretched
>>>> thin.
>>>>
>>>> This also has an added benefits to users, as they can take the
>>>> stand-alone bits and upgrade GF by simply copying the jars.
>>>> (Although this is a secondary issue for v3, assuming it has its own
>>>> update channel to deliver new bits.)
>>>>
>>>> You are right that there's a possibility that EE6 defines profiles
>>>> that only require a certain portion of Metro but not the others,
>>>> but so far that hasn't happened yet, and I thought it won't be too
>>>> late to revisit the packaging when/if that happens.
>>>>
>>>> There's also a small issue that nucleus already depends on a StAX
>>>> implementation, which is today delivered as a part of Metro, but we
>>>> felt that that was small enough duplication and the benefit of
>>>> single bits delivery outweighs the problem.
>>>>
>>>> So all in all, what I'm suggesting is to start the Metro
>>>> integration into v3 according to Bhakti's suggestion, with the
>>>> understanding that we should be open to the possibility of
>>>> revisiting this.
>>>>
>>>>
>>>> Bhakti Mehta wrote:
>>>>> Jerome,
>>>>> Please read inline
>>>>> Jerome Dochez wrote:
>>>>>> my initial feeling is that it is too coarse grained.
>>>>> I tend to agree but if different profiles start plugging in their
>>>>> own versions of the subparts wouldnt that be a nightmare to debug?
>>>>> Hence I brought up this question here should metro be a module or
>>>>> should there be dependencies for individual technologies in metro?
>>>>>
>>>>> Regards,
>>>>> Bhakti
>>>>>>
>>>>>> For instance, for people who don't care about java ee
>>>>>> compatibility and would want to only support say JAXB+JAXWS
>>>>>> (which I assume would be doable), how would that work ?
>>>>>>
>>>>>> also in Java EE 6, different profiles may require different
>>>>>> subpart of the metro stack, wouldn't that make things harder to
>>>>>> decouple...
>>>>>>
>>>>>> Jerome
>>>>>>
>>>>>> On Feb 28, 2008, at 3:18 PM, Bhakti Mehta wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I wanted to check if there are individual modules in v3
>>>>>>> depending on various technologies from the metro stack like
>>>>>>> jaxb, jaxws, sjsxp, stax-ex,saaj?
>>>>>>>
>>>>>>> Since all these technologies are bundled in
>>>>>>> webservices-rt/webservices-tools.jar and the 1.1.2-SNAPSHOT
>>>>>>> version of metro is already on maven repository
>>>>>>> Imaybe we should just refer to webservices-rt,webservices-api
>>>>>>> and webservices-tools in our dependencies
>>>>>>>
>>>>>>> The only case maybe where Kohsuke suggested sjsxp (people just
>>>>>>> wanting to use the parser may not want to get the whole metro
>>>>>>> stack)
>>>>>>> In that case we can let the dependency for sjsxp remain in the
>>>>>>> poms but for other technologies I can just update the poms to
>>>>>>> use metro.
>>>>>>>
>>>>>>> Do other modules see issues with that?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Bhakti
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>