Thanks, Darien. You are on the right track. I found the issue. It is
caused in Adobe CF9 when the new "Component Cache" checkbox is
enabled, in the following scenario:
1. You have multiple, separate CF applications,
2. multiple applications share a common location for some CFCs mapped
in the CFIDE,
3. and multiple apps have their own "this.mapping["/root"] ..."
setting in Application.cfc that maps some CFCs that use the same "/
root" path to a physical location within each app.
For example, perhaps I have two Mach-II applications. Mach-II and
Coldspring are in a shared location on the server, mapped as "/machii"
and "/coldspring" in the CFIDE mappings. Each application has a local
mapping to components that are specific to each application, declared
in Application.cfc like this:
<cfset this.mappings['/us'] = expandPath('cfjar/us') />
In app 1, the path to /us will be mapped to something like: /var/apps/
app1/cfjar/us, and in app2, the path is /var/apps/app2/cfjar/us.
If, in this case, there are components that exist in app1 that do not
exist in app 2, and Component Cache is enabled, then app2 will have
access to app1's components after app1 has instantiated them, which is
bad. Likewise, if there are components that have the same package and
name but are different versions in each app, then the first app to
load it wins -- all other apps get the version from the first app.
I was able to find this by observing the classes generated by CF using
jvisualvm. I could see that when Component Cache was enabled, only one
version of a compiled Java class for the CFC was created, even if two
different versions existed in the different apps.
I believe this is a bug in Adobe CF9: with separate applications, the
Component Cache should take the application context into account.
Otherwise, application-specific mappings won't be truly isolated.
Why would you want to do this? Well, we are creating a build processes
for separate apps that are deployed within the same CF instance that
only include the specific dependencies needed by the app. For example,
a content service is the only one that should have access to
us.lampo.content.*, while a payment service should only see
us.lampo.payment.* components. We don't want the content service to
have access to payment components, and vice-versa. Likewise, if there
are shared components in us.lampo.shared.* that are included in both
apps, but possibly different version of a shared component, these too
should remain independent and isolated.
Fortunately, the simple fix is to turn off Component Cache for now.
The feature doesn't seem to be a significant performance boost anyway.
Thanks,
Doug
On Apr 7, 3:03 pm, UniDyne <[email protected]> wrote:
> I tested my theory out and it doesn't work. I tried instantiating
> DefaultXmlBeanFactory in the Request scope in one app, then in another
> that did not have it in the path and it failed. Nothing special. Do
> your apps share a common directory structure? Is ColdSpring installed
> elsewhere in ColdFusion's search path? Does your Application.cfc
> declare any mappings that might cause ColdSpring to be within the
> path?
>
> On Thu, Apr 7, 2011 at 11:04 AM, UniDyne <[email protected]> wrote:
> > They run from the same Java runtime. My guess is that once the object
> > is instantiated, the compiled version is in the runtime search path. I
> > actually ran into a similar issue in a non-CF project on Jetty. If
> > each app had its own Java instance, this probably wouldn't happen. The
> > solution would be to make sure they are namespaced and the accessors
> > are not public. Not exactly possible with ColdSpring.
>
> > Darien Brown
>
> > On Thu, Apr 7, 2011 at 10:15 AM, Doug <[email protected]> wrote:
> >> No, unfortunately not. My non-Mach-II test app actually initializes
> >> the beanFactory into Request scope, and the same behavior appears.
>
> >> I'll post what I learn when I fix it.
>
> >> Thanks,
>
> >> Doug
>
> >> On Apr 6, 6:01 pm, "Peter J. Farrell" <[email protected]> wrote:
> >>> Nothing rings a bell other than accidentally sharing the application
> >>> scope. Are you sharing the application name scope across the apps?
>
> >>> .pjf
>
> >>> Doug said the following on 04/06/2011 05:33 PM:
>
> >>> > I setup two small skeleton apps that don't use Mach-II. First, I
> >>> > tested to see if there was a bug in ACF 8 by not using ColdSpring, but
> >>> > found that the dependencies were resolved, or not resolved, correctly.
> >>> > Then, I manually instantiated the ColdSpring DefaultXmlBeanFactory
> >>> > into request scope in each app. I found that App A was again able to
> >>> > instantiate a CFC that it shouldn't be able to see, only after it was
> >>> > instantiated in App B.
>
> >>> --
> >>> Peter J. Farrell
> >>> [email protected]
> >>> [email protected]http://blog.maestropublishing.com
> >>> Identi.ca / Twitter: @maestrofjp
>
> >> --
> >> To post to this group, send email to
> >> [email protected]
> >> For more options and to unsubscribe, visit this group
> >> athttp://groups.google.com/group/mach-ii-for-coldfusion?hl=en
>
> >> SVN:http://svn.mach-ii.com/machii/
> >> Wiki / Documentation / Tickets:http://trac.mach-ii.com/machii/
--
To post to this group, send email to [email protected]
For more options and to unsubscribe, visit this group at
http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
SVN: http://svn.mach-ii.com/machii/
Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
