You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "William L. Thomson Jr." <wl...@o-sinc.com> on 2018/06/18 23:08:44 UTC
JDK 11 EA 18
I was also running into this on EA 17, but 18 is current. I had Tomcat
and all my stuff, some Jersey and minor Webapps without issues on JDK
11 EA 9 up to like Tomcat 9.0.6, I think also 9.0.7.
As of late I am not able to start much. The base Tomcat starts but
all webapps fail with "ManagedBean is not found in *", as seen below. I
have tried many things to resolve unsuccessfully. I am looking for
suggestions. Not sure if this is JDK changes, some missing dependency
on bootstrap classpath or within the container, lib directory. Seems to
be something in the JDK. It builds fine, and starts. Just no webapps.
Thanks in advance for any ideas on how to fix!!!
Background
I am doing things a bit abnormal. Running Gentoo building from source
without ant, tomcat split into many packages, all deps built from
source, etc. It all been working fine for sometime even on JDK 11.
tomcat-* packages here
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java
Meta package
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/www-servers/tomcat
Exception snippets
org.apache.catalina.deploy.NamingResourcesImpl.initInternal
namingResources.mbeanCreateFail javax.management.MBeanException
Caused by: java.lang.Exception: ManagedBean is not found with
ContextResource at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:152) ...
12 more
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans
Exception creating UserDatabase MBeans for UserDatabase
java.lang.IllegalArgumentException: Cannot create UserDatabase MBean
for resource UserDatabase Caused by: javax.management.MBeanException at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:308)
at
org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:172) ...
15 more Caused by: java.lang.Exception: ManagedBean is not found with
MemoryUserDatabase at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:307) ...
16 more
org.apache.catalina.deploy.NamingResourcesImpl.initInternal
namingResources.mbeanCreateFail javax.management.MBeanException
Caused by: java.lang.Exception: ManagedBean is not found with
ContextResource at
org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:152) ...
43 more
--
William L. Thomson Jr.
Re: Tomcat source layout (was: JDK 11 EA 18)
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Tue, 26 Jun 2018 09:07:32 +0200
Emmanuel Bourg <eb...@apache.org> wrote:
> Le 26/06/2018 à 05:21, William L. Thomson Jr. a écrit :
>
> > Because I am crazy :)
>
> I personally would support a move to a Maven directory layout even if
> we stick to Ant as the main build system for now. I think it's good
> to use a standard project layout, it looks immediately familiar to
> newcomers.
That is the idea, just to standardize stuff. Not switch build systems.
> That said, I don't really understand why you can't use Ant to build
> Tomcat in Gentoo. Ant is rather reasonably easy to bootstrap and we
> have no problem using it to build Tomcat from sources in
> Debian/Ubuntu.
The problem with Ant and Gentoo has nothing to do with Tomcat really.
Tomcat has built fine for years via Ant on Gentoo and still does. But it
is the Gentoo specific Ant eclass, bash functions library. Plus
packaging and dealing with Ant Tasks. That is a bit cumbersome to
maintain. All around dealing with Ant is more work. I rather avoid.
Presently Gentoo is stuck on <= 1.8 till ant eclass and others are
updated, and other things. The ant eclass also requires complicated XML
re-writers in python to modify classpath, source/target and now release
in build.xml. Which adds more overhead, complexity, and things to
maintain. For some things like Netbeans and other projects it failed to
re-write all source/targets.
I tossed these rather than maintain, to complex, there are better ways.
https://github.com/gentoo/gentoo/blob/master/eclass/java-ant-2.eclass
https://github.com/gentoo/gentoo/blob/master/eclass/ant-tasks.eclass
I am using a more simplistic method of straight javac using a Gentoo
bash eclass. That looks for stuff in standard locations. Reason for my
request to change Tomcat directory layout.
Most the logic is here
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-pkg-simple.eclass
Plus legacy eclass till I re-write, it is already heavily modified.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-utils-2.eclass
My way does not require build.xml modifications, or anything there. I
can ensure always source/target/release, as I am doing the compile
directly. No worries on classpath pollution, accidentally using shipped
jars, or other. Which for ant at times required symlinks to system jars
in build system and other cumbersome stuff. Dealing with Ant is a lot
of work and things to maintain.
For example for tomcat-serlvet-api, always used a stand alone
build.xml, separate from one tomcat ships with. Since there is no means
to build only those jars easily. Without heavy modifications to default
build.xml. Thus creating a standalone build.xml, more to maintain.
https://github.com/gentoo/gentoo/tree/master/dev-java/tomcat-servlet-api/files
Then to prevent downloads, and other things not needed in the
default build.xml. You need to modify build.xml and usually create a
patch. Which is also cumbersome to deal with, more to maintain.
https://github.com/gentoo/gentoo/tree/master/www-servers/tomcat/files
My way requires no patches, guaranteed source/target/release,
classpath, etc. All in a more reliable and simple way that requires
less effort to maintain over a long term. Across hundreds of packages,
maintained by a single person :)
--
William L. Thomson Jr.
Re: Tomcat source layout (was: JDK 11 EA 18)
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 26/06/2018 à 05:21, William L. Thomson Jr. a écrit :
> Because I am crazy :)
I personally would support a move to a Maven directory layout even if we
stick to Ant as the main build system for now. I think it's good to use
a standard project layout, it looks immediately familiar to newcomers.
That said, I don't really understand why you can't use Ant to build
Tomcat in Gentoo. Ant is rather reasonably easy to bootstrap and we have
no problem using it to build Tomcat from sources in Debian/Ubuntu.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JDK 11 EA 18
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Mon, 25 Jun 2018 23:21:47 -0400
"William L. Thomson Jr." <wl...@o-sinc.com> wrote:
> On Mon, 25 Jun 2018 19:40:27 -0400
> Christopher Schultz <ch...@christopherschultz.net> wrote:
>
> > I'm confused about what you're asking, here. Do you want Tomcat to
> > change its own directory layout?
>
> Ideally yes, like a directory per jar, with
>
> src/java/main
> src/java/resources
Totally messed that up...
src/main/java
src/main/resources
--
William L. Thomson Jr.
Re: JDK 11 EA 18
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Mon, 25 Jun 2018 19:40:27 -0400
Christopher Schultz <ch...@christopherschultz.net> wrote:
> I'm confused about what you're asking, here. Do you want Tomcat to
> change its own directory layout?
Ideally yes, like a directory per jar, with
src/java/main
src/java/resources
Jetty is good example or Netbeans
https://github.com/eclipse/jetty.project
https://github.com/apache/incubator-netbeans
> Why?
Because I am crazy :)
It makes packaging it easier IMHO. Each directory contains what ends up
in a given jar. Right now they are all mixed together in java,
including resources. Fine if you use the build system. But then its all
or nothing. Cannot really build a jar, or just those needed/wanted.
Tomcat on Gentoo used to use ant and was a monolithic package short of
servlet-api. Which still exists in Gentoo.
https://github.com/gentoo/gentoo/blob/master/www-servers/tomcat/tomcat-9.0.7.ebuild
https://github.com/gentoo/gentoo/blob/master/dev-java/tomcat-servlet-api/tomcat-servlet-api-9.0.7.ebuild
I have split it out to be a package per jar. Its working
great, it was just a bit of a pain to find what goes in each jar. If
that changes, I will have to match jar contents again. Make sure
correct classes are going in the correct jar, and resources.
See all the tomcat-* packages here, one per jar
https://github.com/Obsidian-StudiosInc/os-xtoo/tree/master/dev-java
Some are a bit tricky to package I have to remove some files or specify
which to include. It is not really ideal.
Example of matching jar contents
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/dev-java/tomcat-jasper/tomcat-jasper-9999.ebuild#L39
Then I have a meta package, that just pulls in all others to form the
actual tomcat installation.
Meta package
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/www-servers/tomcat/tomcat-9999.ebuild
The individual packages allow for embedded use and for development etc.
Like say using Tomcat in Netbeans. This way Netbeans has access to all
Tomcat jars, but does not require a server package to be installed.
Even better Netbeans can have its own "Tomcat install", linking in jars
into its own local server space with its own config, etc. Before others
were doing stuff with the server package.
If making an embedded app, you can pull in what jars you need, rather
than building all of tomcat and having init scripts and other stuff
laying around unused.
Just makes it a bit more modular. A different way of shipping Tomcat :)
--
William L. Thomson Jr.
Re: JDK 11 EA 18
Posted by Christopher Schultz <ch...@christopherschultz.net>.
William,
On 6/20/18 9:21 PM, William L. Thomson Jr. wrote:
> Turns out my issues were due to resources ending up in a sub-directory,
> prefixed with java/org, like find out in sources. One aspect I would
> like to see done if possible. Tomcat mixes a lot of stuff into the same
> directories. Its layout and what not started before the normal java
> conventions now such as;
>
> src/main/java
> src/main/resources
>
> It would be great if tomcat could move towards such structure. My
> problem was due to grabbing resources that are mixed in with sources.
> Then failing to strip java/ from the path as I copied over the files
> into the jar. Various properties and xml files. I understand some
> properties files need be in the same folders but other stuff like xml.
> But many of those can be merged at build time.
>
> Packaging hundreds of Java applications. Very few mix in resources with
> source files. Thus my logic for handling such cases was off. Self
> inflicted problem, but would help if project layout was better.
>
> Utopian would be moving various pieces into sub-directories for the
> various jars. I had to be creative to get my jars to be the same as
> those from upstream. Due to sources all being mixed together. Beyond
> mixing resources and java sources.
I'm confused about what you're asking, here. Do you want Tomcat to
change its own directory layout? Why?
-chris
Re: JDK 11 EA 18
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
On Fri, 22 Jun 2018 08:41:20 +0100
Mark Thomas <ma...@apache.org> wrote:
>
> Rather than repeating what has been said many times before, I suggest
> you look in the archives for past discussions on source structure.
> They are usually part of a discussion about switching to Maven as a
> build system.
While restructure would be a step in such direction. I am not
suggesting switching build systems. It would not matter for my needs,
as I would bypass Maven or Gradle just the same as Ant.
I took part on one discussion long ago regarding Tomcat and Maven when I
officially maintained Tomcat on Gentoo. I can see how its likely come
up many times since. Though my objections then have now passed as I am
not using any build system. Maven and Gradle are not easily
integrated into Gentoo's Portage. Even Ant was a pain and I have
tossed out that integration. Though my 2 cents now would be Gradle vs
Maven. Seems few if any know about things Maven is built on like Plexus
and Modello. Otherwise the build system is moot to me.
None the less I would think moving stuff into sub-modules per jar and
moving resources into their own directories to help with development
and such. Just shows where stuff resides. Though some is shared in like
bootstrap I believe. It was just the one difficulty I had in packaging
Tomcat on Gentoo my new way using straight javac via bash Gentoo
elcasses. Plus the one hiccup as I had to get resources from sources.
That was interesting to see Tomcat running missing most resources.
I am past that self inflicted issue with resources now. Changing
layout is some what moot. Short of when new files are added I must add
to specific jars. That may get a bit hairy. Will cross that bridge then.
Either way thanks for considering the feedback on project structure!
--
William L. Thomson Jr.
Re: JDK 11 EA 18
Posted by Mark Thomas <ma...@apache.org>.
On 21/06/18 02:21, William L. Thomson Jr. wrote:
> Turns out my issues were due to resources ending up in a sub-directory,
> prefixed with java/org, like find out in sources. One aspect I would
> like to see done if possible. Tomcat mixes a lot of stuff into the same
> directories. Its layout and what not started before the normal java
> conventions now such as;
>
> src/main/java
> src/main/resources
>
> It would be great if tomcat could move towards such structure. My
> problem was due to grabbing resources that are mixed in with sources.
> Then failing to strip java/ from the path as I copied over the files
> into the jar. Various properties and xml files. I understand some
> properties files need be in the same folders but other stuff like xml.
> But many of those can be merged at build time.
>
> Packaging hundreds of Java applications. Very few mix in resources with
> source files. Thus my logic for handling such cases was off. Self
> inflicted problem, but would help if project layout was better.
>
> Utopian would be moving various pieces into sub-directories for the
> various jars. I had to be creative to get my jars to be the same as
> those from upstream. Due to sources all being mixed together. Beyond
> mixing resources and java sources.
Rather than repeating what has been said many times before, I suggest
you look in the archives for past discussions on source structure. They
are usually part of a discussion about switching to Maven as a build system.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: JDK 11 EA 18
Posted by "William L. Thomson Jr." <wl...@o-sinc.com>.
Turns out my issues were due to resources ending up in a sub-directory,
prefixed with java/org, like find out in sources. One aspect I would
like to see done if possible. Tomcat mixes a lot of stuff into the same
directories. Its layout and what not started before the normal java
conventions now such as;
src/main/java
src/main/resources
It would be great if tomcat could move towards such structure. My
problem was due to grabbing resources that are mixed in with sources.
Then failing to strip java/ from the path as I copied over the files
into the jar. Various properties and xml files. I understand some
properties files need be in the same folders but other stuff like xml.
But many of those can be merged at build time.
Packaging hundreds of Java applications. Very few mix in resources with
source files. Thus my logic for handling such cases was off. Self
inflicted problem, but would help if project layout was better.
Utopian would be moving various pieces into sub-directories for the
various jars. I had to be creative to get my jars to be the same as
those from upstream. Due to sources all being mixed together. Beyond
mixing resources and java sources.
--
William L. Thomson Jr.