aspose file tools*
The moose likes Tomcat and the fly likes import statement changes from one version of web container to another Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "import statement changes from one version of web container to another" Watch "import statement changes from one version of web container to another" New topic
Author

import statement changes from one version of web container to another

Angus Comber
Ranch Hand

Joined: Jul 16, 2011
Posts: 90
I am running Tomcat 7 on my development machine and my customer is running Tomcat v6.

I need to use some Tomcat specific classes so I compile using catalina.jar.

On my Tomcat 7 installation I use
import org.apache.catalina.comet.CometEvent;

But I have seen Tomcat 6 samples and they use:
import org.apache.catalina.CometEvent;

Is it possible that package path (is that right term to use) could be different between versions of Tomcat?

If so, will this present any problems on customer site?

I assume not because source is already 'compiled' but just wanted to check.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

Comet support is integrated into Tomcat7. It is not part of Tomcat 6, and it is very likely that these 2 different Comet implementations are significantly different, so it's more than just the package path that you need to worry about.

A similar state existed in regard to EL, which was integrated into Tomcat 6, but not Tomcat 5.

One thing, however. As a rule, you should not compile with Tomcat-specific (internal) JARs. You'll notice that there's a servlet-api.jar and a jsp-api.jar. Those JARs contain the non-specific classes/interfaces (the ones defined in the J2EE and JEE standards).


Customer surveys are for companies who didn't pay proper attention to begin with.
Angus Comber
Ranch Hand

Joined: Jul 16, 2011
Posts: 90
Tim Holloway wrote:Comet support is integrated into Tomcat7. It is not part of Tomcat 6, and it is very likely that these 2 different Comet implementations are significantly different, so it's more than just the package path that you need to worry about.

A similar state existed in regard to EL, which was integrated into Tomcat 6, but not Tomcat 5.

One thing, however. As a rule, you should not compile with Tomcat-specific (internal) JARs. You'll notice that there's a servlet-api.jar and a jsp-api.jar. Those JARs contain the non-specific classes/interfaces (the ones defined in the J2EE and JEE standards).


I don't understand your comment about NOT compiling with Tomcat-specific internal JARs. How else can the Tomcat specific functionality be accessed?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

As a general rule, you shouldn't be attempting to access server internal components from applications, and especially in Tomcat. Not only does this tie the app to a particular brand of server, it ties you to a specific version of the server. There's nothing more annoying than doing a system upgrade and having the apps all break in esoteric ways.

COMET is a web service standard, so it's doubly-important not to use implementation-specific libraries. There should be a server-independent API library floating around somewhere.
Angus Comber
Ranch Hand

Joined: Jul 16, 2011
Posts: 90
Tim Holloway wrote:As a general rule, you shouldn't be attempting to access server internal components from applications, and especially in Tomcat. Not only does this tie the app to a particular brand of server, it ties you to a specific version of the server. There's nothing more annoying than doing a system upgrade and having the apps all break in esoteric ways.

COMET is a web service standard, so it's doubly-important not to use implementation-specific libraries. There should be a server-independent API library floating around somewhere.


Hello, I am trying to understand what you are saying because I agree with what you are saying and what my solution to be as universally applicable as possible. But if Tomcat implement Comet one way, Jetty, another, someone else another way then what do I do? Are you suggesting I should make my OWN Comet implementation, create a JAR file and use that?

Is there an implementation of Comet which works in ALL web containers?

My initial plan is to make this available for Tomcat 6+.

Because Comet makes use of Java NIO (and indeed you have to make changes to the Connector server option in server.xml) it is quite a big change so not sure how easy it is to make the Comet model non-container specific.

I am a bit confused as to what the right way forward might be?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

Actually, I think you're right. I haven't been paying close attention. Apparently there ISN'T yet a standard COMET API.

There is a project named "Atmosphere" at github.com that claims to provide COMET as an Inversion-of-Control (IoC) mechanism in a server-independent way. You'd probably have to have customizable builds, however so that it could reference the appropriate backend COMET classes.
Angus Comber
Ranch Hand

Joined: Jul 16, 2011
Posts: 90
Tim Holloway wrote:Actually, I think you're right. I haven't been paying close attention. Apparently there ISN'T yet a standard COMET API.

There is a project named "Atmosphere" at github.com that claims to provide COMET as an Inversion-of-Control (IoC) mechanism in a server-independent way. You'd probably have to have customizable builds, however so that it could reference the appropriate backend COMET classes.


OK, I was wondering if I had missed something. Yes maybe a container/platform independent implementation will come in time.

I had a look at Tomcat v6 and v7 Comet and they look the same. ie I don't think v7 made any changes to CometProcessor, CometEvent, etc.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16014
    
  20

There's one critical difference between the two different versions of Comet - their package names. And, since the package name is actually part of the fully-qualified classname within the classfile itself, you can't just move files around for binary compatibility. Knowing Tomcat, there's probably also a class version problem that will pop out at you if you try and mix and match Tomcat6 and Tomcat6 classes.

I'd go with the Atmosphere abstraction kit myself.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: import statement changes from one version of web container to another