[GUMP@vmgump]: Project tomcat-native-trunk-make (in module tomcat-native-trunk) failed

[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 gene...@gump.apache.org.

Project tomcat-native-trunk-make has an issue affecting its community 
integration.
This issue affects 3 projects,
 and has been outstanding for 49 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- tomcat-native-trunk-make :  Tomcat native library using Apache Portable 
Runtime
- tomcat-native-trunk-make-install :  Tomcat native library using Apache 
Portable Runtime
- tomcat-trunk-test-apr :  Tomcat 9.x, a web server implementing the Java 
Servlet 4.0,
...


Full details are available at:

http://vmgump.apache.org/gump/public/tomcat-native-trunk/tomcat-native-trunk-make/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-native-trunk/tomcat-native-trunk-make/gump_work/build_tomcat-native-trunk_tomcat-native-trunk-make.html
Work Name: build_tomcat-native-trunk_tomcat-native-trunk-make (Type: Build)
Work ended in a state of : Failed
Elapsed: 23 secs
Command Line: make 
[Working Directory: /srv/gump/public/workspace/tomcat-native-trunk/native]
-
make[1]: Entering directory 
`/srv/gump/public/workspace/tomcat-native-trunk/native'
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o 
src/address.lo -c src/address.c && touch src/address.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o src/bb.lo 
-c src/bb.c && touch src/bb.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o src/dir.lo 
-c src/dir.c && touch src/dir.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o 
src/error.lo -c src/error.c && touch src/error.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o src/file.lo 
-c src/file.c && touch src/file.lo
/bin/bash /srv/gump/public/workspace/apr-1/dest-20160618/build-1/libtool 
--silent --mode=compile gcc -g -O2 -pthread   -DHAVE_CONFIG_H  -DLINUX 
-D_REENTRANT -D_GNU_SOURCE   -g -O2 -DHAVE_OPENSSL -DHAVE_POLLSET_WAKEUP   
-I/srv/gump/public/workspace/tomcat-native-trunk/native/include 
-I/usr/lib/jvm/java-8-oracle/include -I/usr/lib/jvm/java-8-oracle/include/linux 
-I/srv/gump/public/workspace/openssl-master/dest-20160618/include  
-I/srv/gump/public/workspace/apr-1/dest-20160618/include/apr-1   -o src/info.lo 
-c src/info.c && touch src/info.lo
/bin/bash 

[Bug 59616] SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59616

--- Comment #5 from Mark Thomas  ---
I've found the root cause. There were some changes in the build scripts between
1.1.x and 1.2.x that meant OCSP was always enabled. Validation with
optionalNoCA always fails if OCSP is enabled.

I plan to commit my fix early next week and start the process to release a new
set of Windows binaries for tc-native.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 59616] SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59616

--- Comment #4 from Mark Thomas  ---
Whatever is going wrong is going wrong in OpenSSL. Don't know where the root
cause is at the moment but the error is:
3648:error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify
failed:.\ssl\s3_srvr.c:3270:

Which is triggered a full failure rather than allowing the tc-native code to
decide what to do.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.70

[Felix Schumacher]

Am 15.06.2016 um 21:47 schrieb Violeta Georgieva:

The proposed Apache Tomcat 7.0.70 release is now available for voting.

It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.70/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-1088/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_70/

The proposed 7.0.70 release is:
[ ] Broken - do not release
[x] Stable - go ahead and release as 7.0.70 Stable

Regards,
 Felix


Regards,
Violeta




-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 59716] New: Allow JNDI configuration of CorsFilter

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59716

Bug ID: 59716
   Summary: Allow JNDI configuration of CorsFilter
   Product: Tomcat 7
   Version: 7.0.69
  Hardware: PC
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: lucasthei...@apache.org

Created attachment 33957
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33957=edit
Source code for the delegating filter and integration test.

Currently the CorsFilter is configured by init-param's.  This makes
configuration compile time (as it would be stored in the deployment artifact). 
In my experience, CORS configuration is environmental (I have a different set
of allowed origins based on where I deploy my app: dev/qa/production), and as
such should be runtime.  Pushing config to JNDI (or at least allowing override
in JNDI) allows you to configure the same artifact differently depending on
environment.  I have written a filter that delegates to the CorsFilter to allow
for JNDI config (which i will attach), but it would be quite simple and useful
to move this functionality into the core filter.  I would be willing to patch
the filter as well if you are interested in this approach...

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 59706] HTTP/2 load testing performance

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59706

Remy Maucherat  changed:

   What|Removed |Added

  Attachment #33951|0   |1
is obsolete||

--- Comment #2 from Remy Maucherat  ---
Created attachment 33956
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=33956=edit
Queue v2

Same idea, revised.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [VOTE] Release Apache Tomcat 7.0.70

[Martin Grigorov]

On Wed, Jun 15, 2016 at 9:47 PM, Violeta Georgieva 
wrote:

> The proposed Apache Tomcat 7.0.70 release is now available for voting.
>
> It can be obtained from:
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.70/
> The Maven staging repo is:
> https://repository.apache.org/content/repositories/orgapachetomcat-1088/
> The svn tag is:
> http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_70/
>
> The proposed 7.0.70 release is:
> [ ] Broken - do not release
> [ ] Stable - go ahead and release as 7.0.70 Stable
>

[ X ] Stable - go ahead and release as 7.0.70 Stable

Tested our main application and Apache Wicket WebSockets integration.


>
> Regards,
> Violeta
>

Re: Using modern development tools for friendlier environment for newcomers

[Martin Grigorov]

Hi Chris,

On Fri, Jun 17, 2016 at 12:51 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Martin,
>
> On 6/8/16 3:25 AM, Martin Grigorov wrote:
> > On Tue, Jun 7, 2016 at 11:33 AM, Mark Thomas  wrote:
> >
> >> On 07/06/2016 10:17, Martin Grigorov wrote:
> >>> Hi devs,
> >>>
> >>> Recently a colleague of mine asked me what it takes to become an Apache
> >>> committer.
> >>> I've explained him that he has to choose a project that is interesting
> to
> >>> him and start participating in the mailing lists (helping others at
> >> users@,
> >>> giving opinion and testing releases at dev@), providing patches for
> open
> >>> issues, etc.
> >>> Few days later he came back with the following questions:
> >>>
> >>> 1) Why Tomcat still uses SVN?
> >>> I've told him that this is the SCM tool most of the committers have
> >>> experience with and there were some discussions to move to Git several
> >>> months back.
> >>> I've recommended him to use GitHub's Pull Requests for the time being -
> >> PRs
> >>> are monitored and merged if approved. Even if Tomcat was using Git,
> >> Apache
> >>> Infra doesn't provide tool with Pull Request support (GitLab, Gerrit,
> or
> >>> similar) anyway so there is no big difference from a contributor point
> of
> >>> view.
> >>
> >> If I recall correctly, the consensus last time around was that there was
> >> merit in exploring the options for using git further with a view to
> >> migrating if the majority were convinced there was a benefit to the
> move.
> >>
> >> There is an outstanding task (I need to chase it up) for the infra team
> >> to look at if we could move to a single git repo for multiple branches
> >> or would need multiple repos.
> >>
> >
> > One repo should be possible.
> > Even if there are some problems with the initial conversion from SVN to
> Git
> > the person dealing with it could create N Git repos and then with the
> help
> > of "git remote add" combine them into one with N branches and finally
> push
> > those branches into a single repository.
> >
> >
> >>
> >>> 2) Why Tomcat uses Bugzilla?
> >>> It is archaic and its UI is unfriendly - he said.
> >>> To be honest I didn't have a good answer here. I also don't like
> >> Bugzilla.
> >>> Everybody knows how to use JIRA! It is hard to explain that Apache JIRA
> >>> runs on Tomcat, but Tomcat project itself uses Perl software for issue
> >>> tracking (no matter how good Bugzilla is).
> >>
> >> My personal view is Jira is overly complex and horribly slow. Bugzilla
> >>
> >
> > I think JIRA is slower because the majority of the projects are there.
> > But I guess it would be an overkill for Infra to maintain several
> instances
> > of JIRA (e.g. sharded by project name).
>
> I think it's slower because it's a sledgehammer where a screwdriver will
> do the job. I've never liked JIRA, but as was previously said "tools are
> tools".
>

At my $dailyJob JIRA is not slow at all.
It is Apache JIRA installation problem, not every JIRA installation.
If you are subscribed to infra@ you will see that people complain
relatively often that it is either down or slow. Last such mail is from
yesterday!
IMO Apache JIRA should be split into several instances.
But here is not the place to discuss this topic!

What I was trying to explain is that Tomcat looks like an ageing product
from a tooling point of view: Bugzilla, SVN, ANT, Gump.
It is hard to make Tomcat development attractive to work with tools from
the 90s (figuratively said).

I am not saying that by changing the tooling suddenly a lot of developers
will want to contribute!
I just share the opinion that many developers consider these things when
trying to find an OSS to contribute to.


> >> just works. We don't need any of the extra features Jira offers. Do we
> >> want any of them? None come to mind. Others may have a different view.
> >>
> >
> > I personally like the JIRA plugins that integrate with the SCM tools.
> > Committing with "PROJECT_NAME-1234" in the commit message automatically
> > adds a comment to the respective ticket with a link to Git/SVN repo. It
> is
> > very easy to explore the history of a ticket.
>
> All of this can be done with svn + bugzilla, too. I guess just nobody
> bothered to do it @ASF until JIRA came along.
>
> > Also it has a proper "Fix version" field. With it it is much easier to
> > create a changelog. No need to maintain one manually.
>
> Bugzilla has a "Target Milestone", but that is disabled in Bugzilla,
> probably because the list of milestones would get insanely long. Maybe
> another reason that JIRA is so slow: all that metadata is actually in
> there instead of having been deemed "too much" at some point in the past.
>
> >>> I know that SVN, Git, JIRA, Bugzilla are just tools. We can do our work
> >>> with any of them.
> >>> Maybe there are more (and more important!) reasons why my colleague
> >> didn't
> >>> start contributing to Tomcat yet but I also agree with him that by
> moving
> >>> to more 

[Bug 59616] SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59616

--- Comment #3 from Mark Thomas  ---
Results of further testing:

The following work:
OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.x + OSX client
OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + OSX client
OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.6 + OSX client
OSX + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.6 + Win client

The following fail:
Win + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + Win client
Win + Tomcat 9.0.x + OpenSSL 1.0.2h + APR 1.5.2 + tc-native 1.2.7 + OSX client

Assuming there is only a single bug here, the results above rule everything out
apart from the OS hosting the Tomcat server. That suggests an OS specific
element of one of the native builds is responsible for this change. It is going
to take some more work to track this down.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Avoid use of SecureRandom during server startup

[Christopher Schultz]

Rémy,

On 6/16/16 5:52 AM, Rémy Maucherat wrote:
> 2016-06-16 11:25 GMT+02:00 Andy Wilkinson :
> 
>> On Thu, Jun 16, 2016 at 10:21 AM, Rémy Maucherat  wrote:
>>
>>> -1, I am against fake improvements.
>>>
>>
>> Do you consider the improvement for applications that do not use HTTP
>> sessions at all to also be fake?
>>
> This does not sound very realistic or common to me.

50% of our applications deployments are cookie-less, and we deploy on
separate Tomcats running on separate JVMs. That means that we have 50%
of our Tomcat instances that will never create an instance of
javax.servlet.http.HttpSession.

If SecureRandom is only being used for HttpSession id generation, it's
not necessary to do it on startup.

> There are different products, with different behaviors, that gives
> users a choice. Tomcat's strategy avoids any risk to delay user
> requests, so is not effectively worse than the other strategy.

I disagree: Tomcat's behavior will cause time-to-first-byte after a
restart to be the same as e.g. Untertow for a request-with-a-session,
but the time-to-first-byte for Untertow will be significantly less for a
request that does not require a session.

> You're basically asking for all products to behave the same because
> it would be nicer for your own product. That's fine, but choice is
> good.

No, that's not what he's saying at all.

Lazy Random-init sounds like a good idea. It's not clear to me if there
are any particular problems with such a strategy given Tomcat's current
implementation.



signature.asc
Description: OpenPGP digital signature

Re: Using modern development tools for friendlier environment for newcomers

[Christopher Schultz]

Martin,

On 6/8/16 3:25 AM, Martin Grigorov wrote:
> On Tue, Jun 7, 2016 at 11:33 AM, Mark Thomas  wrote:
> 
>> On 07/06/2016 10:17, Martin Grigorov wrote:
>>> Hi devs,
>>>
>>> Recently a colleague of mine asked me what it takes to become an Apache
>>> committer.
>>> I've explained him that he has to choose a project that is interesting to
>>> him and start participating in the mailing lists (helping others at
>> users@,
>>> giving opinion and testing releases at dev@), providing patches for open
>>> issues, etc.
>>> Few days later he came back with the following questions:
>>>
>>> 1) Why Tomcat still uses SVN?
>>> I've told him that this is the SCM tool most of the committers have
>>> experience with and there were some discussions to move to Git several
>>> months back.
>>> I've recommended him to use GitHub's Pull Requests for the time being -
>> PRs
>>> are monitored and merged if approved. Even if Tomcat was using Git,
>> Apache
>>> Infra doesn't provide tool with Pull Request support (GitLab, Gerrit, or
>>> similar) anyway so there is no big difference from a contributor point of
>>> view.
>>
>> If I recall correctly, the consensus last time around was that there was
>> merit in exploring the options for using git further with a view to
>> migrating if the majority were convinced there was a benefit to the move.
>>
>> There is an outstanding task (I need to chase it up) for the infra team
>> to look at if we could move to a single git repo for multiple branches
>> or would need multiple repos.
>>
> 
> One repo should be possible.
> Even if there are some problems with the initial conversion from SVN to Git
> the person dealing with it could create N Git repos and then with the help
> of "git remote add" combine them into one with N branches and finally push
> those branches into a single repository.
> 
> 
>>
>>> 2) Why Tomcat uses Bugzilla?
>>> It is archaic and its UI is unfriendly - he said.
>>> To be honest I didn't have a good answer here. I also don't like
>> Bugzilla.
>>> Everybody knows how to use JIRA! It is hard to explain that Apache JIRA
>>> runs on Tomcat, but Tomcat project itself uses Perl software for issue
>>> tracking (no matter how good Bugzilla is).
>>
>> My personal view is Jira is overly complex and horribly slow. Bugzilla
>>
> 
> I think JIRA is slower because the majority of the projects are there.
> But I guess it would be an overkill for Infra to maintain several instances
> of JIRA (e.g. sharded by project name).

I think it's slower because it's a sledgehammer where a screwdriver will
do the job. I've never liked JIRA, but as was previously said "tools are
tools".

>> just works. We don't need any of the extra features Jira offers. Do we
>> want any of them? None come to mind. Others may have a different view.
>>
> 
> I personally like the JIRA plugins that integrate with the SCM tools.
> Committing with "PROJECT_NAME-1234" in the commit message automatically
> adds a comment to the respective ticket with a link to Git/SVN repo. It is
> very easy to explore the history of a ticket.

All of this can be done with svn + bugzilla, too. I guess just nobody
bothered to do it @ASF until JIRA came along.

> Also it has a proper "Fix version" field. With it it is much easier to
> create a changelog. No need to maintain one manually.

Bugzilla has a "Target Milestone", but that is disabled in Bugzilla,
probably because the list of milestones would get insanely long. Maybe
another reason that JIRA is so slow: all that metadata is actually in
there instead of having been deemed "too much" at some point in the past.

>>> I know that SVN, Git, JIRA, Bugzilla are just tools. We can do our work
>>> with any of them.
>>> Maybe there are more (and more important!) reasons why my colleague
>> didn't
>>> start contributing to Tomcat yet but I also agree with him that by moving
>>> to more modern tools Tomcat will become easier and friendlier for
>> newcomers.
>>
>> The Tomcat community tends to change development technology when it can
>> see some direct benefit from the change. It doesn't change just to use
>> the latest shiny new toy.
>>
> 
> I totally agree with "see some benefit"!
> I don't agree with "new" :-) Both Git and JIRA are on the market for quite
> some time.

The age of the toy is not really relevant. It's the relative merit to
the current toy. So far, I don't see any merit in switching to JIRA. My
recent forays into git have shown me that it can help with collaboration
from non-committers, which I think is always a good thing.

-chris



signature.asc
Description: OpenPGP digital signature

[Bug 59715] Getting ClassCircularityError on using javaagent in Catalina.bat and application is using custom SecurityManager.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59715

Violeta Georgieva  changed:

   What|Removed |Added

 OS||All

--- Comment #1 from Violeta Georgieva  ---
Hi,

(In reply to Dipankar Datta from comment #0)
> When using javaagent in catalina.bat file Tomcat is giving
> ClassCircularityError. My application is using implementation of
> SecurityManager.
> I'm  trying to integrate newrelic with my application and since after
> installing newrelic I'm  getting  this error. While installing newrelic it
> adds javaagent in catalina.bat file.
> 
> I'm working with Java 7 and Apache Tomcat 7.0.26

Tomcat 7.0.26 is pretty old (more than 4 years old).

Can you test your scenario with the most recent Tomcat 7 version (7.0.69)?

Regards,
Violeta

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 58626] Tomcat does not start at boot time due to SIGHUP

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=58626

--- Comment #26 from Christopher Schultz  ---
(In reply to Mark Thomas from comment #22)
> CATALINA_PID works as expected

I was skeptical. My quick test:

$ nohup sleep 100 &
[1] 9556

$ echo $!
9556
$ ps aux | grep sleep
chris9559   0.0  0.0  2457368880 s001  S+6:30AM   0:00.00
grep sleep
chris9556   0.0  0.0  2434824664 s001  S 6:30AM   0:00.00
sleep 100

$! returns 9556, the pid of the 'sleep' process.

I haven't looked at the code for, say, GNU nohup, but I suspect it's used often
enough in this type of situation that use of exec() is almost certainly
required to make it useful.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 59715] New: Getting ClassCircularityError on using javaagent in Catalina.bat and application is using custom SecurityManager.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59715

Bug ID: 59715
   Summary: Getting ClassCircularityError on using javaagent in
Catalina.bat and application is using custom
SecurityManager.
   Product: Tomcat 7
   Version: 7.0.26
  Hardware: PC
Status: NEW
  Severity: blocker
  Priority: P2
 Component: WebSocket
  Assignee: dev@tomcat.apache.org
  Reporter: dipankar.da...@ul.com

When using javaagent in catalina.bat file Tomcat is giving
ClassCircularityError. My application is using implementation of
SecurityManager.
I'm  trying to integrate newrelic with my application and since after
installing newrelic I'm  getting  this error. While installing newrelic it adds
javaagent in catalina.bat file.

I'm working with Java 7 and Apache Tomcat 7.0.26

Following is the stack trace.
log4j:ERROR Failed to append logging event to rolling file.
java.lang.ClassCircularityError: java/lang/String
at
net.nicholaswilliams.java.licensing.LicenseSecurityManager.checkPermission(LicenseSecurityManager.java:259)
at
java.lang.reflect.AccessibleObject.setAccessible(AccessibleObject.java:128)
at java.lang.Class$1.run(Class.java:351)
at java.lang.Class$1.run(Class.java:349)
at java.security.AccessController.doPrivileged(Native Method)
at java.lang.Class.newInstance0(Class.java:348)
at java.lang.Class.newInstance(Class.java:325)
at
sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:399)
at
sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:396)
at java.security.AccessController.doPrivileged(Native Method)
at
sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:395)
at
sun.reflect.MethodAccessorGenerator.generateMethod(MethodAccessorGenerator.java:77)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:46)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.log4j.spi.LocationInfo.(LocationInfo.java:142)
at
org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:253)
at
org.apache.log4j.helpers.PatternParser$ClassNamePatternConverter.getFullyQualifiedName(PatternParser.java:555)
at
org.apache.log4j.helpers.PatternParser$NamedPatternConverter.convert(PatternParser.java:528)
at
org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:65)
at org.apache.log4j.PatternLayout.format(PatternLayout.java:506)
at
com.puresafety.logging.OhmRollingFileAppender.append(OhmRollingFileAppender.java:238)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:197)
at
org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:247)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:510)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:486)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:740)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:455)
at
org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:1090)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:487)
at
org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
at
org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
at
org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4779)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5273)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:895)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:871)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:615)
at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1497)
at 

[Bug 59616] SSLVerifyClient="optionalNoCA" stops working between 1.1.33 and 1.2.4

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=59616

--- Comment #2 from Mark Thomas  ---
I'm seeing the issue (or something very like it) with 1.2.7 and Tomcat trunk. I
spent a little time looking at the 1.1.x code vs 1.2.x but don't see any
obvious root causes. I plan to do some more investigation today.

-- 
You are receiving this mail because:
You are the assignee for the bug.

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org