Ok based on what you're telling me, you should be able to pass the data you want want to send within that authenticated page.<br><br>For the time being though, let's go back to your apache configuration. Is it being used to serve regular content? In your example, you are serving a text file. I know from previous posts, that you have other content being served as well. Is that content that you want tomcat to serve also being served via "normal" apache pages? If not, then just configure mod_jk to serve those content types as well, then there is no more dual-app-server confusion. If not, then things get tricky.
<br><br>If it's down to a pure java solution, then I'm really out of my element. My best suggestion would be to hunt down some examples of this type of thing via google. I will ask some of the Java guys here about it and see if I can get something useful.
<br><br>Normally the admin interface is at the url of your tomcat install /manager/ - of course this has to be enabled in your configuration xml files, but most default installs have it in some form, just check the configs.
<br><br><div><span class="gmail_quote">On 6/27/06, <b class="gmail_sendername"><a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a></b> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The "Admin Interface" of which you speak alludes me. I'm just using<br>plain-jane Tomcat from
<a href="http://tomcat.apache.org">tomcat.apache.org</a>. I am no Java expert by any<br>means, so I think you are speaking of some concepts that I don't<br>understand. There may be a better way to handle logins, but I'm using a
<br>session-level (cookie) Bean. At the top of each of my .jsp pages is a<br>small function which checks the bean to make sure that they have access to<br>the page. If they do, then the page is displayed. If they do not then they
<br>are sent to the login page. With .jsp's this is very easy. I merely<br>"jsp:include" the relevant jsp which checks the login. But now I want to<br>serve up file /Data/Files/9/Batch/abc123.txt . Normally, apache would
<br>handle this request. But I need tomcat to make sure:<br><br>a.) This is client #9. And...<br>b.) This particular user (which belongs to client number 9) has access to<br>this particular file.<br><br>So to do this I need to get to that session level bean. Which I don't know
<br>any other way to do unless I get the request to a servlet or jsp of<br>somekind. And then I don't know how to get back to the file.<br><br><br>When we last left our adventurers...<br><br>> Basically mod_jk, in its simplest form, will take a request bound for port
<br>> 80 and apache and look at the type of data it is requesting. Like .php gets<br>> passed to the php module, or .html gets handled natively by apache,<br>> something like .jsp will simply get forwarded on to Tomcat. Apache isn't
<br>> really doing anything at that point except for acting as a conduit so that<br>> both distinct servers can use port 80 simultaneously, which makes coding<br>> multi-language web apps a little simpler.<br>>
<br>> Tomcat has a pretty extensive administration interface. Basically, when it<br>> gets set up, you do just enough dirty work on Tomcat to get the thing to run<br>> and then configure everything else (permissions, database, settings, etc.)
<br>> via the admin app. It's really though this app that you should be directing<br>> your attention.<br>><br>> Your application should have capability to access the allowed functions of<br>> the environment it's running within, which in this case is Tomcat. That
<br>> includes your permissions and access. You shouldn't have to use explicit<br>> filters and such just to access permission data being passed from the<br>> session and handled by the application server.<br>>
<br>> You may want to spend a little time grepping the tomcat docs and even do<br>> some searches over at the Sun website as they have their own spin off app<br>> server based on Tomcat, which is to say it is basically branded Tomcat.
<br>><br>> brad<br>><br>> On 6/27/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:<br>>><br>>> When we last left our adventurers...
<br>>><br>>> > I would say that there should be no reason you couldn't do what you want<br>>> to<br>>> > natively within Tomcat. You shouldn't need more than a modicum of java,<br>>> if
<br>>> > any at all to do it. Tomcat should have some native handling of<br>>> > authentication to it's services, which you can use in conjunction with<br>>> your<br>>> > applications.
<br>>> ><br>>> > The big thing to remember is that although you have Apache and Tomcat<br>>> linked<br>>> > using mod_jk, Tomcat is a standalone server, with it's own auth<br>>> mechanisms
<br>>> > and capabilities. Mod_jk simply allows the java content to be passed<br>>> off to<br>>> > tomcat automagically through apache instead of having to directly<br>>> address<br>>> > the server over port 8080 or whereever you set it up at.
<br>>> ><br>>> > You probably know that, but just in case, I figured, I would expound as<br>>> I<br>>> > know plenty of java developers that have very little clue about the<br>>> workings
<br>>> > of the app server and vice-versa.<br>>> ><br>>> > In short, it should be able to be done, and I would say to leverage<br>>> Tomcat<br>>> > to do what you need to do.<br>
>> ><br>>> > brad<br>>><br>>> I just figured that since the trouble was put into making a mod_jk, and<br>>> not merely passing off the request to tomcat (mod_rewrite or proxy style),
<br>>> that maybe it did more than that. Like accepting requests back in some<br>>> way-shape-or-form.<br>>><br>>> I'm attempting to use a Filter handle the request. Am I barking up the<br>>> wrong tree? Or is this the way to go?
<br>>><br>>> -Josh<br>>><br>>> ><br>>> > On 6/27/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:
<br>>> > ><br>>> > > It got a little out of hand but that was just some friendly banter.<br>>> Merely<br>>> > > commenting on how sometimes someone here will ask a question and
<br>>> someone<br>>> > > else will recommend that they change their distro or platform. I<br>>> actually<br>>> > > completely agree with Brad. Enterprise (or "Enterprisey") is nothing
<br>>> but<br>>> > > bullshit. Its all about a good language for the job at hand and a<br>>> > > good<br>>> > > design. And I try, God knows I try, but I hate Java for<br>>> webprogramming.
<br>>> > ><br>>> > > So anyway, is it possible to verify someone's session and then dish<br>>> out<br>>> > > the file (using Apache/Tomcat)? And I don't care what kind of file it
<br>>> is.<br>>> > > Anything from txt to xml to pdf or jpg. I just don't want to use Java<br>>> to<br>>> > > 'stream' the file (even though that is the common answer I've seen)<br>
>> since<br>>> > > that is essentially duplicating code for something that Tomcat and<br>>> Apache<br>>> > > can already do.<br>>> > ><br>>> > > And my deepest apologies to any "Java lovers" (if there is such a
<br>>> thing)<br>>> > > and "Enterprisey believers". I know not what I do.<br>>> > ><br>>> > > xo<br>>> > > -Josh<br>>> > ><br>>> > > When we last left our adventurers...
<br>>> > ><br>>> > > > Since this is all started and I'm feeling feisty this morning, I'll<br>>> add<br>>> > > my<br>>> > > > $.02 to the debate.<br>>> > > >
<br>>> > > > I've supported and contributed to application devlopment using<br>>> various<br>>> > > > languages and platforms. I can say with all confidence that<br>>> language
<br>>> > > has<br>>> > > > only a small part to play with stability or<br>>> > > enterprise-worthy-ness. It's<br>>> > > > about the coders and the project spec.
<br>>> > > ><br>>> > > > Java is nice; it runs everywhere; and is OO by nature. Perl is<br>>> > > > Perl<br>>> -<br>>> > > it<br>>> > > > does what it does and makes coffee with the right CPAN
<br>>> > > modules. However, in<br>>> > > > both of these cases, don't consider marketing propaganda, corporate<br>>> > > dollars,<br>>> > > > and press for reality.
<br>>> > > ><br>>> > > > I've seen Java fail to accomplish the project's goals just as<br>>> quickly as<br>>> > > if<br>>> > > > it was spec'd for Perl. On the flip side, I've seen PHP create an
<br>>> app<br>>> > > for a<br>>> > > > quarter of the money and less than an 8th of the time of a<br>>> comparable<br>>> > > java<br>>> > > > solution. Of course, I've also seen some awsome things being
<br>>> developed<br>>> > > > using Java.<br>>> > > ><br>>> > > > My complaint with Java is the complexity involved in setting up an<br>>> > > efficient
<br>>> > > > environment. Tomcat is not a simple app to setup and run -<br>>> especially<br>>> > > if<br>>> > > > you are linking it to dynamically serve regular html or some form
<br>>> > > > of<br>>> > > > webscript pages like php.<br>>> > > ><br>>> > > > Perl is also a beast. The fact that it has a loosely defined form<br>>> > > without
<br>>> > > > any real rigidity in its syntax makes for some very very very ugly<br>>> code.<br>>> > > > And don't get me started on CPAN.<br>>> > > ><br>>> > > > In all, there is no perfect language out there now. A good
<br>>> programmer<br>>> > > does<br>>> > > > the best job he / she can with the best tool for the job. They<br>>> don't<br>>> > > simply<br>>> > > > do it because they can or because the marketing says its good and
<br>>> > > > "enterprise ready". But that rule should hold for all things IT.<br>>> > > ><br>>> > > ><br>>> > > ><br>>> > > > On 6/27/06, Pete Cummings <
<a href="mailto:pete@linuxcowboy.com">pete@linuxcowboy.com</a>> wrote:<br>>> > > > ><br>>> > > > > Websphere !!!!! That's great if you want to "port" your freakin<br>>> job
<br>>> > > > > to<br>>> > > > > India! enterprise software =Asian concentration camps!!! Stick<br>>> with<br>>> > > Open<br>>> > > > > Source and live free (or die).
<br>>> > > > ><br>>> > > > ><br>>> > > > > David J. Andruczyk wrote:<br>>> > > > ><br>>> > > > > Use an enterprise application.
i.e. don't ask your local LUG,<br>>> ask<br>>> > > the<br>>> > > > > enterprise vendors..<br>>> > > > ><br>>> > > > > The first one that pops into my head is IBM's websphere. (only
<br>>> > > > > because<br>>> > > > > of the 40+ servers I support most run it with oracle for all<br>>> their<br>>> > > > > web<br>>> > > > > stuff) and this is a large worldwide "enterprise" level site.
<br>>> Aside<br>>> > > > > from that I don't know much about websphere. (I support the<br>>> boxes,<br>>> > > > > not<br>>> > > > > the customer apps)
<br>>> > > > ><br>>> > > > ><br>>> > > > ><br>>> > > > > --- <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> wrote:<br>>> > > > >
<br>>> > > > > Sing now while you can. Sure perl makes that little stuff<br>>> easier.<br>>> > > But<br>>> > > > > when<br>>> > > > > you're writing enterprise applications you can't use a toy like
<br>>> that.<br>>> > > > > And<br>>> > > > > you want to talk about Scalable? I'd love to see you scale your<br>>> hippy<br>>> > > > ><br>>> > > > > programs across multiple servers!
<br>>> > > > ><br>>> > > > > Love<br>>> > > > > -Josh<br>>> > > > ><br>>> > > > > Well i'm sure you're java solution will be scalable and
<br>>> > > enterprise<br>>> > > > > ready enough to allow you plenty of time to fix your tie while<br>>> you<br>>> > > > > reassess your paradigm for a more proactive approach.
<br>>> > > > ><br>>> > > > > On 6/26/06, <a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a> <<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>><br>>> > > > > <
<a href="mailto:joshj@linuxmail.org">joshj@linuxmail.org</a>> wrote:<br>>> > > > ><br>>> > > > > Don't give me that "right tool for the job" malarky you<br>>> > > > > freakin
<br>>> > > > ><br>>> > > > > Perl<br>>> > > > ><br>>> > > > > hippy. Go back to the commune with all the other Perl, PHP,<br>>> > > > > and
<br>>> > > > ><br>>> > > > > Python<br>>> > > > ><br>>> > > > > programmers.<br>>> > > > ><br>>> > > > > _______________________________________________
<br>>> > > > > nflug mailing list<br>>> > > > > nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > ><br>>> > > > > _______________________________________________
<br>>> > > > > nflug mailing list<br>>> > > > > nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > ><br>>> > > > > Dave J. Andruczyk
<br>>> > > > ><br>>> > > > > __________________________________________________<br>>> > > > > Do You Yahoo!?<br>>> > > > > Tired of spam? Yahoo! Mail has the best spam protection around
<br>>> > > > > <a href="http://mail.yahoo.com">http://mail.yahoo.com</a><br>>> > > > > _______________________________________________<br>>> > > > > nflug mailing list
<br>>> > > > > nflug@nflug.orghttp://www.nflug.org/mailman/listinfo/nflug<br>>> > > > ><br>>> > > > ><br>>> > > > ><br>>> > > > > _______________________________________________
<br>>> > > > > nflug mailing list<br>>> > > > > <a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> > > > > <a href="http://www.nflug.org/mailman/listinfo/nflug">
http://www.nflug.org/mailman/listinfo/nflug</a><br>>> > > > ><br>>> > > > ><br>>> > > > ><br>>> > > ><br>>> >> _______________________________________________
<br>>> > > nflug mailing list<br>>> > > <a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> > > <a href="http://www.nflug.org/mailman/listinfo/nflug">http://www.nflug.org/mailman/listinfo/nflug
</a><br>>> > ><br>>> ><br>>> _______________________________________________<br>>> nflug mailing list<br>>> <a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br>>> <a href="http://www.nflug.org/mailman/listinfo/nflug">
http://www.nflug.org/mailman/listinfo/nflug</a><br>>><br>><br>_______________________________________________<br>nflug mailing list<br><a href="mailto:nflug@nflug.org">nflug@nflug.org</a><br><a href="http://www.nflug.org/mailman/listinfo/nflug">
http://www.nflug.org/mailman/listinfo/nflug</a><br></blockquote></div><br>