[STATUS] (geronimo) Wed Apr 4 23:46:37 2007
APACHE GERONIMO STATUS: -*-text-*- Last modified at [$Date: 2007-04-03 09:56:37 -0400 (Tue, 03 Apr 2007) $] The current version of this file can be found at: * http://svn.apache.org/repos/asf/geronimo/server/trunk/STATUS Upcoming Releases: Geronimo 2.0 -- geronimo/server/trunk/ Release Manager: Matt Hogstrom Estimated Date: Q2 2007 Geronimo 1.2 -- geronimo/server/branches/1.2 Release Manager: Dain Sundstrom and Alan Cabrera Estimated Date: early April 2007 Status: We have final releases from our dependent projects and will begin the release process for OpenEJB and Geronimo shortly. RELEASE HISTORY: 2007-03-04 Geronimo 2.0-M3 2007-01-30 Geronimo 2.0-M2 2006-12-22 Geronimo 2.0-M1 2006-12-16 Geronimo 1.2-beta 2006-09-18 Geronimo 1.1.1 2006-06-26 Geronimo 1.1 2006-01-05 Geronimo 1.0 2005-10-04 Geronimo 1.0 milestone 5 2005-08-10 Geronimo 1.0 milestone 4 2004-11-11 Geronimo 1.0 milestone 3 2004-09-09 Geronimo 1.0 milestone 2 2004-04-29 Geronimo 1.0 milestone 1 If you're a contributor looking for something to do: * Review the documentation and suggest improvements * Review the bug list and suggest fixes or report reproducibility * Report bugs yourself
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
I'm okay with that... though I still don't like having to use the config for docs... but ya, commented out bits are much better than defaulting them to FATAL of OFF. --jason On Apr 4, 2007, at 8:11 PM, Jarek Gawor wrote: I think it would be ok to add these logging statements to the configuration file but have them commented out. For example: # log4j.logger.org.apache.commons.httpclient=DEBUG That way the user will not have to search the online docs to figure out the right debug statements. Jarek On 4/4/07, Jason Dillon <[EMAIL PROTECTED]> wrote: On Apr 4, 2007, at 7:31 PM, Lin Sun wrote: > I proposed to add them in just because it took me quite a while to > figure out how to turn on debug logs for Axis2. This is needed if > anyone ever needs to debug an Axis2 prob or report an Axis2 JIRA. > I don't want others to go through the effort thus I feel it is > appropriate to have them in so that people can change to DEBUG or > TRACE whenever needed. > > It is perfectly fine if you want to have INFO or ERROR instead of > FATAL. To answer your question, I don't really see much/any output > of these loggers w/o the limits. Wiki pages are quite useful for explain these types of things to people. If there isn't already there should be a comprehensive guide on how to deal with logging in Geronimo. I don't think it is appropriate to use the actually logging configuration file as documentation... though these aren't commented out with docs, they are actually setting the levels which I think is even worse. I would recommend creating that wiki page (or updating it if one exists, I've not looked recently at what is there). And if you want, add _commented_ examples of how to enable DEBUG/ TRACE, but don't limit things that aren't insanely noisy by default. That will only leave folks scratching their heads when they expect to see the output. And I would recommend that we should never be limiting categories to FATAL or ERROR... those log messages generally indicate problems which should not be swallowed by default. --jason > Lin > > Jason Dillon wrote: >> I don't think we should be trying to taylor the logging output of >> Geronimo to match what other component communities have for their >> projects. >> I'm okay with with levels for axis, though I think FATAL is not >> the correct level to limit them at by default. In most cases I >> would expect to see INFO+ captured in log files, but when limiting >> logger levels like this they will never make it to the file appender. >> But the others, like httpclient for example. Users may be using >> Geronimo w/o any WS muck, using httpclient and expecting to see >> log messages. Limiting these logger here is a very bad idea, as >> it will leave those users wonder where the logs went and causing >> them to ping the lists asking what is going on. >> * * * >> In general I'm -1 on limiting loggers to FATAL, unless for some >> reason the component spits out a ton of ERROR messages, and >> similarly I'm -1 on limiting loggers to ERROR unless they spit out >> a ton of WARN messages. And in both cases if those libraries are >> spitting out so much junk, then we are either integrating them >> improperly or their codebase is incorrectly using logging... in >> both cases something should be fixed, we shouldn't be silently >> ignoring them. >> * * * >> What is the output of these loggers w/o the limits? >> --jason >> On Apr 4, 2007, at 1:39 PM, Donald Woods wrote: >>> The log4j.properties used by Axis2 includes those 4 values set to >>> FATAL, so I'm trying to match our log output to what the Axis2 >>> community is used to seeing and ships today. >>> >>> Also, adding these values into our file allows users to easily >>> see how to turn on debug info for a component (Axis and Axis2 in >>> this case) without having to dig through the component source or >>> pinging our user mailing list for the info. >>> >>> >>> -Donald >>> >>> Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: > Author: dwoods > Date: We
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
I think it would be ok to add these logging statements to the configuration file but have them commented out. For example: # log4j.logger.org.apache.commons.httpclient=DEBUG That way the user will not have to search the online docs to figure out the right debug statements. Jarek On 4/4/07, Jason Dillon <[EMAIL PROTECTED]> wrote: On Apr 4, 2007, at 7:31 PM, Lin Sun wrote: > I proposed to add them in just because it took me quite a while to > figure out how to turn on debug logs for Axis2. This is needed if > anyone ever needs to debug an Axis2 prob or report an Axis2 JIRA. > I don't want others to go through the effort thus I feel it is > appropriate to have them in so that people can change to DEBUG or > TRACE whenever needed. > > It is perfectly fine if you want to have INFO or ERROR instead of > FATAL. To answer your question, I don't really see much/any output > of these loggers w/o the limits. Wiki pages are quite useful for explain these types of things to people. If there isn't already there should be a comprehensive guide on how to deal with logging in Geronimo. I don't think it is appropriate to use the actually logging configuration file as documentation... though these aren't commented out with docs, they are actually setting the levels which I think is even worse. I would recommend creating that wiki page (or updating it if one exists, I've not looked recently at what is there). And if you want, add _commented_ examples of how to enable DEBUG/ TRACE, but don't limit things that aren't insanely noisy by default. That will only leave folks scratching their heads when they expect to see the output. And I would recommend that we should never be limiting categories to FATAL or ERROR... those log messages generally indicate problems which should not be swallowed by default. --jason > Lin > > Jason Dillon wrote: >> I don't think we should be trying to taylor the logging output of >> Geronimo to match what other component communities have for their >> projects. >> I'm okay with with levels for axis, though I think FATAL is not >> the correct level to limit them at by default. In most cases I >> would expect to see INFO+ captured in log files, but when limiting >> logger levels like this they will never make it to the file appender. >> But the others, like httpclient for example. Users may be using >> Geronimo w/o any WS muck, using httpclient and expecting to see >> log messages. Limiting these logger here is a very bad idea, as >> it will leave those users wonder where the logs went and causing >> them to ping the lists asking what is going on. >> * * * >> In general I'm -1 on limiting loggers to FATAL, unless for some >> reason the component spits out a ton of ERROR messages, and >> similarly I'm -1 on limiting loggers to ERROR unless they spit out >> a ton of WARN messages. And in both cases if those libraries are >> spitting out so much junk, then we are either integrating them >> improperly or their codebase is incorrectly using logging... in >> both cases something should be fixed, we shouldn't be silently >> ignoring them. >> * * * >> What is the output of these loggers w/o the limits? >> --jason >> On Apr 4, 2007, at 1:39 PM, Donald Woods wrote: >>> The log4j.properties used by Axis2 includes those 4 values set to >>> FATAL, so I'm trying to match our log output to what the Axis2 >>> community is used to seeing and ships today. >>> >>> Also, adding these values into our file allows users to easily >>> see how to turn on debug info for a component (Axis and Axis2 in >>> this case) without having to dig through the component source or >>> pinging our user mailing list for the info. >>> >>> >>> -Donald >>> >>> Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: > Author: dwoods > Date: Wed Apr 4 13:05:30 2007 > New Revision: 525594 > > URL: http://svn.apache.org/viewvc?view=rev&rev=525594 > Log: > GERONIMO-3064 Add axis2 log4j configure properties so that > people can turn on axis2 logs in ge
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
On Apr 4, 2007, at 7:31 PM, Lin Sun wrote: I proposed to add them in just because it took me quite a while to figure out how to turn on debug logs for Axis2. This is needed if anyone ever needs to debug an Axis2 prob or report an Axis2 JIRA. I don't want others to go through the effort thus I feel it is appropriate to have them in so that people can change to DEBUG or TRACE whenever needed. It is perfectly fine if you want to have INFO or ERROR instead of FATAL. To answer your question, I don't really see much/any output of these loggers w/o the limits. Wiki pages are quite useful for explain these types of things to people. If there isn't already there should be a comprehensive guide on how to deal with logging in Geronimo. I don't think it is appropriate to use the actually logging configuration file as documentation... though these aren't commented out with docs, they are actually setting the levels which I think is even worse. I would recommend creating that wiki page (or updating it if one exists, I've not looked recently at what is there). And if you want, add _commented_ examples of how to enable DEBUG/ TRACE, but don't limit things that aren't insanely noisy by default. That will only leave folks scratching their heads when they expect to see the output. And I would recommend that we should never be limiting categories to FATAL or ERROR... those log messages generally indicate problems which should not be swallowed by default. --jason Lin Jason Dillon wrote: I don't think we should be trying to taylor the logging output of Geronimo to match what other component communities have for their projects. I'm okay with with levels for axis, though I think FATAL is not the correct level to limit them at by default. In most cases I would expect to see INFO+ captured in log files, but when limiting logger levels like this they will never make it to the file appender. But the others, like httpclient for example. Users may be using Geronimo w/o any WS muck, using httpclient and expecting to see log messages. Limiting these logger here is a very bad idea, as it will leave those users wonder where the logs went and causing them to ping the lists asking what is going on. * * * In general I'm -1 on limiting loggers to FATAL, unless for some reason the component spits out a ton of ERROR messages, and similarly I'm -1 on limiting loggers to ERROR unless they spit out a ton of WARN messages. And in both cases if those libraries are spitting out so much junk, then we are either integrating them improperly or their codebase is incorrectly using logging... in both cases something should be fixed, we shouldn't be silently ignoring them. * * * What is the output of these loggers w/o the limits? --jason On Apr 4, 2007, at 1:39 PM, Donald Woods wrote: The log4j.properties used by Axis2 includes those 4 values set to FATAL, so I'm trying to match our log output to what the Axis2 community is used to seeing and ships today. Also, adding these values into our file allows users to easily see how to turn on debug info for a component (Axis and Axis2 in this case) without having to dig through the component source or pinging our user mailing list for the info. -Donald Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Wed Apr 4 13:05:30 2007 New Revision: 525594 URL: http://svn.apache.org/viewvc?view=rev&rev=525594 Log: GERONIMO-3064 Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo. Thanks Lin. I also added the Axis v1 log categories. Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate- minimal/src/main/resources/var/log/server-log4j.properties Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate- minimal/src/main/resources/var/log/server-log4j.properties URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ assemblies/geronimo-boilerplate-minimal/src/main/resources/var/ log/server-log4j.properties? view=diff&rev=525594&r1=5255
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
I proposed to add them in just because it took me quite a while to figure out how to turn on debug logs for Axis2. This is needed if anyone ever needs to debug an Axis2 prob or report an Axis2 JIRA. I don't want others to go through the effort thus I feel it is appropriate to have them in so that people can change to DEBUG or TRACE whenever needed. It is perfectly fine if you want to have INFO or ERROR instead of FATAL. To answer your question, I don't really see much/any output of these loggers w/o the limits. Lin Jason Dillon wrote: I don't think we should be trying to taylor the logging output of Geronimo to match what other component communities have for their projects. I'm okay with with levels for axis, though I think FATAL is not the correct level to limit them at by default. In most cases I would expect to see INFO+ captured in log files, but when limiting logger levels like this they will never make it to the file appender. But the others, like httpclient for example. Users may be using Geronimo w/o any WS muck, using httpclient and expecting to see log messages. Limiting these logger here is a very bad idea, as it will leave those users wonder where the logs went and causing them to ping the lists asking what is going on. * * * In general I'm -1 on limiting loggers to FATAL, unless for some reason the component spits out a ton of ERROR messages, and similarly I'm -1 on limiting loggers to ERROR unless they spit out a ton of WARN messages. And in both cases if those libraries are spitting out so much junk, then we are either integrating them improperly or their codebase is incorrectly using logging... in both cases something should be fixed, we shouldn't be silently ignoring them. * * * What is the output of these loggers w/o the limits? --jason On Apr 4, 2007, at 1:39 PM, Donald Woods wrote: The log4j.properties used by Axis2 includes those 4 values set to FATAL, so I'm trying to match our log output to what the Axis2 community is used to seeing and ships today. Also, adding these values into our file allows users to easily see how to turn on debug info for a component (Axis and Axis2 in this case) without having to dig through the component source or pinging our user mailing list for the info. -Donald Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Wed Apr 4 13:05:30 2007 New Revision: 525594 URL: http://svn.apache.org/viewvc?view=rev&rev=525594 Log: GERONIMO-3064 Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo. Thanks Lin. I also added the Axis v1 log categories. Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties?view=diff&rev=525594&r1=525593&r2=525594 == --- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties (original) +++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties Wed Apr 4 13:05:30 2007 @@ -115,10 +115,22 @@ # Prints various stuff during startup log4j.logger.org.apache.juddi.registry.RegistryServlet=WARN - # Prints various stuff when the portal is used log4j.logger.org.apache.pluto.portalImpl.Servlet=WARN + # Prints stuff for AJAX calls log4j.logger.uk.ltd.getahead.dwr.impl.DefaultConfiguration=WARN log4j.logger.uk.ltd.getahead.dwr.impl.ExecuteQuery=WARN log4j.logger.uk.ltd.getahead.dwr.util.Logger=WARN + +# Axis log output +log4j.logger.org.apache.axis.enterprise=FATAL +log4j.logger.org.apache.axis.TIME=OFF +log4j.logger.org.apache.axis.EXCEPTIONS=FATAL + +# Axis2 log output +log4j.logger.org.apache.axis2.enterprise
Re: [vote] Release openejb-2.3-incubating
This does address my concerns, though while we should still not use
pinned snapshots in a release, having this repo available will allow
the tree to have a higher chance of being build-able in the future.
I think we should probably considering making this a standard of
sorts when making a release, to include the dependency artifacts in a
tar.bz2 along with the *-src.* bits. As long as we don't include the
artifacts we are building then the size should be relatively small...
and thats a small price to pay for having a tree build build-able in
the future.
I think we really need to hold on to the artifacts in the dist tree
just like we do for the src, because with out one or the other, your
chances of having a successful build are going to vary widely.
I think that we should think this over and then consider making this
a policy, at least for now until we have a better story on the
longevity of our m2 builds.
--jason
On Apr 4, 2007, at 5:45 PM, Dain Sundstrom wrote:
Jason and I chatted on irc and decided there isn't much we can do
about these, or the fact that the repos aren't as reliable as we'd
like. To address this, I have saved off the repository used to
create the release here:
http://people.apache.org/~dain/dist/geronimo-1.2-build-
repository.tar.bz
This way we will *always* have everything maven needs to rebuild
the server from source.
-dain
On Apr 4, 2007, at 5:10 PM, Jason Dillon wrote:
Copying g list because the same problem is relevant to the g 1.2
release.
This is still using some artifacts which are only in snapshot
repositories:
* xmlbeans-maven-plugin 2.0.1-20060627.031204-7
* maven-deploy-plugin 2.3-20061210.174233-3
* maven-gpg-plugin 1.0-alpha-2-20061214.035657-1
While the version does not have SNAPSHOT in it... don't let that
trick you into thinking these are not SNAPSHOTS, because they
are. While the release plugin will let you roll something out
like this, use of these pinned snapshots will limit the build-
ability of this tree in the future.
While there is no real guarantee that any artifact in any repo
(snap or not) will really be around in the future (short or long
term), there is a high possibility that artifacts in a snap repo
will not be around for very long. And even when using a pinned
snapshot the fact still remains that the storage of that artifact
is transient and will almost certainly not be available at some
time in the future, which will cause this tree (and the G 1.2
tree) to be unbuildable w/o source changes.
The main problem here is the xmlbeans-maven-plugin
2.0.1-20060627.031204-7, which affects the G 1.2 build as well.
The others are for release support and are in a profile which is
not enabled by default.
* * *
I mention this not to derail the release... because I really want
this to get out so we can get G 1.2 out. But we would really be
in a much better position to support the ongoing build-ability of
this tree if we did not have *any* artifacts which are required to
build that are only available in a transient snapshot repository.
If its a pain to get a release release from the mojo folks working
on the xmlbeans-maven-plugin, then we need to add these artifacts
(and any snaps which it may be depending on, I didn't look), into
a local repository that is checked into svn, just like G does (ie.
http://svn.apache.org/repos/asf/geronimo/server/branches/1.2/
repository/ ).
--jason
On Apr 4, 2007, at 4:52 PM, Dain Sundstrom wrote:
All,
The release is cut and awaiting your vote! All the files are
available in a staging area in my home dir on people.
http://people.apache.org/~dain/stage/org/apache/openejb/
itests-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
modules-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-axis-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-corba-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-corba-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-core-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-itests-core-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-pkgen-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-yoko-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
All jars contain DISCLAIMER, LICENSE, and NOTICE. Each binary
jar is also accompanied by source, javadoc, pom and all are
signed, md5-ed, and secure-hashed. Keys file available here:
http://people.apache.org/repo/m2-incubating-repository/org/
apache/openejb/KEYS
Svn tag is here:
http://svn.apache.org/repos/asf/incubator/openejb/tags/
openejb-2.3/
Here's my +1!
-dain
Re: [vote] Release openejb-2.3-incubating
Jason and I chatted on irc and decided there isn't much we can do
about these, or the fact that the repos aren't as reliable as we'd
like. To address this, I have saved off the repository used to
create the release here:
http://people.apache.org/~dain/dist/geronimo-1.2-build-
repository.tar.bz
This way we will *always* have everything maven needs to rebuild the
server from source.
-dain
On Apr 4, 2007, at 5:10 PM, Jason Dillon wrote:
Copying g list because the same problem is relevant to the g 1.2
release.
This is still using some artifacts which are only in snapshot
repositories:
* xmlbeans-maven-plugin 2.0.1-20060627.031204-7
* maven-deploy-plugin 2.3-20061210.174233-3
* maven-gpg-plugin 1.0-alpha-2-20061214.035657-1
While the version does not have SNAPSHOT in it... don't let that
trick you into thinking these are not SNAPSHOTS, because they are.
While the release plugin will let you roll something out like this,
use of these pinned snapshots will limit the build-ability of this
tree in the future.
While there is no real guarantee that any artifact in any repo
(snap or not) will really be around in the future (short or long
term), there is a high possibility that artifacts in a snap repo
will not be around for very long. And even when using a pinned
snapshot the fact still remains that the storage of that artifact
is transient and will almost certainly not be available at some
time in the future, which will cause this tree (and the G 1.2 tree)
to be unbuildable w/o source changes.
The main problem here is the xmlbeans-maven-plugin
2.0.1-20060627.031204-7, which affects the G 1.2 build as well.
The others are for release support and are in a profile which is
not enabled by default.
* * *
I mention this not to derail the release... because I really want
this to get out so we can get G 1.2 out. But we would really be in
a much better position to support the ongoing build-ability of this
tree if we did not have *any* artifacts which are required to build
that are only available in a transient snapshot repository.
If its a pain to get a release release from the mojo folks working
on the xmlbeans-maven-plugin, then we need to add these artifacts
(and any snaps which it may be depending on, I didn't look), into a
local repository that is checked into svn, just like G does (ie.
http://svn.apache.org/repos/asf/geronimo/server/branches/1.2/
repository/ ).
--jason
On Apr 4, 2007, at 4:52 PM, Dain Sundstrom wrote:
All,
The release is cut and awaiting your vote! All the files are
available in a staging area in my home dir on people.
http://people.apache.org/~dain/stage/org/apache/openejb/
itests-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
modules-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-axis-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-corba-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-corba-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-core-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-itests-core-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-pkgen-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-yoko-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
All jars contain DISCLAIMER, LICENSE, and NOTICE. Each binary jar
is also accompanied by source, javadoc, pom and all are signed,
md5-ed, and secure-hashed. Keys file available here:
http://people.apache.org/repo/m2-incubating-repository/org/
apache/openejb/KEYS
Svn tag is here:
http://svn.apache.org/repos/asf/incubator/openejb/tags/
openejb-2.3/
Here's my +1!
-dain
Re: svn commit: r525641 - in /geronimo/server/tags: 1.2.0/ 1.2/
On Apr 4, 2007, at 5:05 PM, Dain Sundstrom wrote:
On Apr 4, 2007, at 4:52 PM, Jason Dillon wrote:
Hey, just curious... did you use the release plugin to make this
stuff, or did you have to roll it by hand?
I had to do it by hand. Last time I talked to Jason Van Zyl about
this, he said it won't work with Geronimo due to our use of
properties for version numbers.
We need to get that fixed... we can't use ${pom.version} because it
causes massive problems with deploying snapshots... but the release
muck can't handle any other property.
I'll see if I can track down and get this crap fixed.
--jason
Re: [vote] Release openejb-2.3-incubating
Copying g list because the same problem is relevant to the g 1.2
release.
This is still using some artifacts which are only in snapshot
repositories:
* xmlbeans-maven-plugin 2.0.1-20060627.031204-7
* maven-deploy-plugin 2.3-20061210.174233-3
* maven-gpg-plugin 1.0-alpha-2-20061214.035657-1
While the version does not have SNAPSHOT in it... don't let that
trick you into thinking these are not SNAPSHOTS, because they are.
While the release plugin will let you roll something out like this,
use of these pinned snapshots will limit the build-ability of this
tree in the future.
While there is no real guarantee that any artifact in any repo (snap
or not) will really be around in the future (short or long term),
there is a high possibility that artifacts in a snap repo will not be
around for very long. And even when using a pinned snapshot the fact
still remains that the storage of that artifact is transient and will
almost certainly not be available at some time in the future, which
will cause this tree (and the G 1.2 tree) to be unbuildable w/o
source changes.
The main problem here is the xmlbeans-maven-plugin
2.0.1-20060627.031204-7, which affects the G 1.2 build as well. The
others are for release support and are in a profile which is not
enabled by default.
* * *
I mention this not to derail the release... because I really want
this to get out so we can get G 1.2 out. But we would really be in a
much better position to support the ongoing build-ability of this
tree if we did not have *any* artifacts which are required to build
that are only available in a transient snapshot repository.
If its a pain to get a release release from the mojo folks working on
the xmlbeans-maven-plugin, then we need to add these artifacts (and
any snaps which it may be depending on, I didn't look), into a local
repository that is checked into svn, just like G does (ie. http://
svn.apache.org/repos/asf/geronimo/server/branches/1.2/repository/ ).
--jason
On Apr 4, 2007, at 4:52 PM, Dain Sundstrom wrote:
All,
The release is cut and awaiting your vote! All the files are
available in a staging area in my home dir on people.
http://people.apache.org/~dain/stage/org/apache/openejb/
itests-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
modules-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-axis-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-corba-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-corba-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-core-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
openejb-itests-core-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-pkgen-builder-2.3-incubating (jar,source,javadoc,pom)
{asc,md4,sha1}
openejb-yoko-2.3-incubating (jar,source,javadoc,pom){asc,md4,sha1}
All jars contain DISCLAIMER, LICENSE, and NOTICE. Each binary jar
is also accompanied by source, javadoc, pom and all are signed, md5-
ed, and secure-hashed. Keys file available here:
http://people.apache.org/repo/m2-incubating-repository/org/
apache/openejb/KEYS
Svn tag is here:
http://svn.apache.org/repos/asf/incubator/openejb/tags/openejb-2.3/
Here's my +1!
-dain
Re: svn commit: r525641 - in /geronimo/server/tags: 1.2.0/ 1.2/
On Apr 4, 2007, at 4:52 PM, Jason Dillon wrote: Hey, just curious... did you use the release plugin to make this stuff, or did you have to roll it by hand? I had to do it by hand. Last time I talked to Jason Van Zyl about this, he said it won't work with Geronimo due to our use of properties for version numbers. One problem with hand rolling is that it won't get the bits updated as would happen using the release plugin. I think its fine for now, but I hope we can figure out how to use the std tools for 2.0 and newer releases. Should be possible, but I think we will have to dance around a few problems with Maven to make it happen. Me 2. It is a real PITA to release this stuff by hand. -dain
[vote] Release Geronimo 1.2
The 1.2 release cut and awaiting your vote! All the files are available in a staging area in my home dir on people. http://people.apache.org/~dain/dist geronimo-1.2-src geronimo-framework-1.2 geronimo-jetty-minimal-1.2 geronimo-tomcat-minimal-1.2 geronimo-jetty-j2ee-1.2 geronimo-tomcat-j2ee-1.2 Additionally the maven repository with all of the modules, configs, assemblies, etc. is here: http://people.apache.org/~dain/stage/org/apache/geronimo All archives contain LICENSE and NOTICE. Each binary jar is also accompanied by source, javadoc, pom and all are signed, md5-ed, and secure-hashed. Keys file available here: http://people.apache.org/dist/geronimo/KEYS Svn tag is here: http://svn.apache.org/repos/asf/geronimo/server/tags/1.2 Here's my +1! -dain
Re: svn commit: r524928 - /geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml
I don't think this is a good idea, and including client-security is
IMO a mistake. I'm surprised the server will start with it included.
What happens if you use
org.apache.geronimo.configs
axis2
car
classes
?
On Apr 2, 2007, at 2:33 PM, [EMAIL PROTECTED] wrote:
Author: dims
Date: Mon Apr 2 14:33:53 2007
New Revision: 524928
URL: http://svn.apache.org/viewvc?view=rev&rev=524928
Log:
let's try enumerating the jars instead of using the car
Modified:
geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml
Modified: geronimo/server/trunk/configs/axis2-deployer/src/plan/
plan.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/configs/
axis2-deployer/src/plan/plan.xml?
view=diff&rev=524928&r1=524927&r2=524928
==
--- geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml
(original)
+++ geronimo/server/trunk/configs/axis2-deployer/src/plan/plan.xml
Mon Apr 2 14:33:53 2007
@@ -58,8 +58,100 @@
http://geronimo.apache.org/xml/ns/
deployment-${geronimoSchemaVersion}">
+org.apache.geronimo.modulesgroupId>
+geronimo-axis2
+
+
+org.apache.geronimo.modulesgroupId>
+geronimo-j2ee-schema
+
+
+org.apache.axis2
+axis2-java2wsdl
+
+
+org.apache.axis2
+axis2-kernel
+
+
+org.apache.axis2
+axis2-adb
+
+
+org.apache.axis2
+axis2-jaxws
+
+
+org.apache.axis2
+axis2-saaj
+
+
+org.apache.axis2
+axis2-metadata
+
+
+org.apache.ws.commons.axiomgroupId>
+axiom-api
+
+
+org.apache.ws.commons.axiomgroupId>
+axiom-dom
+
+
+org.apache.ws.commons.axiomgroupId>
+axiom-impl
+
+
+org.apache.ws.commons
+XmlSchema
+
+
+org.apache.neethi
+neethi
+
+
+commons-logging
+commons-logging
+
+
+commons-httpclient
+commons-httpclient
+
+
+commons-codec
+commons-codec
+
+
+org.apache.geronimo.javamailgroupId>
+geronimo-javamail_1.4_mailartifactId>
+
+
+org.apache.geronimo.specs
+geronimo-activation_1.1_specartifactId>
+
+
+xalan
+xalan
+
+
+xmlbeans
+xbean
+
+
+jaxen
+jaxen
+
+
+annogen
+annogen
+
+
+xml-resolver
+xml-resolver
+
+
org.apache.geronimo.configsgroupId>
-axis2
+client-security
car
Re: svn commit: r525641 - in /geronimo/server/tags: 1.2.0/ 1.2/
Hey, just curious... did you use the release plugin to make this stuff, or did you have to roll it by hand? One problem with hand rolling is that it won't get the bits updated as would happen using the release plugin. I think its fine for now, but I hope we can figure out how to use the std tools for 2.0 and newer releases. Should be possible, but I think we will have to dance around a few problems with Maven to make it happen. --jason On Apr 4, 2007, at 4:42 PM, [EMAIL PROTECTED] wrote: Author: dain Date: Wed Apr 4 16:42:48 2007 New Revision: 525641 URL: http://svn.apache.org/viewvc?view=rev&rev=525641 Log: rename tag to match version number Added: geronimo/server/tags/1.2/ - copied from r525418, geronimo/server/tags/1.2.0/ Removed: geronimo/server/tags/1.2.0/
Re: Openejb should allow configuration of port used by AdminDaemon
--- David Blevins <[EMAIL PROTECTED]> wrote:
> On Apr 1, 2007, at 5:43 AM, Anita Kulshreshtha wrote:
>
> You can configure it by adding the property "admin.port=" to
>
> the o.a.o.loader.SystemInstance or to the system properties.
>
> This particular protocol shouldn't be enabled though and should
> instead be disabled, "admin.disabled=true" via the same approach.
Thanks David! I modified OpenEjbSystemGBean to set
admin.disabled=true. Neither
System.setProperty("admin.disabled", "true"); nor
systemInstance.setProperty("admin.disabled", "true");
worked correctly, i.e. the port was still being used.. It appears
that the property is being set too late. Am I missing something?
I was able to use GERONIMO_OPTS to set this property, and run
multiple instances of geronimo using bin\startup. If possible I would
like to avoid adding yet another param to GERONIMO_OPTS.
Thanks
Anita
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
[jira] Updated: (GERONIMO-3010) Proposal for tomcat to change managed object construction/annotation processing
[ https://issues.apache.org/jira/browse/GERONIMO-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated GERONIMO-3010: --- Attachment: GERONIMO-3010-3.patch New patch for tomcat/jasper. This one might be ready for the tomcat folks to look at. - uses "InstanceManager" instead of "LifecycleProvider", thanks dblevins for the improved name - implements xml overrides of annotations per suggestion of Remy - postConstruct and preDestroy annotated methods are called for all superclasses as well as actual class per spec - Jasper does not use the catalina InstanceManager, it has it's own interface. This means tomcat includes a jasper class (for the tomcat implementations of InstanceManager) but that jasper includes no catalina classes, and avoids any classes in a non-tomcat package (org.apache) Also includes a new servlet example EnvEntryExample which crudely demonstrates that the env entry annotations work and that xml override works. Put in svn rev 525637. Here is the svn status to help with svn add rm for this patch: M java/org/apache/jasper/JspCompilationContext.java M java/org/apache/jasper/runtime/TagHandlerPool.java D java/org/apache/jasper/runtime/AnnotationHelper.java M java/org/apache/jasper/servlet/JspServletWrapper.java A java/org/apache/jasper/instanceManagement A java/org/apache/jasper/instanceManagement/InstanceManager.java A java/org/apache/jasper/instanceManagement/DefaultInstanceManager.java A java/org/apache/jasper/instanceManagement/InstanceManagerFactory.java M java/org/apache/jasper/compiler/Generator.java M java/org/apache/catalina/core/ApplicationFilterConfig.java M java/org/apache/catalina/core/StandardWrapper.java M java/org/apache/catalina/core/StandardContext.java M java/org/apache/catalina/core/LocalStrings.properties M java/org/apache/catalina/core/mbeans-descriptors.xml A java/org/apache/catalina/deploy/Injectable.java M java/org/apache/catalina/deploy/ContextEnvironment.java M java/org/apache/catalina/deploy/ResourceBase.java M java/org/apache/catalina/deploy/MessageDestinationRef.java A java/org/apache/catalina/instanceManagement A java/org/apache/catalina/instanceManagement/InstanceManager.java A java/org/apache/catalina/instanceManagement/AbstractInstanceManager.java A java/org/apache/catalina/instanceManagement/DefaultInstanceManager.java A java/org/apache/catalina/instanceManagement/InjectionTarget.java A java/org/apache/catalina/instanceManagement/InstanceManagerToAnnotationProcessorAdapter.java M java/org/apache/catalina/startup/WebRuleSet.java D java/org/apache/catalina/util/DefaultAnnotationProcessor.java X native/connector M build.xml M webapps/examples/WEB-INF/web.xml M webapps/examples/WEB-INF/classes/LocalStrings.properties A webapps/examples/WEB-INF/classes/EnvEntryExample.java > Proposal for tomcat to change managed object construction/annotation > processing > --- > > Key: GERONIMO-3010 > URL: https://issues.apache.org/jira/browse/GERONIMO-3010 > Project: Geronimo > Issue Type: Wish > Security Level: public(Regular issues) > Components: Tomcat >Affects Versions: 2.0-M4 >Reporter: David Jencks > Assigned To: David Jencks > Attachments: GERONIMO-3010-1.patch, GERONIMO-3010-2.patch, > GERONIMO-3010-3.patch, GERONIMO-3010-GERONIMO-1.patch > > > I've been working on changing how tomcat might create and destroy "managed > objects" (servlets, filters, listeners, and tags) and want a place to attach > the work in progress so it is more visible. I'm not quite ready to propose > it to the tomcat community thus this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
NoCurrentMessageOnTopicFault error
Hi, I am getting the NoCurrentMessageOnTopicFault fault on getCurrentMessage when infact I have published on and subscibed to this topic successfuly. Please help. Below are the details: Publish Msg: http://www.w3.org/2003/05/soap-envelope";> http://docs.oasis-open.org/wsn/b-2"; xmlns:wsa="http://www.w3.org/2005/08/addressing";> http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple";> myTopic world --- Subscribe Msg: http://www.w3.org/2003/05/soap-envelope";> http://docs.oasis-open.org/wsn/b-2"; xmlns:wsa="http://www.w3.org/2005/08/addressing";> http://www.consumer.org/service/endpoint http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple";> myTopic GetCurrentMessage Msg: http://www.w3.org/2003/05/soap-envelope";> http://docs.oasis-open.org/wsn/b-2"; xmlns:wsa="http://www.w3.org/2005/08/addressing";> http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple";> npex:myTopic -- Response: STATUS: 500 Error 500 HTTP ERROR: 500org.apache.servicemix.wsn.jaxws.NoCurrentMessageOnTopicFault: There is no current message on this topic. RequestURI=/Broker/Caused by:java.lang.Exception: org.apache.servicemix.wsn.jaxws.NoCurrentMessageOnTopicFault: There is no current message on this topic. at org.apache.servicemix.http.processors.ConsumerProcessor.process(ConsumerProcessor.java:214) at org.apache.servicemix.http.HttpBridgeServlet.doPost(HttpBridgeServlet.java:71) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:356) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) at org.mortbay.jetty.Server.handle(Server.java:269) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:333) at org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) Caused by: org.apache.servicemix.wsn.jaxws.NoCurrentMessageOnTopicFault: There is no current message on this topic. at org.apache.servicemix.wsn.AbstractNotificationBroker.getCurrentMessage(AbstractNotificationBroker.java:212) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.servicemix.wsn.component.WSNEndpoint.process(WSNEndpoint.java:137) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:489) at org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:441) at org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:46) at org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:593) at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:174) at org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:176) at org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690) at java.lang.Thread.run(Thread.java:619) Caused by:org.apache.servicemix.wsn.jaxws.NoCurrentMessageOnTopicFault: There is no current message on this topic. at org.apache.servicemix.wsn.AbstractNotificationBroker.getCurrentMessage(AbstractNotificationBroker.java:212) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.servicemix.wsn.component.WSNEndpoint.process(WSNEndpoint.java:137) at org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(
Persistence Unit view in JMX console
Hello all, If anyone would like to take a look, I've attached a patch to Jira 3060 that adds a separate branch to the tree that holds only the persistence units. It's the first step to getting easy access to information about loaded persistence units, but it's self contained would make a nice start (at least I think it would). Jay
[BUILD] TRUNK: Failed for Revision: 525620
Building with Maven version: 2.0.5 Revision: 525620 built with tests skipped See the full build-1800.log file at http://people.apache.org/~prasad/binaries/20070404/build-1800.log 201K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-common-schemas/2.0-incubator-RC-SNAPSHOT/cxf-common-schemas-2.0-incubator-RC-20070404.210355-31.jar 44K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-databinding-jaxb/2.0-incubator-RC-SNAPSHOT/cxf-rt-databinding-jaxb-2.0-incubator-RC-20070404.210355-21.jar 45K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/springframework/spring-core/2.0/spring-core-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-core:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/springframework/spring-core/2.0/spring-core-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-core:jar:2.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repo1.maven.org/maven2/org/springframework/spring-core/2.0/spring-core-2.0.jar 165K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-core/2.0-incubator-RC-SNAPSHOT/cxf-rt-core-2.0-incubator-RC-20070404.210355-27.jar 222K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/apache/geronimo/specs/geronimo-javamail_1.4_spec/1.0-M1/geronimo-javamail_1.4_spec-1.0-M1.jar [WARNING] Unable to get resource 'org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.0-M1' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/apache/geronimo/specs/geronimo-javamail_1.4_spec/1.0-M1/geronimo-javamail_1.4_spec-1.0-M1.jar [WARNING] Unable to get resource 'org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.0-M1' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-javamail_1.4_spec/1.0-M1/geronimo-javamail_1.4_spec-1.0-M1.jar 189K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-tools-common/2.0-incubator-RC-SNAPSHOT/cxf-tools-common-2.0-incubator-RC-20070404.210355-26.jar 166K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-frontend-simple/2.0-incubator-RC-SNAPSHOT/cxf-rt-frontend-simple-2.0-incubator-RC-20070404.210355-21.jar 36K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/springframework/spring-aop/2.0/spring-aop-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-aop:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/springframework/spring-aop/2.0/spring-aop-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-aop:jar:2.0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repo1.maven.org/maven2/org/springframework/spring-aop/2.0/spring-aop-2.0.jar 278K downloaded Downloading: http://people.apache.org/repo/m2-snapshot-repository/org/apache/cxf/cxf-rt-frontend-jaxws/2.0-incubator-RC-SNAPSHOT/cxf-rt-frontend-jaxws-2.0-incubator-RC-20070404.210355-21.jar 191K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/mortbay/jetty/servlet-api-2.5/6.1.2rc0/servlet-api-2.5-6.1.2rc0.jar [WARNING] Unable to get resource 'org.mortbay.jetty:servlet-api-2.5:jar:6.1.2rc0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/mortbay/jetty/servlet-api-2.5/6.1.2rc0/servlet-api-2.5-6.1.2rc0.jar [WARNING] Unable to get resource 'org.mortbay.jetty:servlet-api-2.5:jar:6.1.2rc0' from repository apache-incubator (http://people.apache.org/repo/m2-incubating-repository/) Downloading: http://repo1.maven.org/maven2/org/mortbay/jetty/servlet-api-2.5/6.1.2rc0/servlet-api-2.5-6.1.2rc0.jar 128K downloaded Downloading: http://tomcat.apache.org/dev/dist/m2-repository/org/springframework/spring-beans/2.0/spring-beans-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-beans:jar:2.0' from repository tomcat-m2-repo (http://tomcat.apache.org/dev/dist/m2-repository) Downloading: http://people.apache.org/repo/m2-incubating-repository//org/springframework/spring-beans/2.0/spring-beans-2.0.jar [WARNING] Unable to get resource 'org.springframework:spring-beans:jar:2.0' from repository apache-incub
[jira] Commented: (GERONIMO-3022) @PersistenceContext annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486781 ] David Jencks commented on GERONIMO-3022: Applied in rev 525609. What a great set of tests! thanks! > @PersistenceContext annotation support > -- > > Key: GERONIMO-3022 > URL: https://issues.apache.org/jira/browse/GERONIMO-3022 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Attachments: GERONIMO-3022.patch, GERONIMO-3022.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
I don't think we should be trying to taylor the logging output of Geronimo to match what other component communities have for their projects. I'm okay with with levels for axis, though I think FATAL is not the correct level to limit them at by default. In most cases I would expect to see INFO+ captured in log files, but when limiting logger levels like this they will never make it to the file appender. But the others, like httpclient for example. Users may be using Geronimo w/o any WS muck, using httpclient and expecting to see log messages. Limiting these logger here is a very bad idea, as it will leave those users wonder where the logs went and causing them to ping the lists asking what is going on. * * * In general I'm -1 on limiting loggers to FATAL, unless for some reason the component spits out a ton of ERROR messages, and similarly I'm -1 on limiting loggers to ERROR unless they spit out a ton of WARN messages. And in both cases if those libraries are spitting out so much junk, then we are either integrating them improperly or their codebase is incorrectly using logging... in both cases something should be fixed, we shouldn't be silently ignoring them. * * * What is the output of these loggers w/o the limits? --jason On Apr 4, 2007, at 1:39 PM, Donald Woods wrote: The log4j.properties used by Axis2 includes those 4 values set to FATAL, so I'm trying to match our log output to what the Axis2 community is used to seeing and ships today. Also, adding these values into our file allows users to easily see how to turn on debug info for a component (Axis and Axis2 in this case) without having to dig through the component source or pinging our user mailing list for the info. -Donald Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Wed Apr 4 13:05:30 2007 New Revision: 525594 URL: http://svn.apache.org/viewvc?view=rev&rev=525594 Log: GERONIMO-3064 Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo. Thanks Lin. I also added the Axis v1 log categories. Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate- minimal/src/main/resources/var/log/server-log4j.properties URL: http://svn.apache.org/viewvc/geronimo/server/trunk/ assemblies/geronimo-boilerplate-minimal/src/main/resources/var/ log/server-log4j.properties?view=diff&rev=525594&r1=525593&r2=525594 == --- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties (original) +++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties Wed Apr 4 13:05:30 2007 @@ -115,10 +115,22 @@ # Prints various stuff during startup log4j.logger.org.apache.juddi.registry.RegistryServlet=WARN - # Prints various stuff when the portal is used log4j.logger.org.apache.pluto.portalImpl.Servlet=WARN + # Prints stuff for AJAX calls log4j.logger.uk.ltd.getahead.dwr.impl.DefaultConfiguration=WARN log4j.logger.uk.ltd.getahead.dwr.impl.ExecuteQuery=WARN log4j.logger.uk.ltd.getahead.dwr.util.Logger=WARN + +# Axis log output +log4j.logger.org.apache.axis.enterprise=FATAL +log4j.logger.org.apache.axis.TIME=OFF +log4j.logger.org.apache.axis.EXCEPTIONS=FATAL + +# Axis2 log output +log4j.logger.org.apache.axis2.enterprise=FATAL +log4j.logger.de.hunsicker.jalopy.io=FATAL +log4j.logger.httpclient.wire.header=FATAL +log4j.logger.org.apache.commons.httpclient=FATAL +
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
The log4j.properties used by Axis2 includes those 4 values set to FATAL, so I'm trying to match our log output to what the Axis2 community is used to seeing and ships today. Also, adding these values into our file allows users to easily see how to turn on debug info for a component (Axis and Axis2 in this case) without having to dig through the component source or pinging our user mailing list for the info. -Donald Jason Dillon wrote: Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or -vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or -vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Wed Apr 4 13:05:30 2007 New Revision: 525594 URL: http://svn.apache.org/viewvc?view=rev&rev=525594 Log: GERONIMO-3064 Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo. Thanks Lin. I also added the Axis v1 log categories. Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties?view=diff&rev=525594&r1=525593&r2=525594 == --- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties (original) +++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties Wed Apr 4 13:05:30 2007 @@ -115,10 +115,22 @@ # Prints various stuff during startup log4j.logger.org.apache.juddi.registry.RegistryServlet=WARN - # Prints various stuff when the portal is used log4j.logger.org.apache.pluto.portalImpl.Servlet=WARN + # Prints stuff for AJAX calls log4j.logger.uk.ltd.getahead.dwr.impl.DefaultConfiguration=WARN log4j.logger.uk.ltd.getahead.dwr.impl.ExecuteQuery=WARN log4j.logger.uk.ltd.getahead.dwr.util.Logger=WARN + +# Axis log output +log4j.logger.org.apache.axis.enterprise=FATAL +log4j.logger.org.apache.axis.TIME=OFF +log4j.logger.org.apache.axis.EXCEPTIONS=FATAL + +# Axis2 log output +log4j.logger.org.apache.axis2.enterprise=FATAL +log4j.logger.de.hunsicker.jalopy.io=FATAL +log4j.logger.httpclient.wire.header=FATAL +log4j.logger.org.apache.commons.httpclient=FATAL + smime.p7s Description: S/MIME Cryptographic Signature
[jira] Updated: (GERONIMO-3038) h.tld file not getting properly generated to conform to the latest web-jsptaglibrary_2_1.xsd schema
[ https://issues.apache.org/jira/browse/GERONIMO-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-3038: Attachment: h_tld_exception.txt.txt Hi Paul/David, I've attached the XmlException output from the h.tld file that resides in the myfaces-impl-1.2.0-SNAPSHOT.jar file. Initially, I thought this particular TLD file conformed to one of the other valid schemas for web-jsptaglibrary files (i.e., 1.1 DTD, 1.2 DTD, or 2.0 XSD). However, it doesn't conform to any of those, nor the proper 2.1 XSD schema, making it impossible to convert it correctly. It appears to me to be almost a combination of multiple schemas, which might make some sense if it's programmatically generated by MyFaces, but that only makes it more difficult to convert propertly. > h.tld file not getting properly generated to conform to the latest > web-jsptaglibrary_2_1.xsd schema > --- > > Key: GERONIMO-3038 > URL: https://issues.apache.org/jira/browse/GERONIMO-3038 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: web >Reporter: Tim McConnell > Assigned To: Paul McMahan >Priority: Minor > Attachments: h_tld_exception.txt.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r525594 - /geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/src/main/resources/var/log/server-log4j.properties
Why? I don't think its a good idea to keep growing the list of logger levels in our log4j configuration file like this. For one or two its okay, but probably not for so many. I mean, do these libraries really spit out so much information that we have to limit them all to FATAL? The default output level is currently set to WARN unless the -v or - vv flag is passed to the server, which will set to DEBUG and TRACE respectively. With logger levels set explicitly , then adding -v or - vv will have zero affect. And the way we currently configure these levels affect both the console and log files. I think that changing these levels to FATAL is harmful and should be reverted... unless there is a really good reason for it... which is what I'm asking right now. What is the reason we need to have these explicit logger levels configured here? --jason On Apr 4, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: Author: dwoods Date: Wed Apr 4 13:05:30 2007 New Revision: 525594 URL: http://svn.apache.org/viewvc?view=rev&rev=525594 Log: GERONIMO-3064 Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo. Thanks Lin. I also added the Axis v1 log categories. Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties Modified: geronimo/server/trunk/assemblies/geronimo-boilerplate- minimal/src/main/resources/var/log/server-log4j.properties URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/ geronimo-boilerplate-minimal/src/main/resources/var/log/server- log4j.properties?view=diff&rev=525594&r1=525593&r2=525594 == --- geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties (original) +++ geronimo/server/trunk/assemblies/geronimo-boilerplate-minimal/ src/main/resources/var/log/server-log4j.properties Wed Apr 4 13:05:30 2007 @@ -115,10 +115,22 @@ # Prints various stuff during startup log4j.logger.org.apache.juddi.registry.RegistryServlet=WARN - # Prints various stuff when the portal is used log4j.logger.org.apache.pluto.portalImpl.Servlet=WARN + # Prints stuff for AJAX calls log4j.logger.uk.ltd.getahead.dwr.impl.DefaultConfiguration=WARN log4j.logger.uk.ltd.getahead.dwr.impl.ExecuteQuery=WARN log4j.logger.uk.ltd.getahead.dwr.util.Logger=WARN + +# Axis log output +log4j.logger.org.apache.axis.enterprise=FATAL +log4j.logger.org.apache.axis.TIME=OFF +log4j.logger.org.apache.axis.EXCEPTIONS=FATAL + +# Axis2 log output +log4j.logger.org.apache.axis2.enterprise=FATAL +log4j.logger.de.hunsicker.jalopy.io=FATAL +log4j.logger.httpclient.wire.header=FATAL +log4j.logger.org.apache.commons.httpclient=FATAL +
[jira] Closed: (GERONIMO-3064) Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods closed GERONIMO-3064. -- Resolution: Fixed Committed revision 525594 in trunk. Also added the Axis v1 log categories. Thanks Lin. > Add axis2 log4j configure properties so that people can turn on axis2 logs in > geronimo > -- > > Key: GERONIMO-3064 > URL: https://issues.apache.org/jira/browse/GERONIMO-3064 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Logging >Affects Versions: 2.0-M5 > Environment: sun 1.5 SDK + winxp >Reporter: Lin Sun > Assigned To: Donald Woods >Priority: Minor > Fix For: 2.0-M5 > > Attachments: G3064.patch > > > This patch will add a few axis2 logging properties so that people could turn > on axis2 logs easily. The axis2 log will be appended in geronimo.log. > geronimo-boilerplate-minimal\src\main\resources\var\log\server-log4j.properties > is the only file I can find in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3064) Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3064: -- Assignee: Donald Woods > Add axis2 log4j configure properties so that people can turn on axis2 logs in > geronimo > -- > > Key: GERONIMO-3064 > URL: https://issues.apache.org/jira/browse/GERONIMO-3064 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Logging >Affects Versions: 2.0-M5 > Environment: sun 1.5 SDK + winxp >Reporter: Lin Sun > Assigned To: Donald Woods >Priority: Minor > Fix For: 2.0-M5 > > Attachments: G3064.patch > > > This patch will add a few axis2 logging properties so that people could turn > on axis2 logs easily. The axis2 log will be appended in geronimo.log. > geronimo-boilerplate-minimal\src\main\resources\var\log\server-log4j.properties > is the only file I can find in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Running portlets in Geronimo - Documentation
Hi all, I put together a doc for configuring a portal server (a.k.a. Liferay) on Geronimo. I saw a couple of times users asking how to deploy portlets in Geronimo, hopefully this doc will help to address some of those questions. Here is the link: http://cwiki.apache.org/GMOxDOC11/configuring-portals-liferay.html As usual, comments welcome! Cheers! Hernan
[jira] Updated: (GERONIMO-3022) @PersistenceContext annotation support
[ https://issues.apache.org/jira/browse/GERONIMO-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMO-3022: Attachment: GERONIMO-3022.patch Patch includes testcases for these AnnotationHelper classes: -- EJBAnnotationHelper -- HandlerChainAnnotationHelper -- PersistenceContextAnnotationHelper -- PersistenceUnitAnnotationHelper -- ResourceAnnotationHelper -- WebServiceRefAnnotationHelper Additionally, includes a fix for GERONIMO-3058 plus new support for translations from the @Resource annotation. Finally, I've done a full build to ensure I haven't broken anything. > @PersistenceContext annotation support > -- > > Key: GERONIMO-3022 > URL: https://issues.apache.org/jira/browse/GERONIMO-3022 > Project: Geronimo > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Tim McConnell > Assigned To: Tim McConnell > Attachments: GERONIMO-3022.patch, GERONIMO-3022.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
[
https://issues.apache.org/jira/browse/GERONIMO-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods updated GERONIMO-1716:
---
Fix Version/s: (was: 2.0-M3)
2.0-M5
Moving to M5 as the target release
> Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
>
>
> Key: GERONIMO-1716
> URL: https://issues.apache.org/jira/browse/GERONIMO-1716
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 1.0, 1.1, 1.1.1, 1.2, 2.0-M5
> Environment: Any
>Reporter: Donald Woods
> Assigned To: Donald Woods
>Priority: Minor
> Fix For: 2.0-M5
>
> Attachments: G1716.patch
>
>
> Enhancement to the default PropertiesFileLoginModule and Console to encrypt
> user passwords in users.properties.
> To do this, PropertiesFileLoginModule and Console will be updated to use the
> SimpleEncryption utility class, just like the deployer, to read/write
> passwords that have the {Simple} key in front of encrypted passwords.
> The loadProperties() method in PropertiesFileLoginModule will also be updated
> to rewrite the users.properties file if it detects unencrypted passwords,
> which will allow users to manually edit the file to update a password and
> then have it automatically encrypted when the next login event occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3064) Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo
[ https://issues.apache.org/jira/browse/GERONIMO-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lin Sun updated GERONIMO-3064: -- Attachment: G3064.patch Haven't verified if this will be picked up by tomcat/jetty jee5 assembly yet but thought this won't break the build and I will do so whenever I get chance to clean my .m2 repo. > Add axis2 log4j configure properties so that people can turn on axis2 logs in > geronimo > -- > > Key: GERONIMO-3064 > URL: https://issues.apache.org/jira/browse/GERONIMO-3064 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Logging >Affects Versions: 2.0-M5 > Environment: sun 1.5 SDK + winxp >Reporter: Lin Sun >Priority: Minor > Fix For: 2.0-M5 > > Attachments: G3064.patch > > > This patch will add a few axis2 logging properties so that people could turn > on axis2 logs easily. The axis2 log will be appended in geronimo.log. > geronimo-boilerplate-minimal\src\main\resources\var\log\server-log4j.properties > is the only file I can find in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3064) Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo
Add axis2 log4j configure properties so that people can turn on axis2 logs in geronimo -- Key: GERONIMO-3064 URL: https://issues.apache.org/jira/browse/GERONIMO-3064 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: Logging Affects Versions: 2.0-M5 Environment: sun 1.5 SDK + winxp Reporter: Lin Sun Priority: Minor Fix For: 2.0-M5 This patch will add a few axis2 logging properties so that people could turn on axis2 logs easily. The axis2 log will be appended in geronimo.log. geronimo-boilerplate-minimal\src\main\resources\var\log\server-log4j.properties is the only file I can find in trunk. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2968) Hide Bogus Tomcat 5.5 error message when running on Java SE 5
[ https://issues.apache.org/jira/browse/GERONIMO-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-2968: -- Assignee: Donald Woods > Hide Bogus Tomcat 5.5 error message when running on Java SE 5 > - > > Key: GERONIMO-2968 > URL: https://issues.apache.org/jira/browse/GERONIMO-2968 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: Logging >Affects Versions: 1.1.1, 1.1.2, 1.2 > Environment: Java SE 5 >Reporter: Donald Woods > Assigned To: Donald Woods >Priority: Minor > Fix For: 1.1.2, 1.2 > > Attachments: G2968-1.1.1.patch > > > Tomcat 5.5.x will generate the following exception when DEBUG logging is > enabled in the geronimo.log file when run on a Java SE 5 JVM, since Tomcat > 5.5.x was compiled using the Sun 1.4.2 SDK and the JSSE15 classes were not > generated (and the message can be ignored) - > 13:09:15,156 DEBUG [JSSEImplementation] Error getting factory: > org.apache.tomcat.util.net.jsse.JSSE15Factory > java.lang.ClassNotFoundException: > org.apache.tomcat.util.net.jsse.JSSE15Factory > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:127) > at > org.apache.tomcat.util.net.jsse.JSSEImplementation.(JSSEImplementation.java:53) > at > org.apache.tomcat.util.net.SSLImplementation.getInstance(SSLImplementation.java:70) > at > org.apache.tomcat.util.net.SSLImplementation.getInstance(SSLImplementation.java:47) > at > org.apache.tomcat.util.net.SSLImplementation.getInstance(SSLImplementation.java:63) > at > org.apache.coyote.http11.Http11BaseProtocol.checkSocketFactory(Http11BaseProtocol.java:732) > at > org.apache.coyote.http11.Http11BaseProtocol.init(Http11BaseProtocol.java:123) > at > org.apache.catalina.connector.Connector.initialize(Connector.java:1016) > at > org.apache.catalina.core.StandardService.addConnector(StandardService.java:260) > at org.apache.catalina.startup.Embedded.addConnector(Embedded.java:326) > at > org.apache.geronimo.tomcat.TomcatContainer.addConnector(TomcatContainer.java:341) > at > org.apache.geronimo.tomcat.TomcatContainer$$FastClassByCGLIB$$9370b073.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) > at > org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:817) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.tomcat.TomcatContainer$$EnhancerByCGLIB$$1a3cefb5.addConnector() > at > org.apache.geronimo.tomcat.ConnectorGBean.doStart(ConnectorGBean.java:129) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:981) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) > at > org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41) > at > org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111) > at > org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146) > at > org.apache.geronimo.gbean.runtime.GBeanDepende
[jira] Assigned: (GERONIMO-1413) Console needs to set JSP and Servlet contentType to UTF-8
[ https://issues.apache.org/jira/browse/GERONIMO-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-1413: -- Assignee: Donald Woods > Console needs to set JSP and Servlet contentType to UTF-8 > - > > Key: GERONIMO-1413 > URL: https://issues.apache.org/jira/browse/GERONIMO-1413 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.0 > Environment: AG 1.0 on non-Latin charset machines >Reporter: Donald Woods > Assigned To: Donald Woods >Priority: Minor > Attachments: Geronimo-1413.patch > > > JSP pages and Portal JSP fragment wrapper need to set >contentType="text/html; charset=UTF-8" > so users that are using a non-Latin based charset locale (aka double-byte > character sets) can display the pages correctly. > Also, the web.xml needs to be updated so the Servlet provides content and > expects forms encoded as UTF8. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2759) Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 release
[ https://issues.apache.org/jira/browse/GERONIMO-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-2759: -- Assignee: Donald Woods > Re-enable JVMCheck to warn users if Java SE 5 is not being used for 2.0 > release > --- > > Key: GERONIMO-2759 > URL: https://issues.apache.org/jira/browse/GERONIMO-2759 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: JVM-compatibility >Affects Versions: 2.0-M1 >Reporter: Donald Woods > Assigned To: Donald Woods >Priority: Minor > Fix For: 2.0-M5 > > Attachments: G2759.patch > > > We need to re-enable the JVMCheck call in Daemon.java to warn Java 1.4 or > Java 6 users that Java SE 5 is required. > JEE 5 requires a Java SE 5 or later JVM. > A recent 1/9/07 posting on the users list mentioned that Java 6 will not > work, due to a javax.xml.stream.FactoryConfigurationError and a Stax > implementation included in Java 6. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2941) New config-substitutions.properties file is missing from Tomcat assemblies
[ https://issues.apache.org/jira/browse/GERONIMO-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-2941: -- Assignee: Donald Woods > New config-substitutions.properties file is missing from Tomcat assemblies > -- > > Key: GERONIMO-2941 > URL: https://issues.apache.org/jira/browse/GERONIMO-2941 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0-M4 > Environment: geronimo-tomcat6-jee5 assembly - Rev516152 >Reporter: Donald Woods > Assigned To: Donald Woods > Fix For: 2.0-M4 > > Attachments: G2941.diff > > > The Tomcat assemblies do not include a config-substitutions.properties file, > which causes the following error on server start - > 16:05:25,453 ERROR [LocalAttributeManager] Caught exception > java.io.FileNotFoundException: > C:\geronimo-tomcat6-jee5-2.0-SNAPSHOT\var\config\config-substitutions.properties > (The system cannot find the file specified.) trying to open properties file > C:\geronimo-tomcat6-jee5-2.0-SNAPSHOT\var\config\config-substitutions.properties > Adding a copy of config-substitutions.properties from Jetty to > assemblies\geronimo-boilerplate-minimal\src\main\resources\var\config with > the sample properties commented out will fix this problem for tomcat6-jee5 > and all of the minimal assemblies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3056) WARNING messages issued during deployment on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn resolved GERONIMO-3056. Resolution: Fixed Fix Version/s: 2.0-M5 committed in rev. 525561. Thanks Jay. > WARNING messages issued during deployment on Jetty > -- > > Key: GERONIMO-3056 > URL: https://issues.apache.org/jira/browse/GERONIMO-3056 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, Jetty >Affects Versions: 2.0-M4 >Reporter: Joe Bohn > Assigned To: Joe Bohn >Priority: Minor > Fix For: 2.0-M5 > > Attachments: geronimo-3056.patch, snoop.war > > > While deploying a simple web application (WAR) without a plan from the admin > console on a Jetty JEE5 server instance everything appears to deploy and work > correctly. However, there are these WARNing messages written to the console > that appear to reference each jar in the repository. Note, the first WARNing > message below is expected (because there was no plan) but the subsequent > "Cannott read JAR file..." messages are not expected. I didn't see the same > problem on Tomcat. This was using the 2.0-M4-rc1 > 13:25:12,369 WARN [JettyModuleBuilder] Web application . does not contain a > WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, > depending on whether you have things like resource references that need to be > resolved. You can also give the deployer a separate deployment plan file on > the command line. > 13:25:13,151 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-rmi-spec-1.0-incubating-SNAPSHOT.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-spec-corba-1.0-incubating-SNAPSHOT.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar!/META-INF > 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar!/META-INF > 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/apple_provider.jar!/META-INF > 13:25:13,323 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/dnsns.jar!/META-INF > 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/localedata.jar!/META-INF > 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunjce_provider.jar!/META-INF > 13:25:13,833 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunpkcs11.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/bin/server.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/geronimo-kernel-2.0-M4.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/commons-logging-1.0.4.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/log4j-1.2.14.jar!/META-INF > 13:25:13,835 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/xpp3-1.1.3.3.jar!/META-INF > 13:25:13,835 WARN [JspModuleBuild
[jira] Assigned: (GERONIMO-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
[
https://issues.apache.org/jira/browse/GERONIMO-1716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donald Woods reassigned GERONIMO-1716:
--
Assignee: Donald Woods
> Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
>
>
> Key: GERONIMO-1716
> URL: https://issues.apache.org/jira/browse/GERONIMO-1716
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 1.0, 1.1, 1.1.1, 1.2, 2.0-M5
> Environment: Any
>Reporter: Donald Woods
> Assigned To: Donald Woods
>Priority: Minor
> Fix For: 2.0-M3
>
> Attachments: G1716.patch
>
>
> Enhancement to the default PropertiesFileLoginModule and Console to encrypt
> user passwords in users.properties.
> To do this, PropertiesFileLoginModule and Console will be updated to use the
> SimpleEncryption utility class, just like the deployer, to read/write
> passwords that have the {Simple} key in front of encrypted passwords.
> The loadProperties() method in PropertiesFileLoginModule will also be updated
> to rewrite the users.properties file if it detects unencrypted passwords,
> which will allow users to manually edit the file to update a password and
> then have it automatically encrypted when the next login event occurs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-2835) Error when shutting down server
[ https://issues.apache.org/jira/browse/GERONIMO-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods updated GERONIMO-2835: --- Fix Version/s: (was: 2.0-M2) 2.0-M5 moving to M5 as target release > Error when shutting down server > --- > > Key: GERONIMO-2835 > URL: https://issues.apache.org/jira/browse/GERONIMO-2835 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: ActiveMQ >Affects Versions: 2.0-M2, 2.0-M4 >Reporter: Krishnakumar B > Fix For: 2.0-M5 > > > 13:14:56,218 WARN [GeronimoConnectionEventListener] connectionErrorOccurred > called with null > java.sql.SQLException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedConnection.getAutoCommit(Unknown > Source) > at org.apache.derby.iapi.jdbc.BrokeredConnection.getAutoCommit(Unknown > Source) > at > org.tranql.connector.jdbc.ConnectionHandle.rollback(ConnectionHandle.java:129) > at > org.apache.activemq.store.jdbc.DefaultDatabaseLocker.stop(DefaultDatabaseLocker.java:80) > at > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.stop(JDBCPersistenceAdapter.java:202) > at > org.apache.activemq.store.journal.JournalPersistenceAdapter.stop(JournalPersistenceAdapter.java:254) > at org.apache.activemq.util.ServiceStopper.stop(ServiceStopper.java:42) > at org.apache.activemq.broker.BrokerService.stop(BrokerService.java:443) > at > org.apache.activemq.gbean.BrokerServiceGBeanImpl.doStop(BrokerServiceGBeanImpl.java:106) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance(GBeanInstance.java:1146) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop(GBeanInstanceState.java:337) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:188) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop(GBeanInstanceState.java:180) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.stop(GBeanInstance.java:551) > at > org.apache.geronimo.kernel.basic.BasicKernel.stopGBean(BasicKernel.java:423) > at > org.apache.geronimo.kernel.config.KernelConfigurationManager$ShutdownHook.run(KernelConfigurationManager.java:310) > at > org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks(BasicKernel.java:668) > at > org.apache.geronimo.kernel.basic.BasicKernel.shutdown(BasicKernel.java:645) > at org.apache.geronimo.system.main.Daemon$1.run(Daemon.java:234) > 13:14:56,228 ERROR [JournalPersistenceAdapter] Could not stop service: [EMAIL > PROTECTED] Reason: java.sql.SQLException: No current connection. > java.sql.SQLException: No current connection. > at > org.apache.derby.impl.jdbc.SQLExceptionFactory
Re: [DISCUSS] 2.0-M4 Binaries available (rc1) - rc1 is dead
So moving forward is reproducibility of our milestone builds always going to be an issue? I think this is pretty ridiculous that this is such a painful process and I understand Matt's frustration. Does any one know if Maven is using us as a case-study and working toward addressing some of our major concerns? If not, do we look toward another build solution in the future? -sachin On Apr 4, 2007, at 11:33 AM, Matt Hogstrom wrote: Here's my 0.02 c. The process is owrking well as (I think it was Rakesh) that identified something odd about the binaries. We should not have both artifacts (2.0-M4 and 2.0-M4-SNAPSHOT) in the binaries. As release manager I am not comfortable releasing these and I'm concerned about where they got picked up and will investigate this. I will work today to spin up a corrected set of binaries that addresses the issues we've been discussing (buildability, etc.) I have to say that every release is a learning experience. So, for my part doing this once a month has been useful as it flushes out a new set of issues. Geronimo is so dependent on external projects that we are in a unique (and difficult) position from a release standpoint as our dependent projects do not release in a coordinated fashion. I have a check list of how to build and am augmenting it with a list of things to look for...something new every time :)
[jira] Resolved: (GERONIMO-3063) Axis2 Build Failure on Trunk
[ https://issues.apache.org/jira/browse/GERONIMO-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davanum Srinivas resolved GERONIMO-3063. Resolution: Fixed Fixed in svn revision 525554 thanks, dims > Axis2 Build Failure on Trunk > > > Key: GERONIMO-3063 > URL: https://issues.apache.org/jira/browse/GERONIMO-3063 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0-M5 > Environment: Trunk Rev525398, Sun 1.5.0_11, SLES10 >Reporter: Donald Woods > Assigned To: Davanum Srinivas >Priority: Blocker > Fix For: 2.0-M5 > > > Just started seeing this build failure on Trunk in the last hour after > starting with a clean .m2 repo, due to a new Axis2 SNAPSHOT being released > this morning - > [INFO] [compiler:compile] > [INFO] Compiling 11 source files to > /home/g20/working/server/modules/geronimo-axis2/target/classes > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Compilation failure > /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] > > org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport > is not abstract and does not override abstract method > signalFaultReady(org.apache.axis2.AxisFault) in > org.apache.axis2.transport.RequestResponseTransport > /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] > > org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport > is not abstract and does not override abstract method > signalFaultReady(org.apache.axis2.AxisFault) in > org.apache.axis2.transport.RequestResponseTransport > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 12 minutes 7 seconds > [INFO] Finished at: Wed Apr 04 12:12:58 EDT 2007 > [INFO] Final Memory: 95M/570M > [INFO] > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Axis2 Build Failure on Trunk
I just opened G3063 for this. https://issues.apache.org/jira/browse/GERONIMO-3063 -Donald Donald Woods wrote: Just started seeing this build failure on Trunk in the last hour after starting with a clean .m2 repo, due to a new Axis2 SNAPSHOT being released this morning - [INFO] [compiler:compile] [INFO] Compiling 11 source files to /home/g20/working/server/modules/geronimo-axis2/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 minutes 7 seconds [INFO] Finished at: Wed Apr 04 12:12:58 EDT 2007 [INFO] Final Memory: 95M/570M [INFO] smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-3063) Axis2 Build Failure on Trunk
Axis2 Build Failure on Trunk Key: GERONIMO-3063 URL: https://issues.apache.org/jira/browse/GERONIMO-3063 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.0-M5 Environment: Trunk Rev525398, Sun 1.5.0_11, SLES10 Reporter: Donald Woods Assigned To: Davanum Srinivas Priority: Blocker Fix For: 2.0-M5 Just started seeing this build failure on Trunk in the last hour after starting with a clean .m2 repo, due to a new Axis2 SNAPSHOT being released this morning - [INFO] [compiler:compile] [INFO] Compiling 11 source files to /home/g20/working/server/modules/geronimo-axis2/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 minutes 7 seconds [INFO] Finished at: Wed Apr 04 12:12:58 EDT 2007 [INFO] Final Memory: 95M/570M [INFO] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Axis2 Build Failure on Trunk
Just started seeing this build failure on Trunk in the last hour after starting with a clean .m2 repo, due to a new Axis2 SNAPSHOT being released this morning - [INFO] [compiler:compile] [INFO] Compiling 11 source files to /home/g20/working/server/modules/geronimo-axis2/target/classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport /home/g20/working/server/modules/geronimo-axis2/src/main/java/org/apache/geronimo/axis2/Axis2WebServiceContainer.java:[348,4] org.apache.geronimo.axis2.Axis2WebServiceContainer.Axis2RequestResponseTransport is not abstract and does not override abstract method signalFaultReady(org.apache.axis2.AxisFault) in org.apache.axis2.transport.RequestResponseTransport [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 12 minutes 7 seconds [INFO] Finished at: Wed Apr 04 12:12:58 EDT 2007 [INFO] Final Memory: 95M/570M [INFO] smime.p7s Description: S/MIME Cryptographic Signature
[jira] Assigned: (GERONIMO-3056) WARNING messages issued during deployment on Jetty
[ https://issues.apache.org/jira/browse/GERONIMO-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bohn reassigned GERONIMO-3056: -- Assignee: Joe Bohn (was: Jay D. McHugh) > WARNING messages issued during deployment on Jetty > -- > > Key: GERONIMO-3056 > URL: https://issues.apache.org/jira/browse/GERONIMO-3056 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, Jetty >Affects Versions: 2.0-M4 >Reporter: Joe Bohn > Assigned To: Joe Bohn >Priority: Minor > Attachments: geronimo-3056.patch, snoop.war > > > While deploying a simple web application (WAR) without a plan from the admin > console on a Jetty JEE5 server instance everything appears to deploy and work > correctly. However, there are these WARNing messages written to the console > that appear to reference each jar in the repository. Note, the first WARNing > message below is expected (because there was no plan) but the subsequent > "Cannott read JAR file..." messages are not expected. I didn't see the same > problem on Tomcat. This was using the 2.0-M4-rc1 > 13:25:12,369 WARN [JettyModuleBuilder] Web application . does not contain a > WEB-INF/geronimo-web.xml deployment plan. This may or may not be a problem, > depending on whether you have things like resource references that need to be > resolved. You can also give the deployer a separate deployment plan file on > the command line. > 13:25:13,151 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-rmi-spec-1.0-incubating-SNAPSHOT.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/endorsed/yoko-spec-corba-1.0-incubating-SNAPSHOT.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/classes.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/ui.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/laf.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jsse.jar!/META-INF > 13:25:13,152 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/jce.jar!/META-INF > 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Classes/charsets.jar!/META-INF > 13:25:13,153 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/apple_provider.jar!/META-INF > 13:25:13,323 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/dnsns.jar!/META-INF > 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/localedata.jar!/META-INF > 13:25:13,373 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunjce_provider.jar!/META-INF > 13:25:13,833 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/lib/ext/sunpkcs11.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/bin/server.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/geronimo-kernel-2.0-M4.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/commons-logging-1.0.4.jar!/META-INF > 13:25:13,834 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/log4j-1.2.14.jar!/META-INF > 13:25:13,835 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-rc1/geronimo-jetty6-jee5-2.0-M4/lib/xpp3-1.1.3.3.jar!/META-INF > 13:25:13,835 WARN [JspModuleBuilderExtension] Cannot read JAR file: > jar:file:/Users/bohn/g-images/2.0-m4-
[jira] Commented: (GERONIMO-3051) DB Viewer portlet error
[ https://issues.apache.org/jira/browse/GERONIMO-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486689 ] Joe Bohn commented on GERONIMO-3051: Ok, I had something else messed up that was preventing the application from deploying. However, with the patch applied and keeping jstl included in jee-specs (for the build issue I mentioned) I still had the same "no suitable driver" issue that I was hoping this might resolve for me. > DB Viewer portlet error > --- > > Key: GERONIMO-3051 > URL: https://issues.apache.org/jira/browse/GERONIMO-3051 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, databases >Affects Versions: 2.0-M4 > Environment: embedded Derby databases >Reporter: Hernan Cunico > Attachments: GERONIMO-3051-new.patch, GERONIMO-3051.patch > > > There is a problem when trying to view an embedded Derby database. > I am able to successfully create a new DB with the DB manager and a new entry > appears in the DB Viewer but when I try to view that DB from the DB Viewer I > get a portlet error. > When I check the logs I get this: > 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet > jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception > javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error > getting connection: "java.sql.SQLException: No suitable driver" > ... > 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw > exception > javax.servlet.ServletException > ... > 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > ... > With the exception of the "SystemDatabase" all the other databases created on > the embedded Derby are also unaccessible from other applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3062) heartbeat server monitoring
heartbeat server monitoring --- Key: GERONIMO-3062 URL: https://issues.apache.org/jira/browse/GERONIMO-3062 Project: Geronimo Issue Type: New Feature Security Level: public (Regular issues) Reporter: mike Z Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] 2.0-M4 Binaries available (rc1) - rc1 is dead
Here's my 0.02 c. The process is owrking well as (I think it was Rakesh) that identified something odd about the binaries. We should not have both artifacts (2.0-M4 and 2.0-M4-SNAPSHOT) in the binaries. As release manager I am not comfortable releasing these and I'm concerned about where they got picked up and will investigate this. I will work today to spin up a corrected set of binaries that addresses the issues we've been discussing (buildability, etc.) I have to say that every release is a learning experience. So, for my part doing this once a month has been useful as it flushes out a new set of issues. Geronimo is so dependent on external projects that we are in a unique (and difficult) position from a release standpoint as our dependent projects do not release in a coordinated fashion. I have a check list of how to build and am augmenting it with a list of things to look for...something new every time :)
Re: Board Report Nudge
Thanks for pulling this together, Matt. Looks good to me. With Rick's additions, I can't think of anything else to add... --kevan On Apr 4, 2007, at 11:09 AM, Matt Hogstrom wrote: Sure, please add them ... everyone should be able to edit the Wiki ... thanks On Apr 4, 2007, at 10:43 AM, Rick McGuire wrote: Matt Hogstrom wrote: Just a gentle nudge...please review: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board- report-2007-04-april.html Should we be mentioning the smaller things we released, such as the updates to the javamail spec and provider jars? Rick
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
I tend to agree since these are milestone snapshots not real releases, but am wondering how the repo/source release part would work. Can someone explain? Regards, Alan On Apr 3, 2007, at 6:29 PM, Donald Woods wrote: Agree, lets release M4 as-is with the repo and source zipfiles, in case anyone wants to debug a problem they find -Donald Hernan Cunico wrote: can't we just provide the binaries?, it is a milestone release that will live less than a month. Cheers! Hernan Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? -Donald
Re: Board Report Nudge
Sure, please add them ... everyone should be able to edit the Wiki ... thanks On Apr 4, 2007, at 10:43 AM, Rick McGuire wrote: Matt Hogstrom wrote: Just a gentle nudge...please review: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board- report-2007-04-april.html Should we be mentioning the smaller things we released, such as the updates to the javamail spec and provider jars? Rick
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
Joe Bohn wrote: I agree that we should spend much more time on M4 ... but if we just release them as-is then it shouldn't consume many more cycles. Correction on bad typo ... "I agree that we should *not* spend much more time on M4 ... " :-) Joe
Re: [DISCUSS] 2.0-M4 Binaries available (rc1)
I think that we should make the binaries available as is. It gives folks something to work even with the extra config. Aside from the image size (and confusion if people are looking at the system modules) they don't seem to be doing any harm. I agree that we should spend much more time on M4 ... but if we just release them as-is then it shouldn't consume many more cycles. Joe Matt Hogstrom wrote: On Apr 3, 2007, at 4:57 PM, Donald Woods wrote: I'll upload the 11 Axis2 and 11 CXF artifacts into the M4 branches local repo and update the pom.xml if someone will either respin/republish the build for me or walk me through how to do it:-) Donald, excellent and I appreciate it. I would checkout the 2.0-M4 in branches to start with. There must be some lingering issue in hte build or we somehow picked up the SNAPSHOT though some transitive dependencies. If you like I can provide you with the repo I used for this build. It may be possible to address Alan's concern about being able to rebuild as well. Although, personally I think the time invested in 2.0 is better spent than waving a dead chicken on 2.0-M4. By the time it get built and voted on we'll be into next week most likely with the next milestone a few weeks away. I think a better solution would be to simply create an unstable set and put them up on people.apache.org. Other's thoughts? -Donald
[jira] Commented: (GERONIMO-3051) DB Viewer portlet error
[ https://issues.apache.org/jira/browse/GERONIMO-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486670 ] Joe Bohn commented on GERONIMO-3051: Well, my attempt to run with the jstl dependency in both jee-specs and in the default environment of the app didn't go very well. I was unable to initialize the gbean after deploying the app because of a strange NPE in the JspModuleBuilderExtension trying to add the GBean. > DB Viewer portlet error > --- > > Key: GERONIMO-3051 > URL: https://issues.apache.org/jira/browse/GERONIMO-3051 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, databases >Affects Versions: 2.0-M4 > Environment: embedded Derby databases >Reporter: Hernan Cunico > Attachments: GERONIMO-3051-new.patch, GERONIMO-3051.patch > > > There is a problem when trying to view an embedded Derby database. > I am able to successfully create a new DB with the DB manager and a new entry > appears in the DB Viewer but when I try to view that DB from the DB Viewer I > get a portlet error. > When I check the logs I get this: > 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet > jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception > javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error > getting connection: "java.sql.SQLException: No suitable driver" > ... > 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw > exception > javax.servlet.ServletException > ... > 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > ... > With the exception of the "SystemDatabase" all the other databases created on > the embedded Derby are also unaccessible from other applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Board Report Nudge
Matt Hogstrom wrote: Just a gentle nudge...please review: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board-report-2007-04-april.html Should we be mentioning the smaller things we released, such as the updates to the javamail spec and provider jars? Rick
Re: Board Report Nudge
Don't worry about the board / NDA :) The actual problem is that the board minutes are public information: http://apache.org/foundation/board/calendar.html So we should not add TCK status. We could add a line saying "working through issues on how to speed up communication with SUN regarding TCK challenges" (with better wording of course), since it is a pain point for us. thanks, dims On 4/4/07, Joe Bohn <[EMAIL PROTECTED]> wrote: Looks good to me. The only other possible addition I thought of was to be more specific with our TCK status on both 1.2 & 2.0. Of course, that would mean that we would have to remove the report from the wiki. I'm not sure if that's worth it and I'm not even sure that all of the board has signed the NDA ... so it's probably best to leave it out. Thanks, Joe Matt Hogstrom wrote: > Just a gentle nudge...please review: > > http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board-report-2007-04-april.html > > -- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers
[jira] Created: (SM-921) FTPClientPool does not have dataTimeout and controlEncoding properties.
FTPClientPool does not have dataTimeout and controlEncoding properties.
-
Key: SM-921
URL: https://issues.apache.org/activemq/browse/SM-921
Project: ServiceMix
Issue Type: Bug
Components: servicemix-components
Affects Versions: 3.1
Reporter: Alper Sogukpinar
FTPClientPool does not set FtpClient __dataTimeout property and If timeout
value is not set, infinite timeout will be the case.
As a result of that not only the thread which is in infinite timeout condition
is affected and ftp connection remains open forever but also the file which is
put into the workingSet by the thread will not be processed by latter
FtpPoller threads.
I tried both FtpClient.setDataTimeout and FtpClient.setSoTimeout properties in
my tests and only FtpClient.setDataTimeout was worked.
Creating a DEFAULT_TIMEOUT property and setting dataTimeout just after opening
the ftp connection will solve the problem.
In addition to this a bean property which overrides DEFAULT_TIMEOUT should be
created for user configuration.
In ddition to these, DEFAULT_CONTROL_ENCODING property should also be created
on FTPClientPool for setting controlEncoding property of FtpClient object.
Otherwise, non US ASCII characters which are used in the name of a target file
causes problems. For example Default encoding does not support Turkish
characters. When non US ASCII characters like Turkish charachers (ş,
ı, ğ) are used in the fileName, each of them is converted to '?'
character and '?' is not acceptable for a fileName. As a result of that an
exception is thrown...
***
Sample Code...
public class FTPClientPool {
private static int DEFAULT_TIMEOUT = 600*1000;
private static String DEFAULT_CONTROL_ENCODING = "Cp1254";
public SocketClient borrowClient() throws Exception {
FTPClient client = null;
try {
client = new FTPClient();
client.setControlEncoding(DEFAULT_CONTROL_ENCODING);
if (getConfig() != null) {
client.configure(getConfig());
}
super.connect(client);
client.setDataTimeout(DEFAULT_TIMEOUT);
.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3051) DB Viewer portlet error
[ https://issues.apache.org/jira/browse/GERONIMO-3051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486654 ] Joe Bohn commented on GERONIMO-3051: I noticed that you created the patch from configs. The patch was applied correclty. The difference in our results might be because I'm doing a top level clean build. I think if you try that (using mvn clean install) you will see the problem. We can get past the build problem by keeping the dependency on jstl in jee-specs while still adding it to the defaultEnvironment in JspModuleBuilderExtension, but I'm not sure if that will continue to cause the runtime issues. I'll try it out a little later and see. > DB Viewer portlet error > --- > > Key: GERONIMO-3051 > URL: https://issues.apache.org/jira/browse/GERONIMO-3051 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console, databases >Affects Versions: 2.0-M4 > Environment: embedded Derby databases >Reporter: Hernan Cunico > Attachments: GERONIMO-3051-new.patch, GERONIMO-3051.patch > > > There is a problem when trying to view an embedded Derby database. > I am able to successfully create a new DB with the DB manager and a new entry > appears in the DB Viewer but when I try to view that DB from the DB Viewer I > get a portlet error. > When I check the logs I get this: > 09:57:02,421 ERROR [listTables_jsp]] Servlet.service() for servlet > jsp.WEB_002dINF.view.internaldb.listTables_jsp threw exception > javax.servlet.ServletException: javax.servlet.jsp.JspTagException: Error > getting connection: "java.sql.SQLException: No suitable driver" > ... > 09:57:02,421 ERROR [[DBViewer]] Servlet.service() for servlet DBViewer threw > exception > javax.servlet.ServletException > ... > 09:57:02,453 ERROR [PortletInvokerImpl] PortletInvokerImpl.render() - Error > while dispatching portlet. > javax.portlet.PortletException > ... > With the exception of the "SystemDatabase" all the other databases created on > the embedded Derby are also unaccessible from other applications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Board Report Nudge
Looks good to me. The only other possible addition I thought of was to be more specific with our TCK status on both 1.2 & 2.0. Of course, that would mean that we would have to remove the report from the wiki. I'm not sure if that's worth it and I'm not even sure that all of the board has signed the NDA ... so it's probably best to leave it out. Thanks, Joe Matt Hogstrom wrote: Just a gentle nudge...please review: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board-report-2007-04-april.html
Board Report Nudge
Just a gentle nudge...please review: http://cwiki.apache.org/GMOxPMGT/apache-geronimo-board-report-2007-04- april.html
[jira] Commented: (SM-914) Exception upon generating a dot file from the apache-servicemix-web distribution in Tomcat
[
https://issues.apache.org/activemq/browse/SM-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38956
]
Bruce Snyder commented on SM-914:
-
Oh so the exception _java.io.IOException: dot: not found_ is actually
ServiceMix looking for the GraphViz executable?
> Exception upon generating a dot file from the apache-servicemix-web
> distribution in Tomcat
> ---
>
> Key: SM-914
> URL: https://issues.apache.org/activemq/browse/SM-914
> Project: ServiceMix
> Issue Type: Bug
>Affects Versions: 3.1
> Environment: MacOS X 10.4.8/Tomcat 5.5.20
>Reporter: Bruce Snyder
>
> Upon deploying the {{apache-servicemix-web-3.1-incubating.war}} file in
> Tomcat 5.5.20 and clicking on the 'View' link in the ServiceMix console, the
> following exception is thrown:
> {code}
> WARN - [dispatcher] - Servlet.service() for servlet
> dispatcher threw exception
> java.io.IOException: dot: not found
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:52)
> at java.lang.ProcessImpl.start(ProcessImpl.java:91)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> at java.lang.Runtime.exec(Runtime.java:591)
> at java.lang.Runtime.exec(Runtime.java:429)
> at java.lang.Runtime.exec(Runtime.java:326)
> at
> org.apache.servicemix.web.view.DotView.renderMergedOutputModel(DotView.java:71)
> at
> org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:249)
> at
> org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1105)
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:841)
> at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755)
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396)
> at
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.apache.servicemix.web.filter.ApplicationContextFilter.doFilter(ApplicationContextFilter.java:81)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
> at
> org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
> at
> org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at
> org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
> at java.lang.Thread.run(Thread.java:613)
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-915) FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
[
https://issues.apache.org/activemq/browse/SM-915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_38955
]
Gert Vanthienen commented on SM-915:
... but the original problem still isn't solved.
We get an additional stacktrace when ServiceMix is stopping and the problem
only appears to exist when the FTP server is IIS.
{code}
java.io.IOException: Fatal thread interruption during read.
at
org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:344)
at
org.apache.commons.net.telnet.TelnetInputStream.read(TelnetInputStream.java:466)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:254)
at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:264)
at org.apache.commons.net.ftp.FTP.getReply(FTP.java:605)
at
org.apache.commons.net.ftp.FTPClient.completePendingCommand(FTPClient.java:1253)
at
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2400)
at
org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
at
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:210)
at
org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:202)
at
org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:77)
at
org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
{code}
I've asked the commons mailing list for help on this one...
> FTP poller stalls with threads waiting on PlainSocketImpl.socketAccept()
>
>
> Key: SM-915
> URL: https://issues.apache.org/activemq/browse/SM-915
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-ftp
>Affects Versions: 3.1
>Reporter: Gert Vanthienen
> Attachments: SM-915.patch
>
>
> FTP poller threads stop working with the stack trace below, causing the FTP
> client pool to run out of connections
> {code}
> Name: pool-component.servicemix-ftp-thread-2
> State: RUNNABLE
> Total blocked: 78,430 Total waited: 4,771
> Stack trace:
> java.net.PlainSocketImpl.socketAccept(Native Method)
> java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
> java.net.ServerSocket.implAccept(ServerSocket.java:450)
> java.net.ServerSocket.accept(ServerSocket.java:421)
>
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:502)
>
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2390)
>
> org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2364)
> org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2141)
>
> org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:211)
>
> org.apache.servicemix.ftp.FtpPollerEndpoint.pollFileOrDirectory(FtpPollerEndpoint.java:203)
>
> org.apache.servicemix.ftp.FtpPollerEndpoint.poll(FtpPollerEndpoint.java:78)
>
> org.apache.servicemix.common.endpoints.PollingEndpoint$PollSchedulerTask$1.run(PollingEndpoint.java:155)
>
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
>
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> java.lang.Thread.run(Thread.java:595)
> {code}
> See http://www.nabble.com/FTP-poller-stalls...-tf3490690s12049.html for more
> information
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
