directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: [ApacheDS] Stored Procedures: One language id per StoredProcEngineConfig and StoredProcEngine, Stateful vs. Stateless
Date Mon, 05 Nov 2007 21:30:08 GMT
On 11/5/07, Stefan Zoerner <stefan@labeo.de> wrote:
>
> Hi all!


Hi Stefan,

The current interface StoredProcEngineConfig from
> org.apache.directory.server.core.sp
>
> basically looks like this:
>
> ---
>
> interface StoredProcEngineConfig
> {
>      /**
>       * Returns the type of the associated {@link StoredProcEngine}.
>       */
>      Class<? extends StoredProcEngine> getStoredProcEngineType();
>
>
>      /**
>       * Returns the unique language identifier of the {@link
> StoredProcEngine}.
>       */
>      String getStoredProcLangId();
> }
>
> ---
>
> The interface StoredProcEngine has only one SPLangId, as well.
>
> This makes it hard to provide a StoredProcEngine implementation for more
> than one language. I have started a BsfStoredProcEngine, and ran into
> two problems:
>
> * My StoredProcEngine should be able to support several scripting
> languages, but I can only return one of them as SPLangId
>

I am not sure that you need to specify each language supported by BSF with a
distinct Id. I think only an Id such as "BSF" is enough. Because from the
point of view of the ExecutionEngine it won't matter which specific language
is being used as the BSF provider. All of those providers can support Java
objects passed as parameters. The BSF abstraction provides other useful
tools to handle all the languages with a single API, as far as I remember.

I had developed a prototype implementation for Javax Scripting API languages
here:

http://svn.apache.org/viewvc/directory/sandbox/ersiner

It's really not tested well but it may give some idea.

* The only way to create my class currently is the default constructor.
> Thus I am not able to use Spring to configure my StoredProcEngine
>
> I would like to modify the interfaces in order to support
> StoredProcEngines with more than one language, and to configure them
> with properties.


As I said before feel free to modify any part of the SP subsystem. I did not
make it very flexible because when I refactored the code the server
configuration system was being refactored extensively. So I had left DI out
temporarily.

Before I can propose concrete changed, I have a question (probably to Ersin)
>
> The StoredProcEngine life cycle seems to presume that there is an
> instance for each stored procedure. How often are the methods
> * setSPUnitEntry
> * invokeProcedure
> presumed to be called?
>

They are invoked upon each SP call.

Currently, the implementation within StoredProcExecutionManager looks
> like a new StoredProcEngine is created for each call. The methods will
> be called one after the other. Is a StoredProcEngine supposed to be
> stateful or stateless?


And they are stateful.

BTW I had faced also some other restrictions to be able to support SPs from
both over the wire and from the core. So some of the difficulties about
extending the system can be caused by such limitations.


Thanks in advance,
>      Stefan



Thanks for working on this and sharing your thoughts Stefan.


-- 
Ersin

Mime
View raw message