date:20051016

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native-configure (in module jakarta-tomcat-connectors) failed

2005-10-16 Thread Bill Barker

To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native-configure has an issue affecting its community
integration.
This issue affects 2 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native : Connectors to various web servers
- jakarta-tomcat-jk-native-configure : Connectors to various web servers

Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native-configure/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were
provided:
-ERROR- Unhandled Property: --with-apxs on: Configure on
Project:jakarta-tomcat-jk-native-configure
-INFO- Failed with reason build failed

The following work was performed:
http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native-configure/gump_work/buildscript_jakarta-tomcat-connectors_jakarta-tomcat-jk-native-configure.html
Work Name:
buildscript_jakarta-tomcat-connectors_jakarta-tomcat-jk-native-configure (Type:
Build)
Work ended in a state of : Failed
Elapsed: 28 secs
Command Line:
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native/configure
--with-apxs
[Working Directory:
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... (cached) no
checking for shl_load in -ldld... (cached) no
checking for dlopen... (cached) no
checking for dlopen in -ldl... (cached) yes
checking whether a program can dlopen itself... (cached) yes
checking whether a statically linked program can dlopen itself... (cached) yes
appending configuration tag "F77" to libtool
checking for test... /usr/bin/test
checking for rm... /bin/rm
checking for grep... /bin/grep
checking for echo... /bin/echo
checking for sed... /bin/sed
checking for cp... /bin/cp
checking for mkdir... /bin/mkdir
checking for uint32_t... yes
checking size of uint32_t... 4
checking for u_int32_t... yes
checking size of u_int32_t... 4
checking for unsigned long... yes
checking size of unsigned long... 4
checking for unsigned int... yes
checking size of unsigned int... 4
checking for unsigned long long... yes
checking size of unsigned long long... 8
checking for unsigned longlong... no
checking size of unsigned longlong... 0
checking for snprintf... yes
checking for vsnprintf... yes
checking for flock... yes
checking for setsockopt in -lsocket... no
checking whether to use SO_RCVTIMEO with setsockopt()... yes
checking whether to use SO_SNDTIMEO with setsockopt()... yes
need to check for Perl first, apxs depends on it...
checking for perl... /usr/bin/perl
configure: error: Invalid location for apxs: 'yes'
-

To subscribe to this information via syndicated feeds:
- RSS:
http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native-configure/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native-configure/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 1816102005, vmgump.apache.org:vmgump-public:1816102005
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native-configure (in module jakarta-tomcat-connectors) failed

2005-10-16 Thread Bill Barker

To whom it may engage...

This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]

Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native-configure/index.html

That said, some information snippets are provided here.

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 1816102005, vmgump.apache.org:vmgump-public:1816102005
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Form based + Basic Authentication

2005-10-16 Thread Jess Holle

Does anyone have any pointers as to how one can achieve form-based 
authentication with an "out" for basic authentication?


Essentially given programmatic clients that expect a protocol level 
authentication mechanism like HTTP Basic and human clients that are more 
comfortable with form based authentication, the desire would be to have 
each URL do form based authentication except where the user-agent or 
headers suggest thatt basic authentication is more appropriate.  After 
initial login cookie-based behavior is acceptable in either case.  What 
is not realistic, however, is to expect every programmatic client to 
know about form based login, which is, after all, an ad hoc 
application-level convention (albeit formalized in the servlet spec) 
rather than a protocol-handler-level standard.


What I'm looking for is pointers to do this in a way that will be 
portable across all servlet 2.4 and higher servlet engines.


Somewhat separately we may end up with our own custom realm (or 
realm-like object) at least in cases where we can get a hold of this 
layer as only being able to check a single LDAP is not a realistic 
constraint these days.  [Tomcat's JNDI realm allow you to provide an 
alternate URL when the first URL is unreachable, but what's needed is a 
list of URLs where the first containing data for a given user id wins.  
One could/should constrain the URLs to not contain overlapping user id 
sets, of course.]


--
Jess Holle

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Form based + Basic Authentication

2005-10-16 Thread Jess Holle

P.S. If none of this is possible in any quasi-portable manner, I'd still 
be interested in how to do it just for Tomcat 5.5.x.


Jess Holle wrote:

Does anyone have any pointers as to how one can achieve form-based 
authentication with an "out" for basic authentication?


Essentially given programmatic clients that expect a protocol level 
authentication mechanism like HTTP Basic and human clients that are 
more comfortable with form based authentication, the desire would be 
to have each URL do form based authentication except where the 
user-agent or headers suggest thatt basic authentication is more 
appropriate.  After initial login cookie-based behavior is acceptable 
in either case.  What is not realistic, however, is to expect every 
programmatic client to know about form based login, which is, after 
all, an ad hoc application-level convention (albeit formalized in the 
servlet spec) rather than a protocol-handler-level standard.


What I'm looking for is pointers to do this in a way that will be 
portable across all servlet 2.4 and higher servlet engines.


Somewhat separately we may end up with our own custom realm (or 
realm-like object) at least in cases where we can get a hold of this 
layer as only being able to check a single LDAP is not a realistic 
constraint these days.  [Tomcat's JNDI realm allow you to provide an 
alternate URL when the first URL is unreachable, but what's needed is 
a list of URLs where the first containing data for a given user id 
wins.  One could/should constrain the URLs to not contain overlapping 
user id sets, of course.]


--
Jess Holle



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

40 matches

Mail list logo