A Java dependency problem

[John]

Hi,

I like to evaluate pococapsule for a C++ project. I wonder why
pococapsule depended on Java? It would be uneasy for us if our C++
project needs to depend on Java runtime. Could this Java dependency be
removed or replaced? If to replace it, how much effort it would be?

Thanks,

John

[Ke Jin]

Hi Jon,

PocoCapsule comes with two XML readers out-of-the-box (users can
implement their own). The first one (xmlreader.so/dll) is pure C++
based which has zero dependency to Java. Another XML reader
(xslreader.so/dll) is implemented in Java but supports DSM through
XSLT. Both of these two readers are detached from PocoCapsule runtime.
To choose which one to be used by PocoCapsule container runtime, you
just link the chosen one with the container.

If you do not use DSM, there is zero cost for you to replace the Java
xslreader by the pure XML xmlreader by simply change the C++ link line
commend option. If you do use DSM (through XSLT) and still want to
avoid runtime dependency to Java, you could do the DSM translation off-
line using the pxtransform or pxencode commends and use the translated
or encoded results as input configuration documents.

See more detail answers in the thread <http://groups.google.com/group/
pococapsule/browse_thread/thread/9986e150bc7e1167#>

Regards,
Ke

[John]

Thanks for your quick response.

Another doubt is that why you use system specific wiring such as

<load library=”./TickGenImpl.$dll”/>

Would it be possible to determine the OS and then append the suffix
(.so or .dll) automatically? Or use some configuration file to
externalize these properties like the property file in Spring?

I know C++ does not support package structure to directory structure
mapping such as com.mycompany is mapping to com/mycompany in Java. But
in your framework, you can use this as a conversion, i.e., conversion
over configuration. That is to say, you can still use Java style
"com.mycompany.TickGenImpl". Then, you can even remove the <load
library ...> part. What do you think?

Thanks,

John

[Ke Jin]

John,

Thanks for your questions. See inline answers.

Ke

On Oct 23, 12:26 pm, John <john.jian.f...@gmail.com> wrote:
> Thanks for your quick response.
>
> Another doubt is that why you use system specific wiring such as
>
> <load library=”./TickGenImpl.$dll”/>
>
> Would it be possible to determine the OS and then append the suffix
> (.so or .dll) automatically? Or use some configuration file to
> externalize these properties like the property file in Spring?
>

You certainly don't need to use the "$" sign substitution if you know
the configuration file is only going to be used on a specified system.
For instance, you can simply write:

<load library="./tickGenImpl.dll"/> on windows or,

<load library="./tickGenImpl.so"/> on linux or solaris.

The "$" substitution notion is an option not mandatory (similar to the
"$" or "%" substitution in OS command lines or scripts). If you use
it, PocoCapsule will perform the replacement based on the platform.
This is largely there for convenience of our out-of-box examples (and
certainly for users who playing those examples). We don't want to
write two (or even more) versions of configuration files for these
examples, each for a specific OS just b/c their dynamic library use
different suffices on different platforms.

> I know C++ does not support package structure to directory structure
> mapping such as com.mycompany is mapping to com/mycompany in Java. But
> in your framework, you can use this as a conversion, i.e., conversion
> over configuration. That is to say, you can still use Java style
> "com.mycompany.TickGenImpl". Then, you can even remove the <load
> library ...> part. What do you think?
>

There are several issues:

1. Different users may put (and even move) a same library in (to)
different places and simply list the directory in LD_LIBRARY_PATH (or
PATH) environment (which PocoCapsule will looking through). It is not
very common that the configuration writers would be able to know the
location of the dynamic libraries and could hard coded full package
path at configuration time.

2. It is not uncommon that <load library> is need to load libraries
that contain class/symbols not explicitly referred in <bean>'s "class"
attribute. For instance (like in almost of our out-of-box examples),
if users build their generated IoC proxies into separate libraries,
these proxy classes/symbols are not referred in the XML configuration
documents at all. Users then have to either hard link these proxies
into the container (which is considered to be a bad practice), or use
<load library> to specify which proxies libraries are needed.

3. A same library could container multiple classes (instead of one per
class file for java). User may repackage the library to package some
classes object files to another libraries (very common in case of
making patch releases). C/C++ linkers/loaders have various rules to
deal with such cases that needs to be respected by PocoCapsule and
configurations. Therefore, it is not a good idea to hardcode class
directory path in configuration documents.

Also, the design philosophy of PocoCapsule is to provide mechanisms
but avoid to impose usage policies (especially those that are useful
for a few uncommon usage scenarios). The usage case described by you
(i.e. implicitly referring library path in "class" attribute) should
be easily doable by a simple DSM XSLT transformation (the XSLT
stylesheet shouldn't be longer than 50 lines of code).

Thanks again,
Ke