As Jordan Michaels wrote, in the "vhost + mod_rewrite + tomcat
vhosting without XML setup" discussion:
> But until we have a custom connector like JRun/ServletExec have, we
> have to deal with modifying our j2ee configs a bit for new sites.
So I'm wondering why we can't just go get our own magic connector and
solve this problem.
Do we have a clear definition of what stuff the JRun/ServletExec
connectors actually do, that current Open Source solutions lack?
What would it take to grab the mod_jk source and add the functionality?
Or, more likely, where would we find a suitable (C?) developer that
could do the work - I guess there's a JBoss discussion group
somewhere, so that's perhaps the best place to start, once we know
what we're after.
Vivio employs a C-programmer, but researching this to the point of where
a custom connector could actually be produced represents a significant
time investment on our part. It may actually be more cost-effective to
hire someone who is already intimately familiar with the systems, like a
current mod_jk programmer.
Anything is possible, it's just a matter of time and money.
-Jordan
> To unsubscribe from this group, send email to railo+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
>
--
Warm regards,
Jordan Michaels
Vivio Technologies
http://www.viviotech.net/
Open BlueDragon Steering Committee
Railo Community Distributions
I don't want to be a naysayer, but this sort of virtualization pretty
much circumvents all the encapsulation and security that the JEE model
provides, so I think it'll be a rather tough sell. Suddenly arbitrary
code can execute in my application's context and I have no control
over it? I'm sorry, what?
As CFML pushes farther into the JEE sphere, that means some tradeoffs.
In particular, CFML has always been about zero structure,
quick'n'dirty, make it work code (hence it's pervasive bad image), and
getting away from that isn't a bad thing. A little forethought into
application structure and packaging is a good thing. It also means
your app will actually be able to integrate with other apps using well
defined rules and interfaces.
The WAR-centric approach of JEE web apps is really beneficial.
Deployment (even of single apps onto dedicated infrastructure) is
enormously easier. Dependency management is hugely simplified.
Synchronizing environments (both between developers and between
dev/test/staging/production) is a cinch. The only real downside is
that you have to structure your functionality, rather than just
throwing templates around willy-nilly to get the job done, and that's
hardly a downside.
cheers,
barneyb
On Tue, Mar 30, 2010 at 4:03 PM, Jordan Michaels <jor...@getrailo.org> wrote:
> I've always assumed my best bet to get a custom connector developed would be
> to sweet talk (IE: pay) a current mod_jk developer to help our CFML
> communities out. However, note that both JRun and Servletexec are customized
> J2EE containers, so I imagine there's a bit more to it then just the
> connector itself. Probably some sort of filter if I had to guess, but this
> is not my area of expertise, so I'm not sure.
>
> Vivio employs a C-programmer, but researching this to the point of where a
> custom connector could actually be produced represents a significant time
> investment on our part. It may actually be more cost-effective to hire
> someone who is already intimately familiar with the systems, like a current
> mod_jk programmer.
>
> Anything is possible, it's just a matter of time and money.
>
> -Jordan
>
--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/
I'm *not* saying we should be copying JRun exactly, and lose the
security of encapsulated contexts.
Also, I'm seeing this connector as an additional option, not a
replacement for the current methods.
From my perspective the key benefit of this is single configuration -
being able to setup virtual hosts in Apache and have an equivalent
context created on the Tomcat side; creating an Alias in Apache and
having Railo able to use it in the same way as other mappings - that
sort of stuff.
--
To unsubscribe, reply using "remove me" as the subject.
But that's EXACTLY what you say you want. Either the container has
discrete containers for the different apps or it doesn't.
The point is that in the JEE world, the web container (Tomcat, et al)
does application demarcation, not the web server (Apache). The reason
the JRun connector can do what it can is because it passes filesystem
demarcation back to the web server and removes runtime demarcation
completely. All your applications are mushed into one server space.
Have you looked at non-direct proxying from Apache to Tomcat? E.g.
proxying http://domain.com/index.cfm through to
http://localhost:8080/domain.com/index.cfm. That'd let you do some
virtualization of the applications without requiring a bunch of voodoo
in the connector or changes to Tomcat config to spin up new sites.
Just create the folder and you're done.
cheers,
barneyb
> --
> To unsubscribe, reply using "remove me" as the subject.
>
--
I've done that plenty of times, and it works a treat!
The only rough spot is if your app lives at "/", vs. "/app", but even
then, a per-application mapping for "/" has worked for me in the past
(I did have to add the railo-context mapping too, below the "/" one,
IIRC).
I too would recommend people think about having portable apps though,
vs. hacking around the stuff designed to work with portable apps.
I'm very happy I moved images and other assets into their own "place".
Way more flexible, I think.
Hrm... that would be a cool feature for CFE-- a variable you could
set so when you drag assets into the editor it automatically prepends
them with said variable.
Or something like that, for static resource mapping & validation... yeah...
:den
--
It is a just political maxim, that every man must be supposed a knave.
David Hume
The problem with the proxy method is that you may not WANT Tomcat to
handle everything. Running PHP and CFML side by side for example is
problematic without complex rewrite rules. Not that it can't be done,
it's just complicated, and that's generally not what CFML is about. The
idea behind CFML is to "make complex tasks simple", right? Well, that's
what folks are asking for here with a custom connector.
No one is saying the CFML world should abandon the "discrete container"
deployment method - they just want the choice to have a method that's
similar to the ACF and BDJX methods they're already familiar with.
-Jordan
--