If you are using Wonder’s JavaMonitor (and if a property has not disabled it)
you should see a Migration (Migrations?) tab on the right side. That should
give you instructions and a mod_proxy config that matches the current
JavaMonitor setting. I believe this is the work of Anjo. And, yes, it
Hi Chuck,
On 6 Aug 2014, at 2:27 am, Chuck Hill wrote:
> I’d take a long, hard look at moving to mod_proxy and ending this dependance
> on third party Apache plugins. Unless your configuration changes frequently
> this seems like a better choice.
Tell me more. Is this something that someone
+1
Envoyé de mon iPhone
> Le 2014-08-05 à 12:59, Chuck Hill a écrit :
>
> I’d take a long, hard look at moving to mod_proxy and ending this dependance
> on third party Apache plugins. Unless your configuration changes frequently
> this seems like a better choice.
>
> Chuck
>
>
> On 2014-0
I’d take a long, hard look at moving to mod_proxy and ending this dependance on
third party Apache plugins. Unless your configuration changes frequently this
seems like a better choice.
Chuck
On 2014-08-05, 9:08 AM, "Mark Wardle" wrote:
Yosemite upgrades Apache from 2.2 and 2.4.
I’ve tried
I anticipate that's not a biggie.
You're building via APXS, APXS tries to use the same compiler and
compiler flags to make sure the ABI matches.
Because of how the compiler tools are installed in recent OSX
releases, the compiler is not /usr/bin/cc, it's ... something inside
an Xcode tool
I always do dev in direct connect with ssl enabled :) Apache annoys me when it
times out a page while I’m at a breakpoint. People also have a nasty habit of
using Apache’s doc root as an excuse to fail to use /WebServerResources/
properly. JS and CSS outside of version control is a major pet pee
Yosemite upgrades Apache from 2.2 and 2.4.
I’ve tried recompiling the apache adaptor but compilation files despite
entering a magic incantation:
make ADAPTORS=Apache2.4 LTFLAGS='--tag CC’
/usr/share/apr-1/build-1/libtool: line 8962:
/Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.
Am 05.08.2014 um 16:54 schrieb Klaus Berkling :
>
> On Aug 5, 2014, at 1:04 AM, René Bock wrote:
>
>> But my tests shows, that the WOSession.SessionDidTimeOutNotification is send
>> every time a session terminates – regardless if the session was timed out or
>> terminated explicitly
>> .
>>
On Aug 5, 2014, at 1:04 AM, René Bock wrote:
> But my tests shows, that the WOSession.SessionDidTimeOutNotification is send
> every time a session terminates – regardless if the session was timed out or
> terminated explicitly
> .
> Which is bad, as I only want to take an action on session tim
I would add to (almost) always call super.validateForSave() first.
All your mandatory attributes are tested so you don’t need to write:
if (myAttribute() != null) {
// check some stuff
}
Your mandatory attributes can’t be null after super.validateForSave().
There are some rare circumstances wh
I have a similar requirement than Ted.
But my tests shows, that the WOSession.SessionDidTimeOutNotification is send
every time a session terminates – regardless if the session was timed out or
terminated explicitly
.
Which is bad, as I only want to take an action on session time out :-(
Am
11 matches
Mail list logo
