Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] TAB completion, History, port binding

Hi Glyn,

I extended the debug&trace pointcuts as you suggested:

	pointcut telnetConsole() : within(org.eclipse.virgo.console..*);

	pointcut debugCandidate() : execution(public * *(..)) && !setter() && !getter() && !medic() && !util() && !repository() && !kernelUserRegion() && !webClassLoading() && !logback() && !telnetConsole();

	pointcut traceCandidate() : execution(!public * *(..)) && !setter() && !getter() && !medic() && !util() && !repository() && !kernelUserRegion() && !webClassLoading() && !logback() && !telnetConsole();



This reduced the size of the generated JAR in half and the decompiled code seems to be clean. However the bundle cannot attach to the framework and I found that the bytecode still contains aspect and logging stuff:

	Synthetic@ajc$org_eclipse_virgo_medic_log_EntryExitTrace$ptwAspectInstance


I hope I'm missing something here :) Do you have an idea if something else has to be changed besides the debug/trace pointcuts?

Regards,
Hristo Iliev


-----Original Message-----
From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
Sent: Friday, October 08, 2010 5:48 PM
To: Virgo Project
Subject: Re: [virgo-dev] TAB completion, History, port binding

Hi Hristo

Ah sorry - my misunderstanding.

Since shell function has traditionally been in the kernel repo, I'd like to keep it there. But you can certainly implement the first of the approaches below by tweaking the entry/exit tracing aspect in medic to exclude a specific package that contains this new (kernel) code.

See medic commit 8d92590352e84d94a76e6f2cb6570f970df9cb3b for a recent example of how to do this. Note that the pointcut can become very long without impacting runtime performance as we use compile-time weaving.

Since you can't ripple, do a clean clean-integration build of medic and then copy the medic JARs in each project's target/artifacts on top of the corresponding JARs in the kernel's ivy cache and then rebuild the kernel with clean and clean-integration to apply the modified aspect. You actually only need the medic JAR and not medic.core if you are only changing the aspect.

When you get to making a contribution, we can apply a patch to medic and ripple it up before applying a patch to the kernel.

Hope that helps.

Regards,
Glyn

On 8 Oct 2010, at 15:38, Iliev, Hristo wrote:

