dev@glassfish.java.net

Re: SSH2 dependency added to logging

From: Jerome Dochez <jerome.dochez_at_oracle.com>
Date: Thu, 2 Sep 2010 13:19:02 -0700

On Sep 2, 2010, at 2:08 AM, Naman Mehta wrote:

>
> hi jerome, sahoo,
>
> The collect-log-file command is apllicable to server/standalone instance/cluster. So do I need to move the same?
>
> Right now, LogFilterForInstance.java contains all ssh related code. And LogFilter.java and CollectLogFiles.java uses LogFilterForInstance methods ("new LogFilterForInstance().<method name>").
>
> And my osgi.bundle file contains following entry:
> -exportcontents: com.sun.enterprise.server.logging.logviewer.backend, com.sun.enterprise.server.logging.diagnostics, com.sun.enterprise.server.logging
>
> Import-Package: \
> org.glassfish.cluster.*;resolution:=optional, \
> *
>
so does the code function properly (meaning the log file is returned) even when org.glassfish.cluster package is not resolved ?

> So, is it fine to move just LogFilterForInstance.java file outside logging module?
>
yes

> Regards,
> Naman
>
>
>
> On Thursday 02 September 2010 11:00 AM, Sanjeeb Sahoo wrote:
>> The current matadata would lead to early resolution of bundles, but that can be fixed by use of DynamicImport-Package instead of optional Import-Package, but we won't do that. After discussing the issue at length with Jerome, the conclusion is to move the cluster/logging code to some cluster aware module as originally suggested by Jerome. This is so that cluster/logging commands won't even show up when someone does asadmin list-commands in nucleus distro. Naman to do the needful.
>>
>> Thanks,
>> Sahoo
>>
>> On Wednesday 01 September 2010 09:48 PM, Tom Mueller wrote:
>>> Also, does the optional dependency cause the module to always load if it is there? This means that the Cluster SSH module is resolved at domain startup time even if the cluster feature is not being used. This contributes to the startup time regression.
>>>
>>> Tom
>>>
>>>
>>> On 9/1/2010 11:03 AM, Jerome Dochez wrote:
>>>> that will not completely work as cluster related commands like CollectLogFiles will still appear in the nucleus distribution, right ?
>>>>
>>>> jerome
>>>>
>>>> On Aug 31, 2010, at 11:20 PM, Sanjeeb Sahoo wrote:
>>>>
>>>>> I don't think we need to move classes around. I had told Naman to have optional dependency on SSH. Atleast that's how the OSGi metadata is setup:
>>>>>
>>>>> org.glassfish.cluster.ssh.launcher;resolution:=optional;version="3.1",org.glassfish.cluster.ssh.sftp;resolution:=optional;version="3.1"
>>>>>
>>>>> The logging code is also written such that it works in the absence of SSH packages. So, I think if logging adds a provided scope dependency on SSH artifacts, things will be sorted out.
>>>>>
>>>>> Sahoo
>>>>>
>>>>> On Wednesday 01 September 2010 11:33 AM, Jerome Dochez wrote:
>>>>>> Naman
>>>>>>
>>>>>> I believe you are the one who added the LogFilterForInstance and other cluster related classes like CollectLogFiles in the logging module. We cannot have such dependencies added to a module that ships with nucleus and not clustered distributions (like the RI).
>>>>>>
>>>>>> Can you move those classes to a cluster specific module like admin-cluster or define a new module logging-cluster to add those capabilities there.
>>>>>>
>>>>>> thanks, jerome
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>
>