Custom tags in CF9

[nosredna]

I have over 200 custom java tags.  In our CF7 environment I manually registered the 200+ tags; and then I copied the neo-runtime.xml file to 2 other CF7 server installations.  We are now looking at upgrading to CF9.  I have installed the development version and want to know if there is a way I can get my custom tags recognized without having to manually register each one of them.  I tried copying the neo-runtime.xml file but that didn't work so I restored the original neo-runtime.xml.  And now, for some unexplainable reason, some of my custom tags are working even though they are not registered anywhere; and others are not working.  Not sure what is happening.  Obviously, CF9 handles custom tags differently but I can't find any documentation on this.  Can anyone explain or assist.

Thanks.

[Guest]

If you are using CF enterprise license , in CF administrator, there is a option of building CAR file. You can use this to migrate your CFX tag from CF 7 to 9.

If you using CF standard, then make it in developer edition and then this option will come in CF admin

[nosredna]

In some of the research I've done it has been suggested that a CAR file is good if you are going from one server to another using the same version of CF; but if you are going from one version of CF to another, then it is not a great idea.

Can anyone else confirm that a CAR file will work when going from CF7 to CF9?

Thanks...

[Charlie Arehart]

Nosredna, here's a possible explanation why some work for you and some do not. When "registering" the java CFXs, have you noticed that you don't specify their location? That's because they're expected to be found in places that CF can find them, as defined by the classpath configured for CF, which includes a couple of default locations: in the WEB-INF/classes directory if .class files, or in the WEB-INF/lib for .jar files.

Also, you can tell CF to find them in other locations, by modifying the classpath, either in the CF Admin (Java and JVM page) or in the jvm.config.

I wonder if the ones that are working for you are found in the default locations, and the ones that are not are in locations that either weren't brought forward and specified in the classpath for your upgraded server, or perhaps the paths are there but not correct (if this is a new server).

Much of this is discussed in the CF docs, such as a series of pages starting here:

for CF8: http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=CFXTags_4.html.

for CF9 (same text): http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WSc3ff6d0ea77859461172e0811cbec0a4b8-7ffb.html

You say that "Obviously, CF9 handles custom tags differently but I can't find any documentation on this". I'm really not aware of any changes in this regard, since CF 6.

As for not finding any docs, if you mean about a change in CF9, well, there isn't any as far as I know, not since CF4.51 when Java CFXs were introduced (though the default locations for classes and lib did change as of CF 6.)

If you may have meant that you could find no docs on registering CFXs at all, well, a common problem is that people tend to focus solely on the CFML Reference. The doc I point to above is in the Developer's Guide. There is also an Admin and Config Guide:

for CF8: http://livedocs.adobe.com/coldfusion/8/htmldocs/Part_2_Config_Admin_1.html

for CF9: http://help.adobe.com/en_US/ColdFusion/9.0/Admin/index.html

Though that really doesn't offer much on CFXs. Instead, it points readers to the online help, which again people often miss. This is referring to the help icon within the CF Admin. And that page (called from the CFX page) does indeed offer information on registering CFXs and these paths in which to place them, or the need to modify the classpath.

Hope that helps.

/charlie arehart

charlie@carehart.org

Providing CF and CFBuilder troubleshooting services

at http://www.carehart.org/consulting

[nosredna]

Charlie:

Thanks for the response. I suspected that CF9 might be "automatically" recognizing my custom tags from my custom .jar file and custom tag path that I had set up in CF Admin. The odd thing is that "all" of my custom tags are defined in my.jar file and, as mentioned, some of them were recognized and some of them were not. It was that inconsistency thatI found to be bizarre. For the ones that were not, I had to manually register them in CF Admin.

I'm wondering if anyone else has had similar experiences that they could relay.

Thanks...

[Charlie Arehart]

That is odd. You're saying that all Java CFXs are in one jar, and that Jar is in the classpath?

Even so, it would seem odd that only some would work without registering. Here's a thought: are some in java packages, and others not? Perhaps that has an effect.

/charlie

[nosredna]

Charlie:

Yes, all of the CFXs are in the same jar file and are generated automatically from a Progress proxygenerator application. These are all custom tags used to access and run apps in a back-end database. The jar file is in the classpath.

...Wes

[Charlie Arehart]

What about the question of packaging I had asked? Could be significant. If you don't quite understand it, just say so and I or others can elaborate.

/charlie

[nosredna]

You're right, I wasn't sure what you meant about packaging; however, I didn't respond on that because you asked if some are packaged and some not. All of the tags are processed (created) in a single process which creates the jar file; so it's not a case of some are and some aren't. They are all Progress programs that perform some function on the database. The process converts Progress compiled r-code to java class files. We have been using them with CF5 and CF7 for about 10 years.

...Wes

[Charlie Arehart]

OK, Wes, but it's not really significant that you've been using them with CF for 10 years. You asked specifically why when you moved from one version to another, some worked and some did not. I was just offering some thoughts (about something that perhaps could explain things if perhaps some aspect of configuration was not brought forth from the one release to another).

Similarly, I don't know that you can hang your hat on the mere fact that they're "all created in a single process which creates the jar". That process could still create them as what Java refers to as packages. Typically, it works out to be not much more than subdirectories within the jar (though technically there is indeed more to it, in that you define the class as being in a package in the java code).

But let's have you do the simplest thing to check on it: a jar file is really nothing more than a zip (compressed) file. If you have any tool that you can use to open zip files (winzip, izarc, whatever), try opening the jar. You can't just double-click it--if you have Java installed, then by doing that the OS will (by default) try to run the jar with Java, which is not what we want.

Try opening the jar with the zip tool (just like you might try to open any zip file). Then, once opened, see if there are any suibdirectories. If so, then see if there are any classes in them. Check out their names. Do they look like the class names for your CFXs? If so, then this could be the issue (that some are in packages, and CF may be picking up those that are not).

I'm just guessing here. I don't work for Adobe, and really there are very few (percent-wise) in the CF community who use Java CFXs, so you may be a little hard-pressed to get too much help for your problem.

One last question: are you just trying to find out if you can avoid registering them? If you did register one that was "not working", does it suddenly work?

And back to your earlier question, about using the CAR file mechanism, no, there would be no problem using it to export the CFX definitions out of one instance of CF and then importing them into another, whether on the same version or on new versions.

I would, however, recommend that you do only export/import that one set of settings and none other (the CAR file mechanism could be told to export/import all CF Admin settings). there's no sense in you risking overwriting anything else when it's not related to the problem.

Hope that helps.

/charlie

[nosredna]

Charlie:

Thanks again for your feedback. I did open the jar file and there are no sub-directories. All of the class files are at the root. With regard to your last question the answer is yes. My original issue was that I did not want to manually register 200+ tags if there was a simpler way of doing it (like copying the neo-runtime.xml file in ver. 7). Any tags that I have discovered which did not work, they did work after I manually registered them. So I know I can manually register them and they will work. My real concern was the odd behaviour of some of them working and some of them not. It does not instill a high level of confidence or comfort when the application (CF9) demonstrates this sort of inconsistent behaviour... and I like to get to the bottom of things so I know what I'm dealing with.

Thanks again for all your help.

...Wes

[Charlie Arehart]

OK, thanks for the clarifications. I can offer no insight on why it acts inconsistently. I tend not to take a pessimistic view (a lack of "confidence or comfort when the application (CF9) demonstrates this sort of inconsistent behavior"). I chalk it up instead to something I just don't understand, rather than asserting something must be "wrong" with CF.

I don't know enough about the details to help beyond this, but perhaps someone someday reading this may chime in with some insight. There simply must be some explanation. No one had proposed the package idea. It was just a guess for me. I expect that there's something just like this, some difference in how some of them "work" and others don't.

If nothing else, though, you (and other readers) now know that if you face this, you can at least automated the re-registering of CFXs using the CAR file mechanism.

(Someone may say, "yeah, but that's only in the Enterprise or Dev edition. Fair enough. But you can easily remove the Standard license key during a brief maintenance window, which drops the server back to Developer, and then create or import the CAR file, before adding the key back.)

Hope that's helpful to someone.

/charlie