> Hi Glyn,
> 
> I was not quite clear in my mail - sorry for this.
> 
> Since this fragment is also an extension it has more restrictions: no imports can be added.
> 
> To solve the issue I can think of two approaches:
>        * disable the automatic injection of logging for this fragment bundle
>        * move the code in other package - using the code with com.sap packages works ok
> 
> Do you think that the move outside the kernel can work?
> 
> Regards,
> Hristo Iliev
> 
> -----Original Message-----
> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
> Sent: Friday, October 08, 2010 5:22 PM
> To: Virgo Project
> Subject: Re: [virgo-dev] TAB completion, History, port binding
> 
> Use a template.mf to configure the behaviour of bundlor. See the bundlor home page for details:
> 
> http://www.springsource.org/bundlor
> 
> Regards,
> Glyn
> 
> On 6 Oct 2010, at 14:12, Iliev, Hristo wrote:
> 
>> Hi,
>> 
>> Since the features are implemented as fragment to the system bundle I cannot actually include these imports.
>> 
>> I guess the best way would be to add some ignore/exclude rules. Is there an easy way to do this?
>> 
>> Regards,
>> Hristo Iliev
>> 
>> 
>> -----Original Message-----
>> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
>> Sent: Friday, September 24, 2010 6:56 PM
>> To: Virgo Project
>> Subject: Re: [virgo-dev] TAB completion, History, port binding
>> 
>> Ok, then since "telnet" is a kernel project, it *will*M be advised by EntryExitTrace.aj.
>> 
>> If you compare to the "core" project, you'll see the following in the bundlor template.mf:
>> 
>> Import-Template:
>> org.eclipse.virgo.util.*;version="${org.eclipse.virgo.util:[=.=.=, =.+1)}",
>> org.eclipse.virgo.medic.*;version="${org.eclipse.virgo.medic:[=.=.=, =.+1)}",
>> org.slf4j.*;version="${org.slf4j:[=.=.=, +1)}",
>> org.aspectj.*;version="${org.aspectj:[=.=.=.=, +1)}",
>> 
>> Since bundlor scans the bytecode, it will detect the necessary packages which will then be versioned according to the properties in the build.versions file at the root of the kernel git repository.
>> 
>> We did maintain a new project creation script for a while, but it wasn't particularly thorough and it ended up being more reliable to copy an existing project as a basis for a new project and then cut out everything which was obviously project-specific and then eye-ball/edit the rest. This is the kind of thing which would be good to discuss face to face in due course. Meanwhile, please ask any questions as you feel your way and perhaps between us we can document something reasonable on the wiki.
>> 
>> Regards,
>> Glyn
>> 
>> On 24 Sep 2010, at 15:14, Iliev, Hristo wrote:
>> 
>>> Hi,
>>> 
>>> I'm trying to integrate it in virgo kernel under
>>>     org.eclipse.virgo.kernel.telnet
>>> 
>>> Does this mean that I would need medic, slf4j and aspectj as import package statements in the manifest?
>>> 
>>> Is there some documentation on the "minimum requirements" for a new bundle in Virgo? I took a look at the wiki so I hope I didn't miss it.
>>> 
>>> Regards,
>>> Hristo Iliev
>>> 
>>> -----Original Message-----
>>> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
>>> Sent: Friday, September 24, 2010 4:36 PM
>>> To: Virgo Project
>>> Subject: Re: [virgo-dev] TAB completion, History, port binding
>>> 
>>> Hi Hristo
>>> 
>>> It depends how you are building your code. The aspect:
>>> 
>>> org.eclipse.virgo.medic/org.eclipse.virgo.medic/src/main/java/org/eclipse/virgo/medic/log/EntryExitTrace.aj
>>> 
>>> applies to most of Virgo, so that could be part of the issue you are seeing. Which git repo are you building this function into?
>>> 
>>> Regards,
>>> Glyn
>>> 
>>> On 24 Sep 2010, at 12:39, Iliev, Hristo wrote:
>>> 
>>>> Hi,
>>>> 
>>>> Thanks for the feedback. I'll try to address all these issues.
>>>> 
>>>> One thing I forgot to mention is the presence of grep. The implementation is a bit odd due to the lack of real piping in 3.6, but it works in most cases.
>>>> 
>>>> I'm porting the bundle to Virgo, but obviously something is wrong since on start the following logs are produced:
>>>>    SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
>>>>    SLF4J: Defaulting to no-operation (NOP) logger implementation
>>>>    SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
>>>>    [2010-09-24 14:37:54.023] startup-tracker              <KE0001I> Kernel starting.
>>>> 
>>>> The strange thing here is that when using the bundle with sap packages no logs are produced. The supportability logs do not contain anything related.
>>>> 
>>>> Can it be that having the code in org.eclipse.virgo packages triggers some modifications and requires additional imports?
>>>> 
>>>> Regards,
>>>> Hristo Iliev
>>>> 
>>>> -----Original Message-----
>>>> From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Glyn Normington
>>>> Sent: Friday, September 24, 2010 2:26 PM
>>>> To: Virgo Project
>>>> Subject: Re: [virgo-dev] TAB completion, History, port binding
>>>> 
>>>> Another glitch turned up in further playing:
>>>> 
>>>> 5. tab completion fails to complete the more and disconnect commands:
>>>> 
>>>> osgi> disc
>>>> No such command
>>>> osgi> m
>>>> No such command
>>>> osgi>
>>>> 
>>>> Regards,
>>>> Glyn
>>>> 
>>>> On 24 Sep 2010, at 12:18, Glyn Normington wrote:
>>>> 
>>>>> Hi Hristo
>>>>> 
>>>>> I tried it out and the basic function seems to work nicely, which will be really pleasing for long-suffering Equinox console users, but there were some glitches, mostly in tab completion.
>>>>> 
>>>>> 1. Backspace delete didn't work as expected, on a Mac. I would expect it to delete the character to the left of the cursor and move the cursor left. Instead it seemed to behave just like the delete key.
>>>>> 
>>>>> 2. If you enter a valid command like
>>>>> 
>>>>> osgi> bundles
>>>>> 
>>>>> followed by a space and then attempt to tab complete (to see what might be valid input next), it prints out a message and takes you back to the starting prompt:
>>>>> 
>>>>> osgi> bundles
>>>>> No such command
>>>>> osgi>
>>>>> 
>>>>> 3. It won't tab complete the help command:
>>>>> 
>>>>> osgi> hel
>>>>> No such command
>>>>> osgi>
>>>>> 
>>>>> 4. tab completion from the prompt alone does nothing (rather than suggesting all the possible commands).
>>>>> 
>>>>> Anyone else wanting to try this out should note that, instead of step 3 below, they need to place the bundle com.sap.core.supportability.telnet.jar in lib/kernel and add the bundle to the start of the launcher.bundles property in lib/org.eclipse.virgo.kernel.launch.properties, thus:
>>>>> 
>>>>> launcher.bundles =\
>>>>> file:lib/kernel/com.sap.core.supportability.telnet.jar,\
>>>>> file:lib/kernel/com.springsource.slf4j.api-1.6.1.jar@start,\
>>>>> <etc>
>>>>> 
>>>>> Regards,
>>>>> Glyn
>>>>> 
>>>>> On 23 Sep 2010, at 16:44, Iliev, Hristo wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I finally managed to get the console extension bundle (attached) running in Virgo.
>>>>> 
>>>>> To test it:
>>>>> 1.       Use Virgo with Equinox 3.6 - either replace the one in lib or use latest build
>>>>> 2.       Enable console port in org.eclipse.virgo.kernel.userregion.properties
>>>>> 3.       Place the attached bundle in lib
>>>>> 4.       Connect via telnet
>>>>> 
>>>>> The bundle uses hook to replace the standard console with one with more features like:
>>>>> *         TAB completion - using TAB you can complete the command you type or list the possible commands starting with the entered string. Not pluggable but this can be extended in the future.
>>>>> *         History
>>>>> o   using the arrows you can get the previous or the next command you typed
>>>>> o   Page Up/Down brings the first/last command
>>>>> *         Port binding - the console port can be bound to a specific network interface (identified by hostname or IP) in the format <host/IP>:<port>. This can be used to allow connections only from localhost for increased security. For instance: osgi.console=localhost:2401
>>>>> *         Line editing - backspace and arrows now work as expected
>>>>> 
>>>>> I'm now starting to integrate this in Virgo. Hopefully the features will be available till the mid of October and will reach post 2.1.0 versions.
>>>>> 
>>>>> Regards,
>>>>> Hristo Iliev
>>>>> <com.sap.core.supportability.telnet.jar.zip><ATT00001..txt>
>>>>> 
>>>>> _______________________________________________
>>>>> virgo-dev mailing list
>>>>> virgo-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>>> 
>>>> _______________________________________________
>>>> virgo-dev mailing list
>>>> virgo-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>>> _______________________________________________
>>>> virgo-dev mailing list
>>>> virgo-dev@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>> 
>>> _______________________________________________
>>> virgo-dev mailing list
>>> virgo-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>>> _______________________________________________
>>> virgo-dev mailing list
>>> virgo-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>> 
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
>> _______________________________________________
>> virgo-dev mailing list
>> virgo-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> 
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/virgo-dev

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev


Back to the top