|
Home > Archive > Apache Directory Project > November 2007 > [ApacheDS] Stored Procedures: One language id per StoredProcEngineConfig
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[ApacheDS] Stored Procedures: One language id per StoredProcEngineConfig
|
|
| Stefan Zoerner 2007-11-05, 7:11 pm |
| Hi all!
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
* 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.
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?
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?
Thanks in advance,
Stefan
| |
| Stefan Zoerner 2007-11-06, 7:11 am |
| Hi Chris and Ersin!
Chris Custine wrote:
> I vaguely remember running into these issues a while back as well. I
> think the problem is differentiating which scripting language the script
> is written in so that the BSF Scripting Manager can retrieve the correct
> script engine internally (by extension, name, or mime type). Is that
> the same issue you are having Stefan?
I thought I have. But due to the sample implementation for Java 6
Scripting, Ersin provided in his sandbox, I learned an alternative.
Thank you Ersin for the link!
Ersin stores the concrete scripting language in the attributes of the SP
entry. So the engine has a chance to determine the correct scripting
language, because it knows this attribute (provided via setSPUnitEntry).
In this case, storedProcLangId has a generic value "JavaxScript". This
would solve my problem of how to determine the right language, but I
think the name storedProcLangId is somehow misleading then. Basically,
you store both the engine and the language within the entry. I would
prefer to store only the language, and leave the selection of the engine
up to the StoredProcExecutionManager.
I think I will try to complete my BSF implementation with the solution
Ersin provided first, in order to have more knowledge to discuss.
Thanks for your insights,
Stefan
|
|
|
|
|