Marcin Miłkowski wrote:
Stephan Bergmann pisze:
Marcin Miłkowski wrote:
Hi,

I'm implementing a class that implements a known OOo service (actually, several ones, but the important one is XGrammarChecker). The problem is that the class is instantiated many times in OOo whenever a UI item is used, and the instances created do not share data.

Note that com.sun.star.linguistic2.XGrammarChecker is an interface, not a service.

Of course, but anyway I'm not implementing any code that displays public methods other than documented in API.

Sorry, I do not understand you here. (But that's probably not so important, anyway.)

New UNOIDL ("singleton Foo: XBar;") is not needed here---it would declare that there is a singleton UNO object obtainable with a certain name at the global component context. Rather, you want to change the details of a Java implementation of some UNO object.

Great to hear that!

Your __getServiceFactory method is the place to turn to. Let it return a com.sun.star.lang.XSingleComponentFactory whose createInstanceWithContext and createInstanceWithArgumentsAndContext methods control the number of instances generated (which might be difficult for example if you need to support non-trivial argument lists, which I do not know since XGrammarChecker is an interface and not a service).

No, there are no argument lists. I tried this:

public static XSingleComponentFactory __getServiceFactory(final String sImplName, final com.sun.star.lang.XMultiServiceFactory serFactory, final XRegistryKey regKey) {
    XSingleComponentFactory xFactory = null;
    if (sImplName.equals(Main.class.getName())) {
xFactory = Factory.createComponentFactory(Main.class, Main.getServiceNames());
    }
    return xFactory;
  }

I also have __getComponentFactory (without it, OOo complained about missing parts of XInterface):

public static XSingleComponentFactory __getComponentFactory(final String sImplName) {
    XSingleComponentFactory xFactory = null;
    if (sImplName.equals(Main.class.getName())) {
xFactory = Factory.createComponentFactory(Main.class, Main.getServiceNames());
    }
    return xFactory;
  }

Sorry for causing confusion. The latest style is to implement __getComponentFactory and have it return XSingleComponentFactory (an older alternative would be to implement __getServiceFactory and have it return XSingleServiceFactory; see jurt/com/sun/star/comp/loader/JavaLoader.java:1.16).

All it caused, however, was that classpath suddenly covered files that are not in the manifest.xml (we have some jars that are not on the classpath and should not be touched by OOo). But multiple instances of the service are anyway created.

I do not understand your first part (about classpath), but multiple instances are of course still generated when you use com.sun.star.comp.loader.FactoryHelper.createComponentFactory in __getComponentFactory. You have to return your own implementation of XSingleComponentFactory from __geComponentFactory, which controls the number of instances generated.

Let me just say why I need a singleton class:

1) performance reasons (but we don't actually create all memory-intensive classes in the creator, so it's not so critical)

2) we need to maintain state between an options dialog that should be able to use the first instance's registered listeners to inform them that the document should be rechecked when options have changed. Now, as options dialog opens in a new instance, the new instance has no listeners attached, so we cannot use them. I used a workaround with checking the last modified date of the config file but it works only when the document is still being checked and the first instance is called.

This sounds horribly broken.

Maybe there is another design that I could use for sharing instance data? Adding a new public method to the class wouldn't help as calling it would call still another instance that has no listeners attached.

However, be aware that XGrammarChecker has methods like startDocument documented as "This enables the grammar checker to maintain state information about the document".

Yes, but they will be called by the grammar checker iterator for a document, so they will get into the first instance of my class anyway. I have no problem with them at all.

What happens if two documents are grammar checked in parallel?

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to