XSL jvm dependency

[Paul C]

After building from the source code, I stumbled onto the xslreader.C
dependency on java and pocotools.jar. Is it correct that the XSL
processing step requires a jvm and a jar library? Is that the only
reason for including java? Any details would be greatly appreciated.
If there is a java dependency, then why not just create a tool to
generate jni interfaces to poco c++ classes and use Spring instead of
pococapsule for IoC?

[Ke Jin]

On Aug 22, 8:22 am, Paul C <pkci...@gmail.com> wrote:
> After building from the source code, I stumbled onto the xslreader.C
> dependency on  java and pocotools.jar.  Is it correct that the XSL
> processing step requires a jvm and a jar library?

What is the definition of "correct" or "non-correct"? Supporting XSLT
does not necessary to use Java. A C++ XSLT engine (such as Xalan-C++)
could certainly be integrated. But I don't feel such a necessity to
worth the effort. This has been answered before in the following
thread:

http://groups.google.com/group/pococapsule/browse_thread/thread/9986e150bc7e1167?hl=en

> Is that the only
> reason for including java?

Yes.

> Any details would be greatly appreciated.

See above discussion.

> If there is a java dependency, then why not just create a tool to
> generate jni interfaces to poco c++ classes and use Spring instead of
> pococapsule for IoC?

Please try it. Once getting into details, I guess, you would find the
answer.

Ke

[Paul C]

I can see your point about configuration and deployment in testing and
development needing the XML support more than a production environment
(in theory). However, it happens that the XML and XSL support without
Java is a requirement for the particular production environment I am
thinking about. XML configurations are modified dynamically in the
field/production environment (with a simple text editor). It also
requires the use of configuration variables in a properties file being
pulled into the configuration similar to java property files in ANT or
Spring.

Its great that pococapsule is out there and I am still learning about
it. It takes time to find the best suited approach to do things with
Pococapsule since its new to me. Regarding a tool to build jni
wrappers to poco's for generic IoC control from Java containers like
Spring, is there something in particular you find unpractical about
that approach?

On Aug 22, 11:47 pm, Ke Jin <kjin...@gmail.com> wrote:
> On Aug 22, 8:22 am, Paul C <pkci...@gmail.com> wrote:
>
> > After building from the source code, I stumbled onto the xslreader.C
> > dependency on  java and pocotools.jar.  Is it correct that the XSL
> > processing step requires a jvm and a jar library?
>
> What is the definition of "correct" or "non-correct"? Supporting XSLT
> does not necessary to use Java. A C++ XSLT engine (such as Xalan-C++)
> could certainly be integrated. But I don't feel such a necessity to
> worth the effort. This has been answered before in the following
> thread:
>

> http://groups.google.com/group/pococapsule/browse_thread/thread/9986e...

[Ke Jin]

Hi Paul,

See inline responses.

Thanks!
Ke

On Aug 23, 6:19 am, Paul C <pkci...@gmail.com> wrote:
> I can see your point about configuration and deployment in testing and
> development needing the XML support more than a production environment
> (in theory). However, it happens that the XML and XSL support without
> Java is a requirement for the particular production environment I am
> thinking about. XML configurations are modified dynamically in the
> field/production environment (with a simple text editor). It also
> requires the use of configuration variables in a properties file being
> pulled into the configuration similar to java property files in ANT or
> Spring.
>

1. XML support without Java is already supported by PocoCapsule. You
just need to link (or pre-load) the C++ based XML reader (i.e. the
libpocoxml.so or pocoxml.dll) with the container, then, the container
will not attempt to load/use the java based XML reader. For XSLT
handling, if it is that necessary, you can extend the C++ XML reader
to support XSLT by integrating with the C++ Xalan. By the way, Spring
does not support XSLT at all.

2. XML configuration dynameic modification is also already supported
and documented and used by heavily and transparently used by
PocoCapsule's CORBA support module. Please look for "env-var" in user
guide.

> Its great that pococapsule is out there and I am still learning about
> it. It takes time to find the best suited approach to do things with
> Pococapsule since its new to me. Regarding a tool to build jni
> wrappers to poco's for generic IoC control from Java containers like
> Spring, is there something in particular you find unpractical about
> that approach?
>

There is no advantage with that approach or even more trouble than
worth. For instance, the lifecycle control of C++ objects is
significantly different from Java objects. These control primitives
are missing in Spring's schema. etc.. Besides, as pointed out in the
previous discussion:

http://groups.google.com/group/pococapsule/browse_thread/thread/9986e150bc7e1167?hl=en

Pococapsule allows runtime to work without Java if users want to, even
if XSLT is used in configurations.

[Ke Jin]

Other issues includes:

1. Spring only supports constructor and setter injections while C++
applications are more likely need generic "post-instantiation-
invocation" on arbitrary member functions for dependnecy injections.
See the discussion of <property> in section 3.3 of PocoCapsule's user
guide document.

2. C++ has the concept of pointers (actually, by default, functions
return pointer types). How you going to express pointer types in
Spring's XML? Explicitly use the "pointed-to" types in user XML? In
some cases, a C++ pointer type may not even have its corresponded
"pointed to" object type (for instance, function pointers) or may not
have a portable "pointed-to" type (for instance, the actual "pointed-
to" type of CORBA::Object_ptr may be type defined differently in
different C++ ORB implementations, and therefore, is supposed to not
be explicitly referred in user codes).

