JTransit Documentation: Frequently-Asked Questions (FAQ)
We have tried to make JTransit licensing simple and based on familiar industry standards. If you have additional questions not answered by this FAQ, please contact us at sales@jtransit.com.
Contents
How does JTransit work?
You compile your web applications using the JTransit compiler to generate pure Java source files (.java files), which are then compiled into bytecode (.class files). This bytecode is then executed in a J2EE compliant application server, and references a common set of predefined java classes (the JTransit Runtime Library) that encapsulate some of the functionality that cannot be converted to Java code without massive code repetition. Some examples of this include dynamic meta tags, dynamic expression evaluation (where you are generating the expression terms dynamically) and some database abstraction.
Do I need to buy the JTransit Compiler?
For optimum performance we recommend everyone purchase the compiler. However if your application consists solely of meta language files (TML, CFML, VTL/VM, JS, etc.) the JTransit Runtime Library is capable of interpreting them at runtime without being compiled. Note that this does not include application files such as .taf and .tcf files, nor does it include custom tags - if you need any of those features you must compile those source files first. If you do not wish to purchase the compiler, JTransit or one of our "service center" partners (to be announced at a later date) may provide services to convert your code for you on a service contract. You must still purchase necessary licenses for the JTransit Runtime Library.
What does a JTransit Runtime Library license allow?
The JTransit runtime license is priced on a CPU (processor) basis. If you are running your server on a dual processor machine, you will need a two-CPU license. If you run your server cluster across four single CPU machines, you will need a four-CPU license.
Can I host multiple domains from the same machine?
You may host as many domains as you feel can be handled by the capacity of the server or its processors. When your website demand increases, you can add additional CPU licenses to ensure adequate scalability. Note that previous to June 2001, JTransit did restrict domain pricing but we eliminated this condition from the pricing model.
We have more than one webserver serving our domain(s); what do we need?
You must purchase a license per CPU (processor) in the machine(s) on which you are running JTransit.
JTransit comes with a developer seat that can be run on the server; does that mean all development and testing has to take place on the server?
No. A developer seat license allows runtime access only to localhost or 127.0.0.1. You can develop and test on as many machines as you have developer seats for, but will only be able to access the application server running on the same machine.
Should the compiler be run on the server?
No. Instead, run the compiler on your machine (hence the extra licenses), then upload your compiled code and test it on the server. You may also set up the server locally on your machine.
Do I need a separate license to develop on another machine?
You can use a multiple-seat license key to develop on as many machines as the license allows. For example, if you have a five-seat developer license, you can use that license key on five machines simultaneously. If you need additional seats, licenses can be added cumulatively.
Do I need to purchase JTransit separately for a development machine and a production server?
No. The compiler comes with a development license allowing you to run your tests as localhost or 127.0.0.1.
Can I run JTransit on an NT Server using Tomcat?
Yes. But start with Orion, since it's pre-setup on install.
Can I put all-HTML code into separate templates then include those? How about nested includes?
Yes, and yes.
Can I have MS SQL Server as the database and use stored procedures?
Yes.
I use only DirectDBMS actions in Tango. Is that OK?
Yes.
Does JTransit behave just like my old, proprietary app server?
Yes. JTransit behaves the same, but our tests show it to be more responsive, reliable and scalable. There may be some differences due to bugs in your old application server which are not present in JTransit.
Typically, your application files (.taf, .cfml, .vm, etc.):
- accept an HTTP-request;
- post another HTTP-request;
- process the templates with nested includes;
- fetch data from the database using stored procedures;
- and use variables that are assigned earlier in the same file.
The source file consists of a string of objects like this; if you run a source (.taf, .cfml, .vm, etc.) file through the JTransit Compiler, the resulting program be able to perform all the magic described above, and produce a dynamic web-page just like your old proprietary application server.
Will templates (i.e included files) be included in the compiled package?
If you wish. They can be processed at runtime, just like you're used to, but your application will run faster if you can compile the templates with the rest of your source code when running the compiler. The choice is up to you.
If I make graphical changes to the templates, will the changes be visible without recompiling?
Yes. JTransit checks to see if a template (include) file exists on disk in the correct location, and will use the version from under the webroot if it exists. Otherwise JTransit uses the compiled version of the template. This allows you to make changes to templates even after they have been compiled without restarting the application server. At the earliest opportunity, you should recompile the changed templates for optimal performance, and delete them from under the webroot (so JTransit will start using the compiled versions instead).
Is the Runtime Library always required on the server?
Yes. The servlets generated by the compiler rely on the JTransit classes to execute, and runtime meta language interpretation is not possible without the JTransit Runtime Library.
Can I run the programs on a Tomcat server without the Runtime Library?
No. The servlets generated by the compiler rely on the JTransit classes to execute, and runtime meta language interpretation is not possible without the JTransit Runtime Library.
What platforms and servers are supported?
All J2EE application servers should be supported, and we have reason to believe (either through customer testimony or our own testing) that JTransit will work at the very least with the following application server environments. Note that operating system and hardware are irrelevant because JTransit is 100% pure Java code. JTransit is currently being run on Linux, Solaris, Windows and Mac OS X servers, to name a few.
Platforms we support include (but are not limited in any way to):
- WebSphere
- WebLogic
- JRun
- Tomcat
- Orion
- JBoss
- Enhydra
- iPlanet
What sort of adaptation is needed?
You should not have to do any adaptation to convert your applications to use JTransit. You just have to be familiar with the application server you wish to use, how to set it up and run it. It really is that simple (for most applications). Sometimes JTransit (usually at compile-time) will uncover bugs in your application that you didn't know existed simply because of the way JTransit scours your entire application for syntax errors and other mistakes. These are typically very easy to clean up. Simply evaluating JTransit has helped many people discover lurking defects and made the process more than worth the small effort.
Is it possible to program a set of core components that will run without modification on any of the aforementioned platforms?
Yes. Once you have compiled them, the rest is a simple matter of where you run your applications.
What are the types of components needed to deploy a JTransit solution?
A J2EE-compliant application server, your converted source files (now .class files), and the JTransit runtime library. That's it.
The product seems really interesting. Does it actually work?
It works. Otto Club and CoCo Kids are some examples. List members can vouch for how well JTransit works. And, of course, you can always download the demo and find out for yourself. The only caveat is that you'll need to make sure you're running clean code, although the JTransit Compiler will let you know if there is something wrong before you even upload a file to your app server.
When using JNDI is it still necessary to define the DSN in the jtransit.xml with the database-connection element, or is setting JNDI-switch to true enough so long as the DSN is defined correctly in Orion's data-sources.xml file?
You don't need a database-connection node at all in your jtransit.xml file when setting jndiSwitch to true.
|
