- #Apache common jar update#
- #Apache common jar upgrade#
- #Apache common jar software#
- #Apache common jar code#
During that I found one of the previous developers have purposefully changed the commons-collections from the original given by CF to the custom one with with JUNG works properly. It did not and even if it did (assuming), it was noway related to my problem.Īfter reading the comments from and I have checked through the previous installations and compared the lib changes. Its a misunderstanding by me that Adobe has changed the commons-collections.jar in its WEB-INF/lib when it made CF10. So, may be, changing the JAR in the WEB-INF/lib does not make any difference.Īnswers to this Q would help to my understanding of CF more as well as solve the problem.
But, I worry that there may be areas in CF that depends on this JAR and might break.Ĭfusion\lib : I have found that the commons-collections-3.2.1 already exists in the main lib (cfusion\lib) folder. Everything seems fine as I have not encountered any problems. Testing : For not effecting the rest of applications, I have created a separate instance, changed the JAR to the latest 3.2.1, hosted my application on it and done some testing. Why does CF uses this outdated 2.1 (i feel so) JAR version ?.What could be the parts of core CF that uses this JAR ?.What would be the problem if I change(update) the 2.1 with 3.2.1?.I want to take it as last option and better avoid it if at all possible.
#Apache common jar code#
I can change my code base to suit the default commons-collections-2.1.jar, but that would result in atleast 2-3 months of dev-test cycle.
#Apache common jar update#
If I update the JAR to the latest commons-collections-3.2.1 version, the code works fine as it found all those classes needed. On debug and checking the methods in the commons-collections-2.1.jar given in CF 10, I found that its different from the one present in CF 7. We are in plan to move from CF7 to CF10, so, I'm doing a pilot testing on all the code in the project and found that certain code (that uses the JUNG) are failing with a 'class not found' exception. Note that, Certain classes of JUNG depend on Apache commons-collections.jar which is also present in the same folder (given by default by CF). My custom java code and the Jung libraries are all placed under the wwwroot/WEB-INF/lib.
#Apache common jar upgrade#
All users of Commons HttpClient 3.x are strongly encouraged to upgrade to HttpClient 4.1.I'm working on a project where we use JUNG libraries. Commons HttpClient (legacy)Ĭommons HttpClient 3.x codeline is at the end of life. Users of Commons HttpClient are strongly encouraged to upgrade. HttpComponents Client is a successor of and replacement for Commons HttpClient 3.x. It also provides reusable components for client-side authentication, HTTP state management, and HTTP connection management.
HttpClient is a HTTP/1.1 compliant HTTP agent implementation based on HttpCore. HttpCore supports two I/O models: blocking I/O model based on the classic Java I/O and non-blocking, event driven I/O model based on Java NIO. HttpCore is a set of low level HTTP transport components that can be used to build custom client and server side HTTP services with a minimal footprint. HttpComponents Structure HttpComponents Core Web services, network-enabled appliances and the growth of network computing continue to expand the role of the HTTP protocol beyond user-driven web browsers, while increasing the number of applications that require HTTP support.ĭesigned for extension while providing robust support for the base HTTP protocol, the HttpComponents may be of interest to anyone building HTTP-aware client and server applications such as web browsers, web spiders, HTTP proxies, web service transport libraries, or systems that leverage or extend the HTTP protocol for distributed communication. The Hyper-Text Transfer Protocol (HTTP) is perhaps the most significant protocol used on the Internet today.
#Apache common jar software#
This project functions under the Apache Software Foundation ( ), and is part of a larger community of developers and users. The Apache HttpComponents project is responsible for creating and maintaining a toolset of low level Java components focused on HTTP and associated protocols.