| Summary: | Converting a repository id to a class name can take a long time | ||
|---|---|---|---|
| Product: | JacORB | Reporter: | Phil Mesnier <mesnierp> |
| Component: | Interface Repository | Assignee: | Mailinglist to track bugs <jacorb-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | jacorb |
| Priority: | P5 | ||
| Version: | 3.3 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Attachments: | The fix | ||
Modified patch applied after discussion. |
Created attachment 425 [details] The fix There is a very old utility function, RepositoryID.ir2scope() that takes a string of the form "mod1/mod2/mod3/intf/MyExcept" and returns a fully qualified class name string: "mod1.mod2.mod3.intfPackage.MyExcept" The way it determines that "intf" needs to become "intfPackage" is by using the class loader to first try to load "mod1" then "mod1.mod2" etc. If the class path the loader searches is large, this iteration can take a long time, perhaps seconds. Also, it happens every time the repoID is used, so repeated use, such as from a request interceptor, can incur substantial overhead. My solution is to first use a map to store successful conversions. I'm using a concurrentHashMap, which may impose synchronization, but that is better than always hitting the class loader. Second, the class loader is still used, but now no more than twice. Once to try the FQ class name resulting from a simple '/'->'.' conversion, and if that fails, insert "Package" before the last dot and try again. If that still fails, the "Package" is abandoned and the name is returned. This preserves the semantics of the call. I have not been able to construct an IDL file that will generate a "Package" within a "Package". If that can be demonstrated, please attach a test and I will modify my code to continue adding "Package" names as necessary.