Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ve-dev] Registry contribution occurs too late?

I understand. The JEM registry contribution knows nothing about the VE or which particular VM is being initialized, so my question was kind of foolish.
 
However, I like your suggestion for listening to the preferences, so I will make use of that for now.
 
Thanks again for taking the time to explain the Visual Editor's architecture to me more thoroughly,
and for your suggestions for workarounds.
 
    Darren
-----Original Message-----
From: ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx]On Behalf Of Rich Kulp
Sent: 13 June 2006 14:58
To: Discussions people developing code for the Visual Editor project
Subject: RE: [ve-dev] Registry contribution occurs too late?


Hi,

There isn't a direct way of doing that. There isn't something that says "I'm initializing the VE remote vm". There also isn't anything saying this VM is for Beaninfo versus one for the editor.

The best I can suggest until we get such extension that listens for preference changes would be for you to provide a configuration contributor that does on initializeRegistry:

Create (or access) a global preference change listener that you create the first time a vm is initialized. It listens for your preference change. You register the just created vm with this listener. The listener will:
   a) Add itself as preference change listener.
   b) When a vm is registered with it:
        (i) It will put the vm into a list of registered vm's.
        (ii) It will add a registry termination listener to the new vm.
                This listener will remove the vm from its own list at termination of the vm. And if there are no more vm's registered it
                 will  also remove itself as a listener to preference changes and null itself out of the global. This is so that it doesn't hang around when no longer needed.
        (iii) It will initialize the vm with the current preferences.
   c) Whenever the preferences change, it will go through its list of vm, and reapply the changes to them.

Rich


Darren Hurt <darren.hurt@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/13/2006 05:46 AM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>

To
"'Discussions people developing code for the Visual Editor project'" <ve-dev@xxxxxxxxxxx>
cc
Subject
RE: [ve-dev] Registry contribution occurs too late?





 
Hello again Rich,
 
 
 
The initialization I need isn't editor specific, it is analogous to the look and feel configurations in that it needs to be applied after changes in
the preferences.
 
The fact that an editors VM has already been initialized by the previous editor completely explains
why we have to open and close an editor to make the changes take effect, and I understand that better now, so thanks for that.
 
I think the extra extension point for contributing when an editor receives a new VM (the spare or whatever)  is the ideal solution to my problem, and i'll put in a request for that.
 
In the meantime, more questions I'm afraid.
 
My initialization needs to be applied only to the VM's that are used to open up bean customizers.
I guess this is the editors VM.
How do I make it so that my contributions only get applied to this VM, and not to the BeanInfo VM as well?
 
Thanks,
    Darren
 
 

-----Original Message-----
From:
ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx]On Behalf Of Rich Kulp
Sent:
31 May 2006 20:31
To:
Discussions people developing code for the Visual Editor project
Subject:
RE: [ve-dev] Registry contribution occurs too late?


Hi,


No, each editor gets one VM. It's just that we have a spare vm sitting around waiting to make it more responsive when you open a new editor. As soon as the new editor needs a VM, the spare VM is given over to it, and then a new spare is created for the usage of the next editor. And at that time the contributors are run.


There may also be one other VM for a project. This one is used for BeanInfo introspection. It is a separate VM then the one used by the editor. It is shared for all introspection from any editor within the project.


There is a little history behind this. The concept of the contributor for the registry was created before we had spare vm's. They are used when starting ANY vm from within the project, both the editor's vm and the BeanInfo's vm. Before we had the spare then when the editor started up a new vm was immediatly created (or when start a new vm for the editor) the contribution would run. So at that time there was a one to one relationship that could be counted on to start when the editor started.


It is a good suggestion that we have a contributor that will run whenever the editor is started or a new vm is given to the editor (there are times where the editor needs a new vm even though the editor has not been closed. An example of this is if the project's classpath changes. In that case we need a new vm because it has a new classpath, but the editor didn't close. It just accepts the new vm that is given to it at that time). You could open a enhancement request that we add contribute to registry to the IVEContributor extension too. This would be used whenever the editor gets a new VM. We can't use the same contributor as we use when starting VM's because those editors are registered with org.eclipse.jem.proxy plugin, which is a general purpose registry API. It is not specific to the VE editors.


What kind of initialization do you need to do that it is editor specific and not project specific?


Thanks,

Rich



Darren Hurt <darren.hurt@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

05/31/2006 12:29 PM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>


To
"'Discussions people developing code for the Visual Editor project'" <ve-dev@xxxxxxxxxxx>
cc
Subject
RE: [ve-dev] Registry contribution occurs too late?







   
Yes, that sounds like it explains what is happening.

 
 

>From the way I have understood it (incorrectly it seems), the registry is just a means of communicating with the target VM.

I have been under the assumption that each editor starts up its own java process that is used for the component instances and customizers.

I assumed that each time you open an editor, this target VM is started up.

In fact I have been assuming that the registry and target VM are in 1-1 correspondence, and that when the VM is started up, a new registry is created,
and the contributions are applied through it.

 
 

You seem to be saying that this is not the case.

Are you saying that the target VM processes are being reused, even though an editor has been closed?

 

It does seem that it would be useful to have an extension point for contributions/communication that needs to occur every time a new editor
is opened. This could apply to the Look and feel settings for example.

 

 
I would be very grateful if you could possibly explain a bit more about the relationship between the registry and the target VM's, and when exactly they are started
up.

I have been slightly surprised when remote debugging, the editor has asked for a port number twice, which seems to imply that  there are a couple of VM's hanging around.

 
 
   Thanks,

               Darren Hurt

 
 
 

-----Original Message-----
From:
ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx]On Behalf Of Rich Kulp
Sent:
31 May 2006 16:43
To:
Discussions people developing code for the Visual Editor project
Subject:
Re: [ve-dev] Registry contribution occurs too late?



Hi,


Are you talking about some type of dynamic setting that will be different each time? If so then you current can't. The contribution does occur before the editor gets the registry, but the thing is we keep a spare registry laying around to speed up opening the editor the second time, or after a classpath change. So the contribution occurs when the spare registry opens up, and then at some later time the editor uses that registry.


Typically the contributions are not time-dependent or editor dependent. They are usually class path dependent. For example when JFace is in the classpath the contribution will initialize some JFace classes for us. Since at the time of creation of the registry it is not known what editor will use it, there is no editor specific contribution.


It is a known problem that look and feel doesn't change until we use up the spare registry and create a new one.


Rich

Darren Hurt <darren.hurt@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

05/31/2006 09:03 AM

Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx>


To
"'Discussions people developing code for the Visual Editor project'" <ve-dev@xxxxxxxxxxx>
cc
Subject
[ve-dev] Registry contribution occurs too late?









I have some eclipse preferences that I pass to the target VM via the registry contribution mechanism.

However, in order for these changes to take effect I have to open and close an editor first, before opening
up the editor that I actually want to make changes in.


It seems that the registry contribution occurs too late.

By the way, this is also true when you change the look and feel visual editor configurations.


Is this something you are aware of, and is there any way to make the registry contribution occur earlier?

I am working on top of VE 1.1.0.1.


Thanks,


  Darren Hurt

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

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


Back to the top