> Besides, as pointed out in the
> previous discussion:
>

> http://groups.google.com/group/pococapsule/browse_thread/thread/9986e...

[Paul C]

Thank you for the reply. I saw env-var in the docs but wasn't sure if
it can be used from property files. Pococapsule has got my attention
and look forward to testing it out.

> http://groups.google.com/group/pococapsule/browse_thread/thread/9986e...

[Paul C]

Spring are PocoCapsule are different animals if you will, but Spring
does allow method invocation in addition to factory method invocations
instead of constructors. Spring also has some nice AOP proxy
capabilities allowing pre and post method invocations. In the late
90's before IoC and other buzz words were flying around, I would use
Java wrapper classes to control C++ objects and pointers though macros
that generated metadata so I could use IoC and reflection from XML.
Nothing as elegant as PocoCapsule but it did allow managing/invoking
arbitrary native pointers with a java wrapper instances so the jvm did
the reference counting and rudimentry lifecycle control.

[Ke Jin]

On Aug 23, 2:26 pm, Paul C <pkci...@gmail.com> wrote:
> Thank you for the reply. I saw env-var in the docs but wasn't sure if
> it can be used from property files.

1. env-var is based on a pure C++ mechanism, it doesn't need and
intentionally avoid Java or XML facilities.
2. PocoCapsule tries to provides mechanism and avoids specific
policies. The env-var allows one to substitute named configuration
parameters in XML documents with values of same names specified as
name-value pairs. These name-value pairs can originated from files,
user programs, databased, network messages, etc.. rather than have to
be the java specific property files, which is isn't common in C++
world. Even if one wants to use java property files, it should be
straightforward for any program to write code that retrives name-value
pairs from such property files and pass them to PocoCapsule (see the
setvalue() and setArray() methods in pococapsule user guide).

[Ke Jin]

On Aug 23, 3:07 pm, Paul C <pkci...@gmail.com> wrote:

> Spring are PocoCapsule are different animals if you will, but Spring
> does allow method invocation in addition to factory method invocations
> instead of constructors.

factories are different from post-instantation method. First, spring
factory mandates a return referene, while post instantiation methods
do not necessary have return values. Second, a bean many have multiple
post-instantation methods to be called one-after-another. This is not
supported using factory methods.

> Spring also has some nice AOP proxy
> capabilities allowing pre and post method invocations.

AOP in spring only supports Java class. I don't see how to this
support could cover C++ classes through JNI wrappers?

> In the late
> 90's before IoC and other buzz words were flying around, I would use
> Java wrapper classes to control C++ objects and pointers though macros
> that generated metadata so I could use IoC and reflection from XML.
> Nothing as elegant as PocoCapsule but it did allow managing/invoking
> arbitrary native pointers with a java wrapper instances so the jvm did
> the reference counting and rudimentry lifecycle control.
>

Again, I don't see how JVM reference counting pluses JNI wrappers
could solve the lifecycle control issue of plain-old C++ objects which
use various arbitrary pointer arthematics. But any way, we can agree
to disagree on these issues. If you do have some good ideas as
straightforward as discribed, I would suggest you elaborate them
through a concrete implementation.

[Paul C]

I'm not sure I disagree but just wanted to note that Spring does
provide ways to do post instantiation (just a little different)... if
its just one method to call, the bean declaration allows "init-method"
which is called after properties are set and does not use a return
value. If more control is needed, the bean can implement
afterPropertiesSet() to call a group of methods but that implies code
changes to support the Spring framework so its not as clean as if it
was done purely from the XML wirings.

What i was getting at with lifecycle management is that as long as
there is one java object managing one native pointer, then whatever
lifecycle management that is possible with a Java object (singleton,
prototype, request, session, and global-session) can also be applied
to that native object or function pointer. The drawback is that it
turns the application upside down in that its a java application where
POCO instances are in native libraries (similar to AWT
implementations).

> > > > > > Ke- Hide quoted text -
>
> - Show quoted text -

[Ke Jin]

On Aug 24, 5:51 am, Paul C <pkci...@gmail.com> wrote:
> I'm not sure I disagree but just wanted to note that Spring does
> provide ways to do post instantiation (just a little different)... if
> its just one method to call, the bean declaration allows "init-method"
> which is called after properties are set and does not use a return
> value.  If more control is needed, the bean can implement
> afterPropertiesSet() to call a group of methods but that implies code
> changes to support the Spring framework so its not as clean as if it
> was done purely from the XML wirings.
>

PocoCapsule supports post-instantiation invocations (which is much
common in C++ applications than single parameter setter injection)
without requiring user to rewrite their POCO bean implementations.

> What i was getting at with lifecycle management is that as long as
> there is one java object managing one native pointer, then whatever
> lifecycle management that is possible with a Java object (singleton,
> prototype, request, session, and global-session) can also be applied
> to that native object or function pointer.  The drawback is that it
> turns the application upside down in that its a java application where
> POCO instances are in native libraries (similar to AWT
> implementations).
>

More than this, how these JNI wrappers release the wrapped POCO
objects? Using "delete" regardlessly?

Ke