Danga and watching other FDs
Lo,
AxKit2.
Well, I've finally got round to farming out the slow bits of my app.
Atm it's using Net::Server, but I am going to look at gearmand shortly.
Anyway, as it's the first time I've used sockets, could someone have a
look at my first hack and tell me what I'm missing please?
I essentially serialise a hash and the other end sends back xml.
I have a simple xmlresponse hook. It calls various methods in
the Firstb2b::Acme class, the method I'm testing with is below.
Acme uses Firstb2b::AxKit2::SubprocessEvent, which is also below.
Qu:
1) $bbref should be stored somewhere, but where? I presume in the notes
of something. If this is correct, which notes and how do I get them?
I suppose Ax2/Danga somehow maintains a list of watched fds along with a
persitent data structure?
2) What does the callback of addotherfds do? I can't get it to fire.
sub _state_login {
my Firstb2b::Acme $self = shift;
$self-{plugin}-log(LOGDEBUG, \n\nHERE\n\n);
my $PORT = 2000;
my $sock = IO::Socket::INET-new(
PeerHost = 'localhost',
PeerPort = $PORT,
Proto = 'tcp',
Type = SOCK_STREAM,
Blocking = 0,
)
or die Error creating client on port $PORT : [EMAIL
PROTECTED];
IO::Handle::blocking( $sock, 0 );
my $var = Firstb2b::AxKit2::SubprocessEvent-new($sock);
$var-watch_read(1);
my $cb = sub { die
'YAYAYAAA'; };
$var-AddOtherFds( fileno($sock) = $cb );
$var-write( freeze( { method = 'state_login' } ) . 'ROSE' . EOL );
#$var-write( 'HELLO' . 'ROSE' . \015\012 );
my $dom = $self-get_base_xml(1);
my $root = $dom-getElementsByTagName('main')-get_node(1);
$root-setAttribute( 'uri_post', $self-uri_gen( { state = 'start'
} ) );
return $dom;
}
package Firstb2b::AxKit2::SubprocessEvent;
use base qw(Danga::Socket);
use fields qw(bar);
sub new {
my Firstb2b::AxKit2::SubprocessEvent $self = shift;
my $sock = shift;
$self = fields::new( $self ) unless ref($self);
$self-SUPER::new($sock);
return $self;
}
sub event_read {
my Firstb2b::AxKit2::SubprocessEvent $self = shift;
my $bref = $self-read(1);
return $self-close($!) unless defined $bref;
chomp $$bref;
print 'HER', $$bref;
$self-do_stuff;
}
sub do_stuff {
my Firstb2b::AxKit2::SubprocessEvent $self = shift;
print start do_stuff\n;
print finish do_stuff\n;
#$self-close;
}
1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit::XSP::WebUtils::redirect causing (many) warnings in error_log
On Nov 26, 2007 7:45 PM, Lars Skjærlund [EMAIL PROTECTED] wrote: And if not (they're just warnings after all), how to stop them from clogging the error log file. (They occur, even though I've set Apache's LogLevel to 'error' - though if this is really the problem, I'd probably need to go and ask on the mod_perl or Apache list.) Try AxDebugLevel instead. ;-) Hmm. I hadn't thought of that, so thanks for the suggestion. It does not make any difference though. Also, I doubt whether these warnings are actually caused by AxKit's debugger: there's no [AxKit]. Well, assuming it's not something to worry about, I suppose I can live with it and just regex those lines out when viewing the error log (they're responsible over 95% of the error log). It just would be nice to know what I'm being warned against. Thanks. Martijn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit::XSP::WebUtils::redirect causing (many) warnings in error_log
On 27-Nov-07, at 11:35 AM, Martijn wrote: On Nov 26, 2007 7:45 PM, Lars Skjærlund [EMAIL PROTECTED] wrote: And if not (they're just warnings after all), how to stop them from clogging the error log file. (They occur, even though I've set Apache's LogLevel to 'error' - though if this is really the problem, I'd probably need to go and ask on the mod_perl or Apache list.) Try AxDebugLevel instead. ;-) Hmm. I hadn't thought of that, so thanks for the suggestion. It does not make any difference though. Also, I doubt whether these warnings are actually caused by AxKit's debugger: there's no [AxKit]. Well, assuming it's not something to worry about, I suppose I can live with it and just regex those lines out when viewing the error log (they're responsible over 95% of the error log). It just would be nice to know what I'm being warned against. I think it's a remnant of debug code. You can delete the line. AxTraceIntermediate gets rid of the need (or utility) of it. However it does mean something is failing in your XSP code - either a runtime or compile time exception. If everything worked perfectly you wouldn't be seeing it. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Danga and watching other FDs
On 27-Nov-07, at 8:03 AM, [EMAIL PROTECTED] wrote: 1) $bbref should be stored somewhere, but where? I presume in the notes of something. If this is correct, which notes and how do I get them? I suppose Ax2/Danga somehow maintains a list of watched fds along with a persitent data structure? Store it in your Firstb2b::AxKit2::SubprocessEvent class. (add another field). 2) What does the callback of addotherfds do? I can't get it to fire. You don't need it. That's only required when you can't create a subclass of Danga::Socket. Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modification of non-creatable hash value attempted
On Tue, 27 Nov 2007, Matt Sergeant wrote:
} On 8-Nov-07, at 7:52 PM, Vince LaMonica wrote:
}
} xsp:page xmlns:xsp=http://www.apache.org/1999/XSP/Core;
} xmlns:global=http://www.creITve.de/2002/XSP/Session;
} xmlns:auth=http://www.creITve.de/2002/XSP/Auth;
} xmlns:session=http://www.apache.org/1999/XSP/Session;
}
} login
}
} xsp:logic
} my $login =
} PRIVATE::WWW::com::comground::screendoor::dealer::login($cgi);
} if ($login-{valid}) {
} eval {
} auth:login destination=summary.xsp
} auth:access
} type=userxsp:expr$login-{booth}/xsp:expr/auth:access
} /auth:login
} };
} $session = $r-pnotes('SESSION');
} session:set-attribute
} name=boothxsp:expr$login-{booth}/xsp:expr/session:set-attribute
} session:set-attribute
} name=dealerxsp:expr$login-{dealer}/xsp:expr/session:set-attribute
} die $@ if $@;
} }
} /xsp:logic
} ---8-
}
} So at this level $r isn't in scope. At least not the proper AxKit $r. You need
} to be in the main output stage of the XSP page for the right $r to be valid.
Thanks for the help - it is much appreciated! The only issue is that this
code has worked for 3+ years on the old server [still works, if i update
DNS so that folks go there instead]. When I moved the code to the new
server, it started failing. I *think* the version of AxKit on the old
server was 0.99 or 0.98. The version on the new server is 1.7.
I'm not very familar with AxKit, as all of the development of this was
done prior to my arrival 3 years ago. Is there documentation that would
help explain how to migrate from a pre-1.0 AxKit to v1.7?
Thanks so much for your reply.
/vjl/
--
Vince J. LaMonica Knowledge is knowing a street is one way.
[EMAIL PROTECTED] * Wisdom is still looking in both directions.
Donate today, please: http://www.cancer.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AxKit::XSP::WebUtils::redirect causing (many) warnings in error_log
On Nov 27, 2007 4:52 PM, Matt Sergeant [EMAIL PROTECTED] wrote: However it does mean something is failing in your XSP code - either a runtime or compile time exception. If everything worked perfectly you wouldn't be seeing it. Indeed. What confuses me though is that even the following block of code causes the error to appear: ---8--8--- ?xml version=1.0? xsp:page xmlns:xsp=http://apache.org/xsp/core/v1; xmlns:web=http://axkit.org/NS/xsp/webutils/v1; xmlroot web:redirect web:uriindex.xml/web:uri /web:redirect /xmlroot /xsp:page ---8--8--- I've learned to not go and shout that I've found a bug in an Axkit::XSP::WebUtils and indeed, it could very well be caused by something that has been modified by me or one of my predecessors, but I have no idea what that something could be. It's not very important (any more) though. The realisation that 95% all this code in the error log was caused by one and the same thing and that it, probably, is not very important already helped a lot. Now I can concentrate on real errors. Of which there are, suddenly, not very many :) Thanks again. Martijn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Modification of non-creatable hash value attempted
On 27-Nov-07, at 12:21 PM, Vince LaMonica wrote: } So at this level $r isn't in scope. At least not the proper AxKit $r. You need } to be in the main output stage of the XSP page for the right $r to be valid. Thanks for the help - it is much appreciated! The only issue is that this code has worked for 3+ years on the old server [still works, if i update DNS so that folks go there instead]. When I moved the code to the new server, it started failing. I *think* the version of AxKit on the old server was 0.99 or 0.98. The version on the new server is 1.7. I'm not very familar with AxKit, as all of the development of this was done prior to my arrival 3 years ago. Is there documentation that would help explain how to migrate from a pre-1.0 AxKit to v1.7? There isn't. pre-1.0 is a pretty darn old AxKit, so the differences are probably pretty major. I would start with the XSP guide and learn how it works from there, and try and figure out how to make the app work under real XSP (I suspect back at 1.0 it was a bit of a hack). Matt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
CONTINUATIONS
Lo,
I've had a look at the webmail example and am not much the wiser.
Could someone have a look at my plugin and give me a big kick in
the right direction so I can make it use continuations please?
I've made a bit of a start, but am confused as to the correct way
of doing things...
use Firstb2b::Acme;
use Data::Dumper;
sub init {
{$Firstb2b::Acme::subref};
}
sub register {
my $self = shift;
$self-register_hook('xmlresponse' = 'hook_xmlresponse1');
$self-register_hook('xmlresponse' = 'hook_xmlresponse2');
}
sub hook_xmlresponse2 {
my ($self, $input) = @_;
$self-log(LOGDEBUG, \n\nXMLRESPONSE 2\n\n);
if ($self-client-notes('xml_response') == OK) {
return OK, $input;
}
return $self-client-notes('xml_response');
}
sub hook_xmlresponse1 {
my ($self, $input) = @_;
my ( $dom, $sub, $bl, $uri );
my $client = $self-client;
$self-log(LOGDEBUG, \n\nXMLRESPONSE 1\n\n);
$client-notes('xml_response', DECLINED);
if ( $client-headers_in-filename =~
/\.(?i:png|gif|css|jpg|js|html)$/ ) {
$self-log(LOGDEBUG, 'Declined: '.
$client-headers_in-filename);
return DECLINED;
}
$bl = Firstb2b::Acme-new( $self );
$sub = 'state_'.$bl-get_state;
$dom = $bl-$sub;
return REDIRECT if $dom == REDIRECT;
$input-dom( $dom );
my $styles = $bl-get_stylesheets( { state = $bl-get_state,
is_pop = scalar
$self-client-param( 'is_pop' ) ,
pop_id = scalar
$self-client-param( 'pop_id' ) ,
pop_text = scalar
$self-client-param( 'pop_text') ,
use_pop_js = scalar
$self-client-param( 'use_pop_js') } );
my $out = $input-transform(map XSLT( $_-{style}, %{$_-{params}}
), @{$styles});
return OK, $out;
} # hook_xmlresponse1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
