July 15, 2006. JProxy version 2.2 has been released.

New Features

Now the settings (properties) for server and for client can be modified during runtime from Web-browser (http://localhost/proxyservlet/properties.jsp). The client requests the properties from the server before its first remote call. There are no needs anymore to modify proxyclient.jar or proxyservlet.war. The changed properties are stored by default in $JAVA_HOME/lib/proxy.properties. But new location can be specified in com.jproxy.proxy.properties.dir Implemented new functionnality restricting remote JProxy Server access or properties access. The list of allowed client hosts can be specified in com.jproxy.proxy.allow.hosts and com.jproxy.proxy.properties.allow.hosts. Changed server-side object recycling implementation. Previous releases where based only on ?Time-to-Live? (TTL) logic. The logic recycled server objects created by the client if the client session did not send update request during specified time. New implementation utilizes stub?s finalize-method that are invoked by client-side GC if the remote stub is not in use anymore. The finalize-method calls are collected by JProxy Client Runtime during TTL/2 time and then the batch with object and session IDs is sent to the server for processing. Server then recycles resources associated with the remote objects. The TTL logic that cleans resources on client session expiration is still necessary because it allows to recycle server resources in case of networking problem or of sudden client shutdown. Implemented JNDI username/password-based authentication for WebSphere. Implemented logic that recycles server resources on EJB remove call. Reduced CPU load caused by JProxy Server by improving thread synchronization. The fix also increased performance especially for high-load cases. Improved asynchronous communication performance. You will get at least 2x (and better) performance boost for JMS. Fixed authentication for Orion 2.0.5 and 2.0.7. Fixed server-side memory leak caused by not cleared entries in session hash. Fixed leak that was caused by non-collected callback listeners (MessageListener for JMS) and all linked to them resources. Fixed JNDI relogin bug. Previous client login retained till client session is active. New settings (properties): com.jproxy.proxy.allow.hosts = * # # Used in = server # Default = localhost # The list of hosts allowed to access JProxy Server # The wildcard "*" can be used at the and of address. # Keyword LAN can be used to allow all hosts on the LAN. # The localhost is always allowed. com.jproxy.proxy.properties.allow.hosts = LAN # # Used in = server # Default = localhost # The list of hosts allowed to access remotely server's properties.jsp # The wildcard "*" can be used at the and of address. # Keyword LAN can be used to allow all hosts on the LAN. # The localhost is always allowed. com.jproxy.proxy.properties.from.server = true # # Used in = client # Default = false # If true then client during its initialization attempts to obtain properties from the server. # If false then it uses properties from local proxy.properties file. com.jproxy.proxy.support.cookie = true # # Used in = client # Default = "false" # If "true" then client will store all server cookies and return it in request. com.jproxy.proxy.cookie.manager.class = com.jproxy.proxy.servlet.CookieManager # # Used in = client # Default = com.jproxy.proxy.servlet.CookieManager # Cookie manager collects all cookies sent by the server and then response it back in any Http Request # Cookies are utilized by some servers with HTTP load balacing.

Fixed some minor bugs.

April 7, 2004. JProxy version 2.1 has been released.

New Features

A new Server-side property com.jproxy.proxy.nonremote.classes Default value - "weblogic." A list of class names. If result of remote call is instance of one of folowing classes then jproxy creates remote stub for it. JProxy Samples have been improved.

Bugs Fixes

Memory leak for asynchronous communication has been fixed. Cause: HttpCallbackServer object could not be collected by GB because its reference was kept by callback caller. Fixed: JProxy 2.1 Thread synchronization issue during asynchronous communication in JProxy Server. The bug appeared during heavy load by JMS message producer. Cause: HttpCallbackServer . "push" and "popAll" calls synchronization. Fixed: JProxy 2.1 NullPointerException in JBoss 3.2.1 for each client request reported by some our customers. Cause: An odd behavior of JBoss returning null from ServletContext.getRealPath(codebase) Fixed: JProxy 2.1 Some minor bug fixes: fixed some message log, removed unecessary code, etc.

March 11, 2004. JProxy version 2.0 has been released.

New Features

SOAP JAX-RPC support. Now you may invoke operations on SOAP services without even SOAP and XML libraries presented on your client. All that you need on your client is JProxy Runtime about 100K! JProxy tested on Apache Axis and IONA Artix. New SOAP JAX-RPC samples available online and in download. CORBA support by JProxy has been redesigned. You can use CORBA main functionality without even CORBA libraries and API presented on your client. New CORBA samples that also available online and in download. A properties can be set in $JAVA_HOME/lib/proxy.properties proxy.properties can be changed without changing repackaging proxyservlet.war and proxyclient.jar. JProxy runtime first reads default properties via Classloader as resource com/jproxy/proxy/proxy.properties. And then attempts to read from $JAVA_HOME/lib/proxy.properties. The properties override default properties. Greatly simplified JProxy settings for bytecode stub generation for Java clients with JRE before 1.3. If client running in applet it sends applet codebase to JProxy Server. And JProxy Server in its turn calculates path in local file system for deployed war-file with matched codebase. Then JProxy Server uses the path to place generated bytecode stubs that lately can be downloaded by client’s applet Classloader. As result properties com.jproxy.proxy.lib.class.path and com.jproxy.proxy.stubgen.class.path have been removed. You also can explicitly map web codebase to path in local file system via new property: com.jproxy.proxy.stubgen.codebase.path.mapping All remote class libraries necessary to generate stubs (dynamic and bytecode) now can be located outside of ear-file that contains proxyservlet.war. They even can be accessible remotely by URL. The list of class libraries can be set in server property com.jproxy.proxy.server.class.path Besides MSEI and Netscape Navigator JProxy has been tested on Opera Web Browser and Linux Konqueror. JProxy Client can be executed in default sandbox security model for all supported J2EE APIs: EJB, CORBA, RMI, SOAP. But there is an issue with Linux KDE Konqueror Web Browser. The does not support a standard way of obtaining InitialContext (new InitialContext(…)) because of wrong definition of Java sandbox security. For the browser "getClassLoader" permission is not allowed for sand-box. For Konqueror support in sandbox security model line: Context context = new InitialContext(env); Has to be replaced to code below: javax.naming.spi.InitialContextFactory factory = new com.jproxy.proxy.NamingContextFactory(); Context context = factory.getInitialContext(env); A new Server-side property com.jproxy.proxy.server.class.path Default value - "" A classpath for JProxy Server used for compiling dynamic and bytecode stubs In the property you may enumerate necessary libraries separated by semi-colon. Wildcard *.jar or *.zip can be used. A path can be any valid URL: http://localhost/bluh/bluh/lib.jar;/opt/lib/*.jar;/usr/lib/; All paths that ends with file-separator (/) is assumed to reffer to a directory. The parameter does not have to be set for dynamic stubs if all necessary libraries are accessible from classloader of servlet engine. For instance if proxyservlet.war is deploed as part of ear-file that contains libraries. In order to compile bytecode stubs proxyclient.jar must be accessible. The parameter must be used to enable JProxy Client for web browsers that do not have Sun Java Plug-in 1.3 installed such as MS Internet Explorer that have Microsoft JVM. This property is introduced in the property file com/jproxy/proxy/proxy.properties A new Client-side property com.jproxy.proxy.stubgen.codebase.path.mapping Default value - "" The property is used to specify generated bytecode stubs location (on local fyle system) for each web-context. Usually JProxy Server automatically finds containers's mappings of web-contexts to real path on local file system. Use the property if you want to override the behavior. The format of mapping: context1>path1, context2>path2, ... A new Server-side property com.jproxy.proxy.soap.init.arguments Default value - "" IONA Artix space-separated arguments used for com.iona.jbus.Bus.init(String[] args) call. A new Client-side property com.jproxy.proxy.soap.url.from.wsdl Default value - false If set to "true" JProxy Client gets "real" service port binding URL by parsing WSDL. URL for WSDL is passed as parameter in ServiceFactory.createService(URL wsdlUrl, QName serviceName). If set to "false" JProxy Client gets service port binding from URL used by JProxy tunneling. A Message logging has been improved. Expanded Performance Test Sample. New test cases SOAP, CORBA and RMI has been added. The test can be used as main JProxy test for SOAP, CORBA, EJB and RMI testing. The sample includes test of Callbacks for all test cases.

Bugs Fixes

January 23, 2004. JProxy version 1.4.0 has been released.

New Features

New Highly improved Client Callback Support Now ANY client-side class may be called by the Server. The class just must implementing either java.rmi.Remote or ANY User interface. The callback is passed as argument in remote call. Almost any J2EE technology (even non-callback aware) can pass client object reference to the server. The new feature allows very easy runtime creation of client-side remote objects. And no extra security necessary! A new Client-side property com.jproxy.proxy.callback.classes Default value - java.rmi.Remote,javax.jms.MessageListener,org.omg.CORBA.Object The property specifies a list of classes (interfaces). The Callback Object could be ANY object that is instance of the class implementing either interface from the list. The list of interfaces can be customized by changing the property. The Callback can be set by passing in remote call the Object as an argument. ANY number of arguments can be used. Check Performance example for practice of setting up callback. This property is introduced in the property file com/jproxy/proxy/proxy.properties Thread-based Session support Client now generates unique session ID based on thread where remote call is performed. Server updates remote object or reference license based on session ID. One object can be shared by several sessions. Now Object Licenses can be updated automatically by background thread. The thread generates object update request for all objects of all client sessions that not been updated longer then Object Time-To-Live / 2. A new Client-side property com.jproxy.proxy.timeout.update.enabled Default value - "false" If "true" then a thread starts on the client. The thread polls the server for resetting timeout of remote objects used by client. The polling period is: com.jproxy.proxy.object.ttl / 2 This property is introduced in the property file com/jproxy/proxy/proxy.properties A Message logging has been improved. Improved Performance Test Sample. The test can be used as main JProxy test. It will be extended to present more test cases for different J2EE APIs. The sample includes test of Callbacks. There is also possible to specify number of testing threads for testing racing conditions. All different cases reuse same com.jproxy.samples.interfaces.ITest and com.jproxy.samples.interfaces.ITestCallback interfaces.

Bugs Fixes

Local client spontaneously failed especially with high JProxy server load. Cause: There has been probability of Non-unique Request ID in case when client and server run in same process. Fixed: If the thread is died then it gets recreated during construction of HttpCallbackClient JProxy 1.4 JProxy client could not run on JRE 1.3.1 in JProxy 1.2. Cause: HttpURLConnection.getOutputStream() called after HttpURLConnection.connect() Fixed: JProxy 1.4 Some minor bug fixes: fixed some message log, removed unecessary code, etc.

November 5, 2003. JProxy version 1.2.0 has been released.

New Features

A new Server-side property com.jproxy.proxy.stubgen.stub.reuse.enabled By default when JProxy Server been restarted or redeployed then all previously generated bytecode stub files are ignored. If the property set to "true" - StubGen before generating new stubs tries to utilize stub file from directory specified in property "com.jproxy.proxy.stubgen.class.path". This property is introduced in the property file com/jproxy/proxy/proxy.properties New JProxy proxy classes (Dynamic and Bytecode proxies) do not have any references to any JProxy Server classes accept com.jproxy.proxy.ServerStub. The change illuminates dependencies between client and server caused by generated proxies. Performance improvement for case of accessing JProxy Server by multiple JProxy clients with JRE 1.3 and up. The improvement was made possible by utilizing new com.jproxy.proxy.Hashtable2 class and non-synchronized java.util.HashMap. The Hashtable2 class uses synchronization for modifiers-methods only. Read-methods are executed concurrently.

Bugs Fixes

Two applets utilizing asynchronous communication running under one JRE cannot be executed simultaneously. Also if one such applet starts after another been closed then it also cannot be executed. Cause: An interrupted thread in HttpCallbackClient was a reason of the behavior. Fixed: If the thread is died then it gets recreated during construction of HttpCallbackClient JProxy 1.2.031105 Inconsistently slow server response up to 5 seconds. Cause: TunnelServlet had been using DNS lookup for client IP from the call: request.getRemoteHost(); Fixed: The call request.getRemoteHost() replaced on request.getRemoteAddr() that returns just IP address of client host. JProxy 1.2.031105 An applet running in MS JVM cannot start because ClassNotFoundException during loading JProxy libraries or stubs from AppServer running in JRE 1.4 and up. Cause: Bytecode format had been changed in Sun Java 1.4 Fixed: In order to support MS JVM for JProxy Server running on JRE 1.4.x, all JProxy libraries including j2api.jar had been recompiled with javac option "-target 1.1". Please be aware that if you execute JProxy Server on JRE 1.4.x then JProxy Server property (proxy.properties) must be set to com.jproxy.proxy.compiler.options = -target 1.1 Also all your libraries that are supposed to be used by MS JVM client have to be recompiled with javac option "-target 1.1". JProxy 1.2.031105 In Evaluation release JProxy Client was not able to use Web-Proxy Server authentication for SSL. Cause: Some JSSE does not allow proxy authentication for SSL. Fixed: com.jproxy.proxy.servlet.SSLProxySocketFactory is used now when proxy authentcation for SSL been requested. JProxy 1.2.031105 JProxy 1.1.0 had been closing connection for each HTTP request. The bug was submited on JProxy forum. Thanks. Cause: JProxy 1.1.0 has connection.destroy() call. Fixed: The "connection.destroy()" has been removed. JProxy 1.2.031105 Some minor bug fixes: fixed some message log, removed unecessary code, improved documentation for SSL usage, and other.

February 11, 2003. JProxy version 1.1.0 has been released.

New Features

This is a complete rework of JProxy Tunnel internal machinery that resulted in a number of advantages that this version delivers to the end user. The performance has been drastically improved. JProxy Tunnel 1.1.0 is almost twice (2x) as faster comparing to its predecessor 1.0.5 The client side footprint has been reduced by 15%. It is now only 80 Kbytes. The marshaling mechanism has been redesigned and optimized. As a result one can now have JProxy Tunnel 1.1.0 automatically integrated into applications that operate with remote class hierarchies of EJB, RMI, JMS or CORBA of almost any complexity. No source code change required. JProxy Tunnel server to JMS provider communication mechanism has been optimized, which delivers better performance results for JMS over HTTP tunneling. JProxy Tunnel client side can run in outdated Microsoft JVM. This allows your clients not to have to download Sun Java plug-in.

Bugs Fixes

When JProxy Tunnel was used to tunnel asynchronous JMS notifications on shutdown its client async controller thread was not getting properly terminated, resulting in performance degradation. Some minor bug fixes.

January 20, 2003. JProxy version 1.0.5 maintenance 1 has been released.

New Features

None

Bugs Fixes

Latest Servlet Engine - Tomcat 4.1.12 seems to have a change in its processing of web.xml deployment descriptor. The original <url-pattern> value in web.xml - <url-pattern>/proxyservlet/servlet/proxyservlet/*</url-pattern> is no longer functioning. However, this value <url-patter>servlet/proxyservlet/*</url-pattern> does work. JProxy's deployment package has been updated to accommodate the change in Tomcat's behavior. Please, those who have downloaded JProxy Tunnel prior January 15, 2003 and are experiencing problems with Tomcat 4.1.12, download the latest evaluation version of the software here. If you're our customer you can always get the latest JProxy Tunnel package here.

December 9, 2002. JProxy version 1.0.5 has been released.

New Features

A new Client property com.jproxy.proxy.native.exceptions.enabled has been introduced. The default value is false. If set to true, then all server exceptions are passed to the client side as is. In this case client must have access to the classes of serialized server exceptions. If set to false, then JProxy Server analizes this exception being thrown and acts as follows: If the class of the exception being thrown is the same as declared in the throw clause of an interface's method declaration this exception is passed to the client as is. If the class of the exception being thrown is inherited from a non-standard J2SE/J2EE exception class declared in the throw clause of an interface's method declaration, then this exception is passed to the client as is. If the class of the exception being thrown is inherited from a standard J2SE/J2EE exception class declared in the throw clause of an interface's method declaration, but the thrown exception class by itself is a non-standard J2SE/J2EE exception class, then the standard J2SE/J2EE exception declared in the throw clause of an interface's method declaration is passed to the client. If the class of the exception being thrown nor its parent class is declared in the throw clause of an interface's method declaration then RuntimeException with the thrown exception's message is passed to the client. Standard J2SE/J2EE exceptions are those defined in packages that start with: java, org.omg, org.xml, com.sun, sun and org.w3c This property is introduced in the property file com/jproxy/proxy/proxy.properties

Bugs Fixes

A wrong server URL or IP of the server was returned if JProxy been deployed on private domain (LAN) and accessible with port-forwarding or IP-forwarding during asynchronous communication. Now server URL passed with each request/response. Some minor bug fixes.

October 15, 2002. JProxy version 1.0.4 has been released.

New Features

JProxy communication has been optimized. JProxy Client now automatically makes a decision if data compression is efficient for remote calls based on network performance. A new property com.jproxy.proxy.network.perfromance.threshold (bytes per second) is introduced for the JProxy client side. JProxy Client measures network performance for each call. If detected performance is higher than specified threshold then data compression is disabled. Data compression is enabled otherwise. Server always uses compression if client request uses compression. The property com.jproxy.proxy.compression.enabled is not used any more. The property is introduced in the property file com/jproxy/proxy/proxy.properties The new JProxy has a new Performance Test that allows running multiple client threads.

Bugs Fixes

A wrong algorithm of generation of objectId for new references to remote objects. The objectId was based on current time measured in milliseconds and it is supposed to be unique for each referenced object. There was a possibility when during interval of 1 millisecond more then one same id get created for different objects. For remote client networking delay guarantied different Id. But in case of local client (some test cases) or very heavy load of the server probability of occurrence of the bug got increased.

August 5, 2002. JProxy version 1.0.3 has been released.

New Features

Java Authentication Authorisation Service (JAAS) support, which is a server-side EJB Authentication mechanism. Principal and Credentials from client are still passed as JNDI properties. Note that JAAS is used in JBoss by default. A new property "com.jproxy.proxy.jaas.configuration.name" is introduced for the JProxy server side. This property bears the name of the current JAAS configuration. By default this property equals to "other". In case of JBoss its default value is "client-login" The property is introduced in the configuration file com/jproxy/proxy/proxy.properties A new class com.jproxy.proxy.providers.JaasInvocationInterceptor implemented to support JProxy JAAS integration

Bugs Fixes

No major bugs were reported.

JProxy version 1.0.2 has been released.

New Features

JProxy now supports SSL. JProxy API allows to control the SSL timeout value. A new class is introduced and implemented that enables SSL in JProxy - com.jproxy.proxy.servlet.SSLProxySocketFactory A new property com.jproxy.proxy.use.jproxy.ssl.socket.factory is introduced in com/jproxy/proxy/proxy.properties file. If the value of this property is set to true then SSL support is enabled. If the value is false then SSL support is disabled.

Bugs Fixes

Some bug fixes.

Date. JProxy version 1.0.1 has been released.

New Features

A new request level interceptor com.jproxy.proxy.InvocationInterceptorIt is introduced. This feature allows to the developer to intercept and customize the way requestes are being marshaled A new property com.jproxy.proxy.object.destroy.enabled is introduced for the JProxy's server side configuration file, which could be found in jproxy/proxy/proxy.properties. If the property value is set to true, then JProxy automatically releases remote objects for you. If the property value is set to false, then the remote resources garbage collectionby is left up to the implementor. Note, that in either case the local client resources are always garbage collected by JProxy garbage collector (GC). A new class com.jproxy.proxy.providers.OrionInvocationInterceptor is introduced that allows to intercept Orion remote method invokations. A new property com.jproxy.proxy.tunnel.invocation.interceptor is introduced in com/jproxy/proxy/proxy.properties" Set this property to com.jproxy.proxy.providers.OrionInvocationInterceptor to intercept each remote call in Orion Application Server A new deployment descriptor Weblogic-ejb-jar.xml for TestSessionBean has been included. It allows direct deployment of test application proxy.ear on BEA WebLogic Application Server.

Bugs Fixes

Servlet output stream was closing 2 times.