connectors/jk/native2/CHANGES.html - tomcat55 - Git at Google

 <h3>Changes in Jk2</h2>

 </h4>User visible</h4>

 <ul>
 <li>Logging. Jk2 will use the 'native' logging mechanism, wherever is available.
 For example in apache the logs will go to apache's error.log. If a 'native'
 implementation is not available jk will use the old mod_jk.log.

 <li>Apache(2) configuration
   <ul>
     <li><b>"JkSet name value"</b> can be used to specify the same options as in
 workers.properties. The admin can choose to use only apache's httpd.conf, without
 any external file.</li>
     <li>(not completed) <b>"JkWorker worker"</b> directive can be used in a Location
 context to specify a webapp. This is particularly usefull for sites with many
 virtual hosts / webapps where the Location-based and native vhost  mapping is more
 efficient.</li>
     <li>
   </ul>

 <li>JNI worker. Most options on the jni worker are now optional, jk can detect
 and set them automcatically. This reduce the effort needed to configure jni.
 It is _required_ that LD_LIBRARY_PATH or equivalent is set coreclty, otherwise
 java will not start and apache will crash. ( on windows this may not be needed ).
 The user must set either as environment variables or in httpd.conf ( using JkSet )
 or in workers.properties: JAVA_HOME, TOMCAT_HOME ( or CATALINA_HOME ). Jk must
 be installed in the standard location ( modules/ or webapps/. The output from
 the vm will go in apache's error.log ( like all other jk output ) unless
 a special file is requested.

 </ul>

 <h4>Developer specific</h4>

 <ul>
 <li>Created an 'object' registry. All jk components will follow a common pattern
 for creation, and developers will be able to 'plug' their own
 implementation and override the defaults.

 <li>Memory manangement. Use pools more extensively, almost all mallocs have been
 replaced.

 <li>Native pools. The pool is based on virtual functions and may use the native
 server mechanism. For Apache2 ( and as a default for servers not having a pool )
 we can use APR ( or the original jk_pool if APR is not available for a server ).

 <li>Native maps and apr based impl. jk2 maps now use virtual methods that allow
 server-specific implementation. That avoids copying the headers and attributes
 ( and lazy access ). The apr based impl will be the default to be used for servers
 not providing a native map. ( we still use jk_map for object storage, as apr_table
 can be used only for string values )

 <li>Native loggers. Jk2 logger uses virtual methods and may use the 'native'
 server-specific logging mechanism. The original file logger can be used
 for servers not providing a logger ( or until a specific logger is implemented ).

 <li>Reorganised and simplified data structures. Now most usefull information about
 workers is exposed in the core interfaces.

 <li>Pool reuse. In normal operation jk2 will operate in constant memory, the
 endpoint pool will be reset and will not require a malloc per request. ( same is
 true for apache2 request processing )

 <li>Method signatures. Jk2 uses the same 'patterns' as jni, with a jk_env as
 first parameter, then 'this' (the pointer to the object ), then regular parameters.
 The same pattern is used no consistently in all methods.

 <li>JNI has been refactored. On file, jk_vmutil deals with the creation of the
 vm and guessing of all properties needed to create a java vm. It could be possible
 to create specialized instances of jk_vmutil for different vms ( the default
 works for most ).

 <li>JNI now uses the channel abstraction to send/receive messages. In future we
 could refine this to use a special 'marshalling' that will map 'messages' into
 method invocations. One big benefit is that we can now reuse all objects, no
 longer need to use strings ( and thus enable the solving of most i18n problems ).
 The code is also more 'uniform' and easier to extend.

 <li>JNI worker is no longer singleton and can be used to start multiple java
 programms in the same process. Probably not very usefull for jk in particular,
 but the restriction was not needed.

 <li>(not completed) Error handling. The env parameter will provide a mechanism to
 pass error information up the stack ( eventually a stack trace ). It'll also
 provide per/thread storage and a temp pool.

 </ul>

 <h4>Features</h4>

 <h4>Bug fixes</h4>

 <ul>
 <li>Initial fixed for thread safety issue in uriMap ( when rewriting is needed )

 </ul>
	<h3>Changes in Jk2</h2>

	</h4>User visible</h4>

	<ul>
	<li>Logging. Jk2 will use the 'native' logging mechanism, wherever is available.
	For example in apache the logs will go to apache's error.log. If a 'native'
	implementation is not available jk will use the old mod_jk.log.

	<li>Apache(2) configuration
	<ul>
	<li><b>"JkSet name value"</b> can be used to specify the same options as in
	workers.properties. The admin can choose to use only apache's httpd.conf, without
	any external file.</li>
	<li>(not completed) <b>"JkWorker worker"</b> directive can be used in a Location
	context to specify a webapp. This is particularly usefull for sites with many
	virtual hosts / webapps where the Location-based and native vhost mapping is more
	efficient.</li>
	<li>
	</ul>

	<li>JNI worker. Most options on the jni worker are now optional, jk can detect
	and set them automcatically. This reduce the effort needed to configure jni.
	It is _required_ that LD_LIBRARY_PATH or equivalent is set coreclty, otherwise
	java will not start and apache will crash. ( on windows this may not be needed ).
	The user must set either as environment variables or in httpd.conf ( using JkSet )
	or in workers.properties: JAVA_HOME, TOMCAT_HOME ( or CATALINA_HOME ). Jk must
	be installed in the standard location ( modules/ or webapps/. The output from
	the vm will go in apache's error.log ( like all other jk output ) unless
	a special file is requested.

	</ul>

	<h4>Developer specific</h4>

	<ul>
	<li>Created an 'object' registry. All jk components will follow a common pattern
	for creation, and developers will be able to 'plug' their own
	implementation and override the defaults.

	<li>Memory manangement. Use pools more extensively, almost all mallocs have been
	replaced.

	<li>Native pools. The pool is based on virtual functions and may use the native
	server mechanism. For Apache2 ( and as a default for servers not having a pool )
	we can use APR ( or the original jk_pool if APR is not available for a server ).

	<li>Native maps and apr based impl. jk2 maps now use virtual methods that allow
	server-specific implementation. That avoids copying the headers and attributes
	( and lazy access ). The apr based impl will be the default to be used for servers
	not providing a native map. ( we still use jk_map for object storage, as apr_table
	can be used only for string values )

	<li>Native loggers. Jk2 logger uses virtual methods and may use the 'native'
	server-specific logging mechanism. The original file logger can be used
	for servers not providing a logger ( or until a specific logger is implemented ).

	<li>Reorganised and simplified data structures. Now most usefull information about
	workers is exposed in the core interfaces.

	<li>Pool reuse. In normal operation jk2 will operate in constant memory, the
	endpoint pool will be reset and will not require a malloc per request. ( same is
	true for apache2 request processing )

	<li>Method signatures. Jk2 uses the same 'patterns' as jni, with a jk_env as
	first parameter, then 'this' (the pointer to the object ), then regular parameters.
	The same pattern is used no consistently in all methods.

	<li>JNI has been refactored. On file, jk_vmutil deals with the creation of the
	vm and guessing of all properties needed to create a java vm. It could be possible
	to create specialized instances of jk_vmutil for different vms ( the default
	works for most ).

	<li>JNI now uses the channel abstraction to send/receive messages. In future we
	could refine this to use a special 'marshalling' that will map 'messages' into
	method invocations. One big benefit is that we can now reuse all objects, no
	longer need to use strings ( and thus enable the solving of most i18n problems ).
	The code is also more 'uniform' and easier to extend.

	<li>JNI worker is no longer singleton and can be used to start multiple java
	programms in the same process. Probably not very usefull for jk in particular,
	but the restriction was not needed.

	<li>(not completed) Error handling. The env parameter will provide a mechanism to
	pass error information up the stack ( eventually a stack trace ). It'll also
	provide per/thread storage and a temp pool.

	</ul>

	<h4>Features</h4>

	<h4>Bug fixes</h4>

	<ul>
	<li>Initial fixed for thread safety issue in uriMap ( when rewriting is needed )

	</ul>