Custom Connector

[Peter Boughton]

This topic seems to keep coming up - the fact that JRun and
ServletExec have special connectors that make things easier.

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.

[Jordan Michaels]

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

> 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

[Barney Boisvert]

Another thing to consider is that the arrangement JRun has is pretty
much exactly opposite of the way the JEE spec works. JEE is all about
encapsulation: self contained applications doing their thing. They're
then assembled (as black boxes) into complete solutions. As such,
wanting anything to ever exist outside your WAR/EAR is anathema to the
JEE way of life.

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/

[Peter Boughton]

Barney, your message is a little confusing, and is probably why we
need clear details on exactly what the connector would do.

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.

[Ryan Letulle]

I am certainly not asking for anyone that is happy with their technology to change anything either.

I am in a situation where I wrote a site creation system in Win2003/CF7/SQL2000 that I am trying to recreate using all open source replacement parts.

The user completes one form and everything is created from a template.  (site, database, datasource ...)

As of now I cannot do this with Railo/Tomcat.  I would like to get there one day.

</ryan>

--
To unsubscribe, reply using "remove me" as the subject.

[Ryan Letulle]

Let me correct that.  I can do it but when I restart Tomcat everyone else on the server gets logged out and loses all their session variables.

</ryan>

[Barney Boisvert]

> I'm *not* saying we should be copying JRun exactly, and lose the
> security of encapsulated contexts.

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.
>

--

[denstar]

On Wed, Mar 31, 2010 at 11:46 AM, Barney Boisvert wrote:
...

> 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.

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

[Jordan Michaels]

The point, really, is that folks *like* and *want* the same
functionality that ACF and BDJX gives them with their custom connectors.
The main reason I deploy Railo as a common class in Tomcat via the Vivio
installer is because it's the most similar method to what ACF and BDJX
give you. It lowers the learning curve when new programmers enter CFML
programming, or migrate from one CFML engine to another. Keeping the
deployment methods similar between engines facilitates harmony for all
CFML engines.

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

--