[jira] [Updated] (TOMEE-877) ParentClassLoaderFinder default strategy is broken for embedded OpenEJB
[ https://issues.apache.org/jira/browse/TOMEE-877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-877: Attachment: TOMEE-877.patch ParentClassLoaderFinder default strategy is broken for embedded OpenEJB --- Key: TOMEE-877 URL: https://issues.apache.org/jira/browse/TOMEE-877 Project: TomEE Issue Type: Bug Affects Versions: 1.5.1 Reporter: Mark Struberg Priority: Critical Attachments: TOMEE-877.patch ParentClassLoaderFinder default strategy always uses the ClassLoader which got used to load OpenEJB.class. But this algorithm is broken for all scenarios where a classloader hierarchy is in place. Instead of this we should use the Thread.currentThread.getContextClassLoader() by default. Please note that is is effectively not possible to set a custom ParrentClassLoaderFinder (via SystemInstance.get().setComponent(ParentClassLoaderFinder.class,... ) when using EJBContainer.createEJBContainer() as this gets cleared via SystemInstance.reset() at boot time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (OPENEJB-2022) don't create an application classloader if not mandatory (classpath deployment) in embedded mode
[ https://issues.apache.org/jira/browse/OPENEJB-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened OPENEJB-2022: the logic to determine which classes to skip breaks existing apps if there is a mixture between ejb-jars and CDI jars. Only the ejb-jars will get picked up and all cdi-jars will be completely ignored. The cdi-jars are still there in NewLoaderLogic#applyBuiltinExcludes but don't make it to Assembler#createAppClassLoader don't create an application classloader if not mandatory (classpath deployment) in embedded mode Key: OPENEJB-2022 URL: https://issues.apache.org/jira/browse/OPENEJB-2022 Project: OpenEJB Issue Type: Improvement Reporter: Romain Manni-Bucau Assignee: Romain Manni-Bucau Fix For: 4.6.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOMEE-959) changes done in ProcessAnnotatedType get ignored for EJBs
Mark Struberg created TOMEE-959: --- Summary: changes done in ProcessAnnotatedType get ignored for EJBs Key: TOMEE-959 URL: https://issues.apache.org/jira/browse/TOMEE-959 Project: TomEE Issue Type: Bug Affects Versions: 1.6.0 Reporter: Mark Struberg I'm dynamically applying an Interceptor via a CDI Extension (https://github.com/struberg/InterDyn). This dynamically added @InvocationMonitored annotation gets ignored for all EJBs in tomee-1.6.0-SNAPSHOT. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOMEE-1063) URL encoding problems when using ?faces-redirect=trueincludeViewParams=true
[ https://issues.apache.org/jira/browse/TOMEE-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13801571#comment-13801571 ] Mark Struberg commented on TOMEE-1063: -- Could you please try to add a ServletFilter which sets the encoding for request and response to setCharacterencoding(UTF-8); URL encoding problems when using ?faces-redirect=trueincludeViewParams=true Key: TOMEE-1063 URL: https://issues.apache.org/jira/browse/TOMEE-1063 Project: TomEE Issue Type: Bug Affects Versions: 1.5.2, 1.5.3, 1.6.0 Reporter: Kristof Neirynck This is basicly the same bug as https://java.net/jira/browse/JAVASERVERFACES-2440 I've created a simple testproject for it here: https://github.com/Crydust/facesredirect 1. submit a field with an umlaut or other unicode character 2. return to the view with ?faces-redirect=trueincludeViewParams=true 3. the url contains a wrongly encoded string 4. the value of the viewParam is also wrongly encoded now This can be reproduced on TomEE 1.5.2, 1.5.3-SNAPSHOT, 1.6.0-SNAPSHOT and even Glassfish 3.1.2.2. This seems to work correctly on JBoss eap 6.1 and Glassfish 4.0. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TOMEE-1214) tomee should pick up conf/log4j.xml
Mark Struberg created TOMEE-1214: Summary: tomee should pick up conf/log4j.xml Key: TOMEE-1214 URL: https://issues.apache.org/jira/browse/TOMEE-1214 Project: TomEE Issue Type: Bug Affects Versions: 1.6.0.1 Reporter: Mark Struberg Fix For: 1.7.0 If a user sets -Dopenejb.log.factory=log4j then we currently only look for logging.properties in our /conf folder. We should also pick up conf/log4j.xml that way _after_ conf/logging.properties, but _before_ the internal default config. If there is a conf/logging.properties then we will of course _not_ check for log4j.xml... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TOMEE-1215) Log4jLogStreamFactory picks up wrong conf directory
Mark Struberg created TOMEE-1215:
Summary: Log4jLogStreamFactory picks up wrong conf directory
Key: TOMEE-1215
URL: https://issues.apache.org/jira/browse/TOMEE-1215
Project: TomEE
Issue Type: Bug
Affects Versions: 1.6.0.1
Reporter: Mark Struberg
Fix For: 1.7.0
Log4jLogStreamFactory (and most probably a few others) pick up the conf
directory from the current path
{code}
SystemInstance.get().getConf(null)
{code}
which is essentially
{code}
system.getBase.getDirectory(conf)
{code}
When starting from tomee-maven-plugin this points to my project directory. But
the tomee working directory is actually in ./target/apache-tomee/
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOMEE-1215) Log4jLogStreamFactory picks up wrong conf directory
[
https://issues.apache.org/jira/browse/TOMEE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002172#comment-14002172
]
Mark Struberg commented on TOMEE-1215:
--
seems to happen from PersistenceBootstrap. In this case env.get is empty for
openejb.base and for openejb.home :/
Log4jLogStreamFactory picks up wrong conf directory
---
Key: TOMEE-1215
URL: https://issues.apache.org/jira/browse/TOMEE-1215
Project: TomEE
Issue Type: Bug
Affects Versions: 1.6.0.1
Reporter: Mark Struberg
Fix For: 1.7.0
Log4jLogStreamFactory (and most probably a few others) pick up the conf
directory from the current path
{code}
SystemInstance.get().getConf(null)
{code}
which is essentially
{code}
system.getBase.getDirectory(conf)
{code}
When starting from tomee-maven-plugin this points to my project directory.
But the tomee working directory is actually in ./target/apache-tomee/
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TOMEE-1215) Log4jLogStreamFactory picks up wrong conf directory
[
https://issues.apache.org/jira/browse/TOMEE-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14002186#comment-14002186
]
Mark Struberg commented on TOMEE-1215:
--
debugging further. The init of RootLogger is in Warmup which calls
Log4jLogStreamFactory. Still the variables are not set.
Log4jLogStreamFactory picks up wrong conf directory
---
Key: TOMEE-1215
URL: https://issues.apache.org/jira/browse/TOMEE-1215
Project: TomEE
Issue Type: Bug
Affects Versions: 1.6.0.1
Reporter: Mark Struberg
Fix For: 1.7.0
Log4jLogStreamFactory (and most probably a few others) pick up the conf
directory from the current path
{code}
SystemInstance.get().getConf(null)
{code}
which is essentially
{code}
system.getBase.getDirectory(conf)
{code}
When starting from tomee-maven-plugin this points to my project directory.
But the tomee working directory is actually in ./target/apache-tomee/
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (TOMEE-1214) tomee should pick up conf/log4j.xml
[ https://issues.apache.org/jira/browse/TOMEE-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened TOMEE-1214: -- The problem basically remains the same even after your fix. The point is that it doesn't even enter the new path as it finds the logging.properties (which are intended for jul only by default it seems) and skips all the later processing. I'm not sure why we read logging.properties at all if log4j is configured... tomee should pick up conf/log4j.xml --- Key: TOMEE-1214 URL: https://issues.apache.org/jira/browse/TOMEE-1214 Project: TomEE Issue Type: Bug Affects Versions: 1.6.0.1 Reporter: Mark Struberg Assignee: Romain Manni-Bucau Fix For: 1.7.0 If a user sets -Dopenejb.log.factory=log4j then we currently only look for logging.properties in our /conf folder. We should also pick up conf/log4j.xml that way _after_ conf/logging.properties, but _before_ the internal default config. If there is a conf/logging.properties then we will of course _not_ check for log4j.xml... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOMEE-1214) tomee should pick up conf/log4j.xml
[ https://issues.apache.org/jira/browse/TOMEE-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012291#comment-14012291 ] Mark Struberg commented on TOMEE-1214: -- What about the following: we parse the logging.properties and if it is either not there OR if it just contains no properties THEN we switch to the alternative handling of log4j.properties + log4j.xml? tomee should pick up conf/log4j.xml --- Key: TOMEE-1214 URL: https://issues.apache.org/jira/browse/TOMEE-1214 Project: TomEE Issue Type: Bug Affects Versions: 1.6.0.1 Reporter: Mark Struberg Assignee: Romain Manni-Bucau Fix For: 1.7.0 If a user sets -Dopenejb.log.factory=log4j then we currently only look for logging.properties in our /conf folder. We should also pick up conf/log4j.xml that way _after_ conf/logging.properties, but _before_ the internal default config. If there is a conf/logging.properties then we will of course _not_ check for log4j.xml... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TOMEE-1214) tomee should pick up conf/log4j.xml
[ https://issues.apache.org/jira/browse/TOMEE-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14012779#comment-14012779 ] Mark Struberg commented on TOMEE-1214: -- this means that you need to put your apps log4j config into an own jar and add it to the libs folder. Not very comfortable... tomee should pick up conf/log4j.xml --- Key: TOMEE-1214 URL: https://issues.apache.org/jira/browse/TOMEE-1214 Project: TomEE Issue Type: Bug Affects Versions: 1.6.0.1 Reporter: Mark Struberg Assignee: Romain Manni-Bucau Fix For: 1.7.0 If a user sets -Dopenejb.log.factory=log4j then we currently only look for logging.properties in our /conf folder. We should also pick up conf/log4j.xml that way _after_ conf/logging.properties, but _before_ the internal default config. If there is a conf/logging.properties then we will of course _not_ check for log4j.xml... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TOMEE-836) ReportValidationResults should log.info about the root cause
[ https://issues.apache.org/jira/browse/TOMEE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-836. - Resolution: Fixed seems to have been fixed in the meantime ReportValidationResults should log.info about the root cause Key: TOMEE-836 URL: https://issues.apache.org/jira/browse/TOMEE-836 Project: TomEE Issue Type: Bug Components: Compliance Checks Affects Versions: 1.5.1 Reporter: Mark Struberg Fix For: 1.7.0, 1.6.0.beta1 I'm having an EJB which references a @PersistenceContext with a not yet defined DataSource. This leads to a Deployment error, but the real cause is well hidden internally and doesn't get logged properly. Same happens if the persistence unit itself is not configured. This currently doesn't even lead to a deployment Exception but OpenEJB just resumes to start. If I debug into ReportValidationResults#deploy line 66 uberContext.addFailure(failure); then I see the issue. But it doesn't get logged it seems. This should at least be logged with INFO level imo. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TOMEE-1408) Incorrect assertions within the testcode
[ https://issues.apache.org/jira/browse/TOMEE-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reopened TOMEE-1408: -- this is still broken in trunk. Incorrect assertions within the testcode Key: TOMEE-1408 URL: https://issues.apache.org/jira/browse/TOMEE-1408 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Daniel Kasmeroglu Assignee: Andy Gumbrecht Fix For: 2.0.0 Attachments: tomee-1408.patch The test cases _DeploymentsElementTest_ and _EarModuleNamesTest_ in module _openejb-core_ contain invalid assertion values. They should be restored to the previous case which corresponds to the correct expectation: See: https://kasisoft.com/stash/projects/TOMEE/repos/tomee/commits/66be50b7313bca4fb339fa1883ee5bcc1cf1d288 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOMEE-1408) Incorrect assertions within the testcode
[ https://issues.apache.org/jira/browse/TOMEE-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1408. -- Resolution: Fixed Fix Version/s: 1.7.2 I gave the ear in each test method an own distinct appName. hacked this in master and 1.7.x branch. Incorrect assertions within the testcode Key: TOMEE-1408 URL: https://issues.apache.org/jira/browse/TOMEE-1408 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Daniel Kasmeroglu Assignee: Andy Gumbrecht Fix For: 2.0.0, 1.7.2 Attachments: tomee-1408.patch The test cases _DeploymentsElementTest_ and _EarModuleNamesTest_ in module _openejb-core_ contain invalid assertion values. They should be restored to the previous case which corresponds to the correct expectation: See: https://kasisoft.com/stash/projects/TOMEE/repos/tomee/commits/66be50b7313bca4fb339fa1883ee5bcc1cf1d288 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1428) improve the performance of TempClassLoader$ResourceComparator
Mark Struberg created TOMEE-1428: Summary: improve the performance of TempClassLoader$ResourceComparator Key: TOMEE-1428 URL: https://issues.apache.org/jira/browse/TOMEE-1428 Project: TomEE Issue Type: Improvement Affects Versions: 1.7.1, 2.0.0 Environment: maven build - tests running with openejb-embedded Reporter: Mark Struberg Fix For: 2.0.0, 1.7.2 While profiling our maven build with DeltaSpike CdiCtrl and openejb-embedded I noticed that TempClassLoader$ResourceComparator#weight eats up a big part of the scanning time. Improving this method could improve the overall boot time of openejb around 20%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1428) improve the performance of TempClassLoader$ResourceComparator
[ https://issues.apache.org/jira/browse/TOMEE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184452#comment-14184452 ] Mark Struberg commented on TOMEE-1428: -- the issue might be related to lowercase issues. I get the same classes twice in TempClassLoader#getResources() When I start the test from within Idea, then I get file:/c:/develop/... vs file:/C:/develop/... When I remote debug my maven build directly, then the drive letters are both lower case, but I get myjar-1.0-SNAPSHOT vs mycar-1.0-snapshot. improve the performance of TempClassLoader$ResourceComparator - Key: TOMEE-1428 URL: https://issues.apache.org/jira/browse/TOMEE-1428 Project: TomEE Issue Type: Improvement Affects Versions: 2.0.0, 1.7.1 Environment: maven build - tests running with openejb-embedded Reporter: Mark Struberg Fix For: 2.0.0, 1.7.2 While profiling our maven build with DeltaSpike CdiCtrl and openejb-embedded I noticed that TempClassLoader$ResourceComparator#weight eats up a big part of the scanning time. Improving this method could improve the overall boot time of openejb around 20%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1428) improve the performance of TempClassLoader$ResourceComparator
[ https://issues.apache.org/jira/browse/TOMEE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184455#comment-14184455 ] Mark Struberg commented on TOMEE-1428: -- humm and sometimes it's really _exactly_ the same. No difference in cases even. improve the performance of TempClassLoader$ResourceComparator - Key: TOMEE-1428 URL: https://issues.apache.org/jira/browse/TOMEE-1428 Project: TomEE Issue Type: Improvement Affects Versions: 2.0.0, 1.7.1 Environment: maven build - tests running with openejb-embedded Reporter: Mark Struberg Fix For: 2.0.0, 1.7.2 While profiling our maven build with DeltaSpike CdiCtrl and openejb-embedded I noticed that TempClassLoader$ResourceComparator#weight eats up a big part of the scanning time. Improving this method could improve the overall boot time of openejb around 20%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1428) improve the performance of TempClassLoader$ResourceComparator
[ https://issues.apache.org/jira/browse/TOMEE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184460#comment-14184460 ] Mark Struberg commented on TOMEE-1428: -- so far my conclusio is that it has to do with the doNotUseClassLoader created in DeploymentLoader. Despite it's name it seems to get used. This registeres an URL pointing to target/classes, but this location already gets served by the AppClassLoader (accessible via getOpenEjbClassLoader()) which it delegates too. improve the performance of TempClassLoader$ResourceComparator - Key: TOMEE-1428 URL: https://issues.apache.org/jira/browse/TOMEE-1428 Project: TomEE Issue Type: Improvement Affects Versions: 2.0.0, 1.7.1 Environment: maven build - tests running with openejb-embedded Reporter: Mark Struberg Fix For: 2.0.0, 1.7.2 While profiling our maven build with DeltaSpike CdiCtrl and openejb-embedded I noticed that TempClassLoader$ResourceComparator#weight eats up a big part of the scanning time. Improving this method could improve the overall boot time of openejb around 20%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1428) improve the performance of TempClassLoader$ResourceComparator
[ https://issues.apache.org/jira/browse/TOMEE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184559#comment-14184559 ] Mark Struberg commented on TOMEE-1428: -- well but TempClassLoader finds the class it serves for (the path given via the URL[] parameter) plus the same class from the AppClassLoader. And this is what causes the performance impact. I have a huge test scenario ready and will try + bench a few possible solutions for it. improve the performance of TempClassLoader$ResourceComparator - Key: TOMEE-1428 URL: https://issues.apache.org/jira/browse/TOMEE-1428 Project: TomEE Issue Type: Improvement Affects Versions: 2.0.0, 1.7.1 Environment: maven build - tests running with openejb-embedded Reporter: Mark Struberg Fix For: 2.0.0, 1.7.2 While profiling our maven build with DeltaSpike CdiCtrl and openejb-embedded I noticed that TempClassLoader$ResourceComparator#weight eats up a big part of the scanning time. Improving this method could improve the overall boot time of openejb around 20%. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OPENEJB-2107) connection issues in MulticastagentDiscoveryTest
Mark Struberg created OPENEJB-2107: -- Summary: connection issues in MulticastagentDiscoveryTest Key: OPENEJB-2107 URL: https://issues.apache.org/jira/browse/OPENEJB-2107 Project: OpenEJB Issue Type: Bug Affects Versions: 5.0.0 Environment: happens on OSX-10.10 Reporter: Mark Struberg Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 76.862 sec FAILURE! - in org.apache.openejb.server.discovery.MulticastDiscoveryAgentTest test(org.apache.openejb.server.discovery.MulticastDiscoveryAgentTest) Time elapsed: 76.8 sec ERROR! org.apache.openejb.server.ServiceException: java.net.SocketException: Can't assign requested address: Can't assign requested address at java.net.PlainDatagramSocketImpl.join(Native Method) at java.net.AbstractPlainDatagramSocketImpl.join(AbstractPlainDatagramSocketImpl.java:178) at java.net.MulticastSocket.joinGroup(MulticastSocket.java:319) at org.apache.openejb.server.discovery.MulticastDiscoveryAgent$Multicast.init(MulticastDiscoveryAgent.java:180) at org.apache.openejb.server.discovery.MulticastDiscoveryAgent.start(MulticastDiscoveryAgent.java:138) at org.apache.openejb.server.discovery.MulticastDiscoveryAgentTest.agent(MulticastDiscoveryAgentTest.java:86) at org.apache.openejb.server.discovery.MulticastDiscoveryAgentTest.test(MulticastDiscoveryAgentTest.java:39) Results : Tests in error: MulticastDiscoveryAgentTest.test:39-agent:86 » Service java.net.SocketExcepti... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1524) tomee doesn't start up deployments on restart
[
https://issues.apache.org/jira/browse/TOMEE-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362017#comment-14362017
]
Mark Struberg commented on TOMEE-1524:
--
I still think it should be on by default.
What is the issue with clusters? They also need to auto-restart the server
anyway. Even in a cluster.
What I miss (maybe it exists and I just don't know) is a way to deploy
_without_ start. That should actually be the default. Plus own commands to
start and stop the application. That way you can easily do ripple-starts in
cluster envs, cloud deployment, etc.
tomee doesn't start up deployments on restart
-
Key: TOMEE-1524
URL: https://issues.apache.org/jira/browse/TOMEE-1524
Project: TomEE
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Mark Struberg
Fix For: 2.0.0
We should set
{quote}
openejb.deployer.save-deployments = true
{quote}
in conf/system.properties as a default.
This is needed for EAR deployments not getting 'lost' during server restarts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TOMEE-1524) tomee doesn't start up deployments on restart
[
https://issues.apache.org/jira/browse/TOMEE-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14362326#comment-14362326
]
Mark Struberg commented on TOMEE-1524:
--
No Romain, even the JavaEE umbrella spec and the deployment spec clearly
separates between application deployment and application startup.
At deployment time we have to copy/unzip the artifacts of course. But it also
will create default resources and has to validate available resources, JNDI
locations etc. According to the EE spec those things have to validated before
the application starts. See the current EE spec discussion about how to handle
these requirements when CDI comes to play.
I agree that most of those requirements are 'nice to have' but no requirements.
E.g. you cannot finally verify JNDI resources before the application got
started. Nor should we fail a deployment just because a DataSource is not _yet_
defined.
Still there is a clear distinction between deployment and startup. _Especially_
when it comes to clusters! In a cluster I would expect a 'deploy' to also
distribute my binary to all my cluster nodes, do a fully automated
ripple-restart (to avoid downtime), etc
Of course I'm not sure if this should be part of TomEE or if the users have to
deal with this themselves (as it really depends on how your cluster setup does
look like).
tomee doesn't start up deployments on restart
-
Key: TOMEE-1524
URL: https://issues.apache.org/jira/browse/TOMEE-1524
Project: TomEE
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Mark Struberg
Fix For: 2.0.0
We should set
{quote}
openejb.deployer.save-deployments = true
{quote}
in conf/system.properties as a default.
This is needed for EAR deployments not getting 'lost' during server restarts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOMEE-1525) tomee.bat complains about 'input line too long' when deploying big projects
Mark Struberg created TOMEE-1525: Summary: tomee.bat complains about 'input line too long' when deploying big projects Key: TOMEE-1525 URL: https://issues.apache.org/jira/browse/TOMEE-1525 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Environment: Windows. Reporter: Mark Struberg Fix For: 2.0.0 tomee.bat complains about 'input line too long' when deploying big projects This comes from using -cp on the command to start the jvm. But if there are too many classpath entries then the commandline exceeds the limit of 8k. We should use the environment variable CLASSPATH instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1524) tomee doesn't start up deployments on restart
Mark Struberg created TOMEE-1524:
Summary: tomee doesn't start up deployments on restart
Key: TOMEE-1524
URL: https://issues.apache.org/jira/browse/TOMEE-1524
Project: TomEE
Issue Type: Bug
Affects Versions: 2.0.0
Reporter: Mark Struberg
Fix For: 2.0.0
We should set
{quote}
openejb.deployer.save-deployments = true
{quote}
in conf/system.properties as a default.
This is needed for EAR deployments not getting 'lost' during server restarts.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOMEE-1571) cdi-embedded TCK integration does not properly shut down Sessions
Mark Struberg created TOMEE-1571: Summary: cdi-embedded TCK integration does not properly shut down Sessions Key: TOMEE-1571 URL: https://issues.apache.org/jira/browse/TOMEE-1571 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Mark Struberg This issues happens when running our cdi-embedded TCK. In this mode the arquillian adaptor doesn't use tomcat but fires up OpenEJBHttpServer. But during undeploy this server doesn't get used but instead just the OpenWebBeans lifecycle in the WebBeansContext gets shut down. Due to this the Sessions don't get cleaned up properly. That makes us not only leak memory but also miss a few CDI events which are tested in our TCK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1572) adopt latest OWB-1.5.1 changes
Mark Struberg created TOMEE-1572: Summary: adopt latest OWB-1.5.1 changes Key: TOMEE-1572 URL: https://issues.apache.org/jira/browse/TOMEE-1572 Project: TomEE Issue Type: Task Affects Versions: 2.0.0 Reporter: Mark Struberg Fix For: 2.0.0 OWB-1.5.1 implemented quite a few changes which were already targetted for 1.5.0 bit did not make it due to timing contstraints. The main differences are * store SessionContext in real HttpSession if possible OWB-1048 * remove FailOverService OWB-1049 * store Conversations in the SessionContext OWB-1050 Most of these changes finally remove SPI and methods which are deprecated since a long time already -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1571) cdi-embedded TCK integration does not properly shut down Sessions
[ https://issues.apache.org/jira/browse/TOMEE-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14525146#comment-14525146 ] Mark Struberg commented on TOMEE-1571: -- After the rework in OWB we do not have any information about Servlet backed Sessions in the CDI container anymore. We just have the thread local 'dummy sessions' for non-servlet requests which we clean up. The 'real ' sessions have to get properly cleaned up by the servlet container - which openejb-httpd does _not_ atm. cdi-embedded TCK integration does not properly shut down Sessions - Key: TOMEE-1571 URL: https://issues.apache.org/jira/browse/TOMEE-1571 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Mark Struberg This issues happens when running our cdi-embedded TCK. In this mode the arquillian adaptor doesn't use tomcat but fires up OpenEJBHttpServer. But during undeploy this server doesn't get used but instead just the OpenWebBeans lifecycle in the WebBeansContext gets shut down. Due to this the Sessions don't get cleaned up properly. That makes us not only leak memory but also miss a few CDI events which are tested in our TCK. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1572) adopt latest OWB-1.6.0 changes
[ https://issues.apache.org/jira/browse/TOMEE-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14526838#comment-14526838 ] Mark Struberg commented on TOMEE-1572: -- We decided to use the version 1.6.0 for all those changes in OWB. So the new baseline for this work is trunk which targets OWB-1.6.0 adopt latest OWB-1.6.0 changes -- Key: TOMEE-1572 URL: https://issues.apache.org/jira/browse/TOMEE-1572 Project: TomEE Issue Type: Task Affects Versions: 2.0.0 Reporter: Mark Struberg Fix For: 2.0.0 OWB-1.5.1 implemented quite a few changes which were already targetted for 1.5.0 bit did not make it due to timing contstraints. The main differences are * store SessionContext in real HttpSession if possible OWB-1048 * remove FailOverService OWB-1049 * store Conversations in the SessionContext OWB-1050 Most of these changes finally remove SPI and methods which are deprecated since a long time already -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1576) openejb-http ServletRequest.getSession().invalidate should remove the session cached in the request
Mark Struberg created TOMEE-1576: Summary: openejb-http ServletRequest.getSession().invalidate should remove the session cached in the request Key: TOMEE-1576 URL: https://issues.apache.org/jira/browse/TOMEE-1576 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Mark Struberg Fix For: 2.0.0 affects openejb-http. The request impl 'caches' the current Session. But this doesn't get destroyed if you call request.getSession().invalidate(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOMEE-1576) openejb-http ServletRequest.getSession().invalidate should remove the session cached in the request
[ https://issues.apache.org/jira/browse/TOMEE-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1576. -- Resolution: Fixed done in the fb_tomee2_owb16 branch openejb-http ServletRequest.getSession().invalidate should remove the session cached in the request --- Key: TOMEE-1576 URL: https://issues.apache.org/jira/browse/TOMEE-1576 Project: TomEE Issue Type: Bug Affects Versions: 2.0.0 Reporter: Mark Struberg Fix For: 2.0.0 affects openejb-http. The request impl 'caches' the current Session. But this doesn't get destroyed if you call request.getSession().invalidate(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOMEE-1572) adopt latest OWB-1.6.0 changes
[ https://issues.apache.org/jira/browse/TOMEE-1572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1572. -- Resolution: Fixed Assignee: Mark Struberg fixed and pushed to master adopt latest OWB-1.6.0 changes -- Key: TOMEE-1572 URL: https://issues.apache.org/jira/browse/TOMEE-1572 Project: TomEE Issue Type: Task Affects Versions: 7.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 7.0.0 OWB-1.5.1 implemented quite a few changes which were already targetted for 1.5.0 bit did not make it due to timing contstraints. The main differences are * store SessionContext in real HttpSession if possible OWB-1048 * remove FailOverService OWB-1049 * store Conversations in the SessionContext OWB-1050 Most of these changes finally remove SPI and methods which are deprecated since a long time already -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1601) Ear-wide @AppliationScoped bean option
Mark Struberg created TOMEE-1601: Summary: Ear-wide @AppliationScoped bean option Key: TOMEE-1601 URL: https://issues.apache.org/jira/browse/TOMEE-1601 Project: TomEE Issue Type: New Feature Reporter: Mark Struberg Assignee: Mark Struberg This is only about EARs. Currently TomEE handles @ApplicationScoped beans as 1-per-WAR. This is basically a sane approach but other servers behave different. Most of the other servers opted for a 1-per-EAR approach. For compatibility reasons we should support a mode where we optionally also support this behaviour. This could e.g. get activated via system.properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1602) optional 'EAR-wide' CDI Extensions
Mark Struberg created TOMEE-1602: Summary: optional 'EAR-wide' CDI Extensions Key: TOMEE-1602 URL: https://issues.apache.org/jira/browse/TOMEE-1602 Project: TomEE Issue Type: Wish Reporter: Mark Struberg Assignee: Mark Struberg In TomEE we load all CDI Extensions always 1:1 to the BeanManager. This is perfectly fine from an isolation pov (and actually the only sane mode which does _not_ leak classes to other classloaders). But other containers don't behave that way and some Extensions rely on this behaviour... E.g. when parsing the classpath with @Observes ProcessAnnotatedType, storing some info in a Collection and then using this collected info in another phase later. This might lead to not seeing the scanned information though.. I'm not quite sure if we should implement a Extension 'sharing' compatibility mode or whether we should fix this properly in DeltaSpike, etc. For having a clean solution we would need to push this in CDI-2.0 by e.g. introducing a @Inject @Parent MyExtension qualifier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOMEE-1793) PostConstruct and PreRenderView called twice on load
[
https://issues.apache.org/jira/browse/TOMEE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266211#comment-15266211
]
Mark Struberg commented on TOMEE-1793:
--
2 questions: 1.) What kind of component is it where it fails? 2.) Are you
deliberately using Mojarra or just by accident (default is MyFaces...)
> PostConstruct and PreRenderView called twice on load
>
>
> Key: TOMEE-1793
> URL: https://issues.apache.org/jira/browse/TOMEE-1793
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 1.7.3, 1.7.4
>Reporter: Matthew Broadhead
> Attachments: threadstack20160501.txt
>
>
> May have started after recent Oracle java update (1.8.0-92-b14) but suddenly
> all ManagedBeans seem to be calling PostConstruct and PreRenderView twice on
> View load. Second time it is called the request parameters are empty.
> Result is that any redirect in PreRenderView gets executed. Determined
> second request was a Partial Request so surrounded PreRenderView listener with
> {code}
> if
> (!FacesContext.getCurrentInstance().getPartialViewContext().isPartialRequest())
> {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TOMEE-1793) PostConstruct and PreRenderView called twice on load
[
https://issues.apache.org/jira/browse/TOMEE-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266283#comment-15266283
]
Mark Struberg commented on TOMEE-1793:
--
Oh I see what you got wrong. The 'E' in PLUME has nothing to do with the
Eclipse IDE but with the EclipseLink JPA provider. Do you use JPA at all, and
if so what JPA provider do you like to use? Apache OpenJPA (default in TomEE),
JBoss Hibernate (default in JBossAS) or EclipseLink (default in GlassFish)?
> PostConstruct and PreRenderView called twice on load
>
>
> Key: TOMEE-1793
> URL: https://issues.apache.org/jira/browse/TOMEE-1793
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 1.7.3, 1.7.4
>Reporter: Matthew Broadhead
> Attachments: threadstack20160501.txt
>
>
> May have started after recent Oracle java update (1.8.0-92-b14) but suddenly
> all ManagedBeans seem to be calling PostConstruct and PreRenderView twice on
> View load. Second time it is called the request parameters are empty.
> Result is that any redirect in PreRenderView gets executed. Determined
> second request was a Partial Request so surrounded PreRenderView listener with
> {code}
> if
> (!FacesContext.getCurrentInstance().getPartialViewContext().isPartialRequest())
> {
> ...
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TOMEE-1925) WebContext#isWeb doesn't contain all web artifacts
Mark Struberg created TOMEE-1925: Summary: WebContext#isWeb doesn't contain all web artifacts Key: TOMEE-1925 URL: https://issues.apache.org/jira/browse/TOMEE-1925 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.1 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 7.0.2 It misses a few Listeners and can also get improved performance wise -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOMEE-1925) WebContext#isWeb doesn't contain all web artifacts
[ https://issues.apache.org/jira/browse/TOMEE-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1925. -- Resolution: Fixed > WebContext#isWeb doesn't contain all web artifacts > -- > > Key: TOMEE-1925 > URL: https://issues.apache.org/jira/browse/TOMEE-1925 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.1 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 7.0.2 > > > It misses a few Listeners and can also get improved performance wise -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOMEE-1920) upgrade OWB to 1.7.0-SNAPSHOT
[ https://issues.apache.org/jira/browse/TOMEE-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1920. -- Resolution: Fixed > upgrade OWB to 1.7.0-SNAPSHOT > - > > Key: TOMEE-1920 > URL: https://issues.apache.org/jira/browse/TOMEE-1920 > Project: TomEE > Issue Type: Task > Components: TomEE Core Server >Affects Versions: 7.0.1 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 7.0.2 > > > We pushed OWB to min require 1.7.0 and got rid of many obsolete modules > (JSF-1.2, EL-1.0 etc). > All those changes should _not_ affect TomEE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-1943) Tomee blows up when it finds tags in beans.xml which it doesn't know
Mark Struberg created TOMEE-1943: Summary: Tomee blows up when it finds tags in beans.xml which it doesn't know Key: TOMEE-1943 URL: https://issues.apache.org/jira/browse/TOMEE-1943 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.1, 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 7.0.2 We blow up heavily if we find a tag in e.g. beans.xml which we don't know. This is really sad since OWB has additional tags since many years and Weld also has them. A hardcoded 'ignore' hack got added for Weld, but not for OWB. We must only log out a warning if we detect a tag or attribute we don't know, but must not blow up. This really limits us. There is a simple trick to work around this: @XmlAnyElement(lax = true) private List unknownElements; + log out those values manually afterwards. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TOMEE-2031) Upgrade to latest Tomcat 7.0.77
Mark Struberg created TOMEE-2031: Summary: Upgrade to latest Tomcat 7.0.77 Key: TOMEE-2031 URL: https://issues.apache.org/jira/browse/TOMEE-2031 Project: TomEE Issue Type: Task Components: TomEE Core Server Affects Versions: 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.7.5 A newer version of Tomcat7 exists to which we should update: 7.0.77 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-2031) Upgrade to latest Tomcat 7.0.77
[ https://issues.apache.org/jira/browse/TOMEE-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2031. -- Resolution: Fixed > Upgrade to latest Tomcat 7.0.77 > --- > > Key: TOMEE-2031 > URL: https://issues.apache.org/jira/browse/TOMEE-2031 > Project: TomEE > Issue Type: Task > Components: TomEE Core Server >Affects Versions: 1.7.4 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 1.7.5 > > > A newer version of Tomcat7 exists to which we should update: 7.0.77 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOMEE-2032) Upgrade to OpenWebBeans-1.2.8
Mark Struberg created TOMEE-2032: Summary: Upgrade to OpenWebBeans-1.2.8 Key: TOMEE-2032 URL: https://issues.apache.org/jira/browse/TOMEE-2032 Project: TomEE Issue Type: Task Components: TomEE Core Server Affects Versions: 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.7.5 we still ship with owb 1.2.7, but 1.2.8 is out since a long time and fixed a few nasty bugs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-2029) OpenEJB #finalize might kill a foreign container
[ https://issues.apache.org/jira/browse/TOMEE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2029. -- Resolution: Fixed > OpenEJB #finalize might kill a foreign container > > > Key: TOMEE-2029 > URL: https://issues.apache.org/jira/browse/TOMEE-2029 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 1.7.4 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 1.7.5 > > > While tracking down a seemingly random TomEE bug in the DeltaSpike test suite > I finally figured what the cause is. In 1.7.3 a 'cleanup logic' got > introduced to ContextWrapper#finalize. > Sadly this often kills the wrong instance! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-2030) cdi-event-realm blows up with noSuchMethod in tomcat
[ https://issues.apache.org/jira/browse/TOMEE-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2030. -- Resolution: Fixed > cdi-event-realm blows up with noSuchMethod in tomcat > > > Key: TOMEE-2030 > URL: https://issues.apache.org/jira/browse/TOMEE-2030 > Project: TomEE > Issue Type: Bug > Components: Examples and Documentation >Affects Versions: 1.7.4 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 1.7.5 > > > cdi-event-realm blows up because it uses a manually set tomcat.version in > maven. But this tomcat version has class conflicts with the much more recent > one we use in the rest of TomEE. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-2032) Upgrade to OpenWebBeans-1.2.8
[ https://issues.apache.org/jira/browse/TOMEE-2032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2032. -- Resolution: Fixed > Upgrade to OpenWebBeans-1.2.8 > - > > Key: TOMEE-2032 > URL: https://issues.apache.org/jira/browse/TOMEE-2032 > Project: TomEE > Issue Type: Task > Components: TomEE Core Server >Affects Versions: 1.7.4 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 1.7.5 > > > we still ship with owb 1.2.7, but 1.2.8 is out since a long time and fixed a > few nasty bugs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-1763) Issue after installing TomEE+ 1.7.4 in Eclipse MARS 4.5.0 (windows 7) all 64 bit
[ https://issues.apache.org/jira/browse/TOMEE-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-1763. -- Resolution: Not A Bug Hi Igor! Closing this as not a bug in TomEE. But txs for reporting! Good to know such IDE limitations. Others might stumble over it as well. > Issue after installing TomEE+ 1.7.4 in Eclipse MARS 4.5.0 (windows 7) all 64 > bit > - > > Key: TOMEE-1763 > URL: https://issues.apache.org/jira/browse/TOMEE-1763 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 1.7.4 > Environment: Windows 7 64-bit, MARS 4.5.0 64-bit, Eclipse MARS 4.5.0 > 64-bit >Reporter: Igor Livshin >Priority: Minor > Fix For: 1.7.5 > > > After installing the server the log shows the following issues: > WARNING: File error: - Does not exist: > C:\Users\i262666\workspace_Eclipse_MARS_64_bit\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\apps > INFO: The APR based Apache Tomcat Native library which allows optimal > performance in production environments was not found on the > java.library.path: > C:\jdk1.7.0_11_SE_64_bit\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\IBM\Derby\db-derby-10.12.1.1-bin\bin;C:\jdk1.7.0_11_SE_64_bit\bin;C:\Program > Files (x86)\IBM\WebSphere MQ\Java\lib;C:\Program Files (x86)\AMD > APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;C:\Program Files > (x86)\HP SimplePass 2011\x64;C:\Program Files (x86)\HP SimplePass > 2011\;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program > Files (x86)\Common Files\Microsoft Shared\Windows > Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program > Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files > (x86)\Common Files\Roxio Shared\12.0\DLLShared\;C:\Program Files > (x86)\Windows Live\Shared;C:\Program Files (x86)\ATI > Technologies\ATI.ACE\Core-Static;C:\Program Files\Intel\WiFi\bin\;C:\Program > Files\Common Files\Intel\WirelessCommon\;C:\Program Files (x86)\Quest > Software\vWorkspace Client\pntsc.exe;C:\Program Files > (x86)\ibm\gsk8\lib;C:\Program Files (x86)\IBM\WebSphere MQ\bin;C:\Program > Files (x86)\IBM\WebSphere MQ\tools\c\samples\bin;C:\Program > Files\ibm\gsk8\lib64;C:\IBM\DB2_EX~1\BIN;C:\IBM\DB2_EX~1\FUNCTION;C:\IBM\DB2_EX~1\SAMPLES\REPL;C:\WINDOWS;C:\WinZip\WINZIP\WINZIP32.EXE;. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOMEE-2029) OpenEJB #finalize might kill a foreign container
Mark Struberg created TOMEE-2029: Summary: OpenEJB #finalize might kill a foreign container Key: TOMEE-2029 URL: https://issues.apache.org/jira/browse/TOMEE-2029 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.7.5 While tracking down a seemingly random TomEE bug in the DeltaSpike test suite I finally figured what the cause is. In 1.7.3 a 'cleanup logic' got introduced to ContextWrapper#finalize. Sadly this often kills the wrong instance! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TOMEE-2029) OpenEJB #finalize might kill a foreign container
[
https://issues.apache.org/jira/browse/TOMEE-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957596#comment-15957596
]
Mark Struberg commented on TOMEE-2029:
--
To be more precise the following line in the code is the problem why we must
not use the finalizer for killing the server:
{code}
SystemInstance.get().getComponent(Assembler.class);
{code}
This kills whatever is currently registered, even if the server got restarted 3
times for this very ClassLoader...
> OpenEJB #finalize might kill a foreign container
>
>
> Key: TOMEE-2029
> URL: https://issues.apache.org/jira/browse/TOMEE-2029
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
>Affects Versions: 1.7.4
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 1.7.5
>
>
> While tracking down a seemingly random TomEE bug in the DeltaSpike test suite
> I finally figured what the cause is. In 1.7.3 a 'cleanup logic' got
> introduced to ContextWrapper#finalize.
> Sadly this often kills the wrong instance!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TOMEE-2030) cdi-event-realm blows up with noSuchMethod in tomcat
Mark Struberg created TOMEE-2030: Summary: cdi-event-realm blows up with noSuchMethod in tomcat Key: TOMEE-2030 URL: https://issues.apache.org/jira/browse/TOMEE-2030 Project: TomEE Issue Type: Bug Components: Examples and Documentation Affects Versions: 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.7.5 cdi-event-realm blows up because it uses a manually set tomcat.version in maven. But this tomcat version has class conflicts with the much more recent one we use in the rest of TomEE. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOMEE-2034) Upgrade to latest OpenJPA-2.4.2
Mark Struberg created TOMEE-2034: Summary: Upgrade to latest OpenJPA-2.4.2 Key: TOMEE-2034 URL: https://issues.apache.org/jira/browse/TOMEE-2034 Project: TomEE Issue Type: Task Components: TomEE Core Server Affects Versions: 1.7.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 1.7.5 We currently ship an older OpenJPA-2.4.0 version. This should get updated for the 1.7.5 release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOMEE-2035) Upgrade TomEE 7 to OWB-1.7.3
Mark Struberg created TOMEE-2035: Summary: Upgrade TomEE 7 to OWB-1.7.3 Key: TOMEE-2035 URL: https://issues.apache.org/jira/browse/TOMEE-2035 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.3 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 7.0.4 OWB-1.7.3 just got released. gonna update -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TOMEE-2034) Upgrade to latest OpenJPA-2.4.2
[ https://issues.apache.org/jira/browse/TOMEE-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15967278#comment-15967278 ] Mark Struberg commented on TOMEE-2034: -- We might even ship OpenJPA-2.4.3 next week, so maybe worth waiting > Upgrade to latest OpenJPA-2.4.2 > --- > > Key: TOMEE-2034 > URL: https://issues.apache.org/jira/browse/TOMEE-2034 > Project: TomEE > Issue Type: Task > Components: TomEE Core Server >Affects Versions: 1.7.4 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 1.7.5 > > > We currently ship an older OpenJPA-2.4.0 version. This should get updated for > the 1.7.5 release. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOMEE-2035) Upgrade TomEE 7 to OWB-1.7.3
[ https://issues.apache.org/jira/browse/TOMEE-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2035. -- Resolution: Fixed > Upgrade TomEE 7 to OWB-1.7.3 > > > Key: TOMEE-2035 > URL: https://issues.apache.org/jira/browse/TOMEE-2035 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.3 > Reporter: Mark Struberg > Assignee: Mark Struberg > Fix For: 7.0.4 > > > OWB-1.7.3 just got released. gonna update -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TOMEE-2117) Rework ProcessObserverMethod integration
Mark Struberg created TOMEE-2117: Summary: Rework ProcessObserverMethod integration Key: TOMEE-2117 URL: https://issues.apache.org/jira/browse/TOMEE-2117 Project: TomEE Issue Type: Sub-task Affects Versions: 8.0.0 Reporter: Mark Struberg Fix For: 8.0.0 CdiPlugin.java contains code to fire ProcessObserverMethod. Since CDI-2.0 there are now 2 methods to change that ObserverMethod. Means we need to enhance the integration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOMEE-2115) TomEE-8 work
Mark Struberg created TOMEE-2115: Summary: TomEE-8 work Key: TOMEE-2115 URL: https://issues.apache.org/jira/browse/TOMEE-2115 Project: TomEE Issue Type: Task Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 This is an aggregator ticket for collecting tasks for the road to TomEE-8.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOMEE-2116) Create javaee-api-8.0.0
Mark Struberg created TOMEE-2116: Summary: Create javaee-api-8.0.0 Key: TOMEE-2116 URL: https://issues.apache.org/jira/browse/TOMEE-2116 Project: TomEE Issue Type: Sub-task Components: TomEE Build Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 The javaee-api has a completely separate lifecycle and even SCM location than the rest of tomee. You can find it at https://svn.apache.org/repos/asf/tomee/javaee-api/ The current trunk targets EE7 which will get moved to branches/ee7. There is already a branch which contains a 7.0-SNAPSHOT version. I suggest to remove this branch because it makes not much sense. Seems to have been a temporary feature branch on the road to EE7. So it's not needed any longer as this work got moved to trunk. After that trunk will be upgraded to various EE8 specs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOMEE-2096) randomly broken Test ReconnectDelayCaseInsensitiveTest
Mark Struberg created TOMEE-2096: Summary: randomly broken Test ReconnectDelayCaseInsensitiveTest Key: TOMEE-2096 URL: https://issues.apache.org/jira/browse/TOMEE-2096 Project: TomEE Issue Type: Bug Components: TomEE Build Affects Versions: 7.0.3 Environment: Linux FC25, Java8 Reporter: Mark Struberg RoundRobinConnectionStrategyTest.test:175->assertBalance:224 Expected 100 invocations, received 152 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TOMEE-2088) Broken Test: org.apache.openejb.itest.legacy.LegacyServerTest
[ https://issues.apache.org/jira/browse/TOMEE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2088: - Attachment: org.apache.openejb.itest.failover.RoundRobinConnectionStrategyTest.txt > Broken Test: org.apache.openejb.itest.legacy.LegacyServerTest > - > > Key: TOMEE-2088 > URL: https://issues.apache.org/jira/browse/TOMEE-2088 > Project: TomEE > Issue Type: Bug > Components: TomEE Build >Affects Versions: 7.0.3 > Environment: Linux 4.11.6-201.fc25.x86_64, Java8 1.8.0_131 > Reporter: Mark Struberg > Attachments: > org.apache.openejb.itest.failover.RoundRobinConnectionStrategyTest.txt > > > Test broken in org.apache.openejb.itest.legacy.LegacyServerTest > java.lang.AssertionError: 1 out of 1000 is too low > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.openejb.itest.legacy.LegacyServerTest.assertBalance(LegacyServerTest.java:226) > at > org.apache.openejb.itest.legacy.LegacyServerTest.test(LegacyServerTest.java:208) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TOMEE-2088) Broken Test: org.apache.openejb.itest.legacy.LegacyServerTest
[ https://issues.apache.org/jira/browse/TOMEE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080006#comment-16080006 ] Mark Struberg commented on TOMEE-2088: -- 2nd time all built fine. Means it's stochastic behaviour > Broken Test: org.apache.openejb.itest.legacy.LegacyServerTest > - > > Key: TOMEE-2088 > URL: https://issues.apache.org/jira/browse/TOMEE-2088 > Project: TomEE > Issue Type: Bug > Components: TomEE Build >Affects Versions: 7.0.3 > Environment: Linux 4.11.6-201.fc25.x86_64, Java8 1.8.0_131 > Reporter: Mark Struberg > > Test broken in org.apache.openejb.itest.legacy.LegacyServerTest > java.lang.AssertionError: 1 out of 1000 is too low > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at > org.apache.openejb.itest.legacy.LegacyServerTest.assertBalance(LegacyServerTest.java:226) > at > org.apache.openejb.itest.legacy.LegacyServerTest.test(LegacyServerTest.java:208) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TOMEE-2094) XAPoolTest failing randomly
[
https://issues.apache.org/jira/browse/TOMEE-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated TOMEE-2094:
-
Attachment: org.apache.openejb.resource.jdbc.XAPoolTest.txt
> XAPoolTest failing randomly
> ---
>
> Key: TOMEE-2094
> URL: https://issues.apache.org/jira/browse/TOMEE-2094
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Build
>Affects Versions: 7.0.3
> Environment: OSX, Java 8
> Reporter: Mark Struberg
> Attachments: org.apache.openejb.resource.jdbc.XAPoolTest.txt
>
>
> happens in trunk
> {noformat}
> Tests in error:
> XAPoolTest.check » Construction Error invoking factory method: public
> static o...
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2094) XAPoolTest failing randomly
Mark Struberg created TOMEE-2094:
Summary: XAPoolTest failing randomly
Key: TOMEE-2094
URL: https://issues.apache.org/jira/browse/TOMEE-2094
Project: TomEE
Issue Type: Bug
Components: TomEE Build
Affects Versions: 7.0.3
Environment: OSX, Java 8
Reporter: Mark Struberg
happens in trunk
{noformat}
Tests in error:
XAPoolTest.check » Construction Error invoking factory method: public static
o...
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Moved] (TOMEE-2090) Randomly broken Test in CDI TCK MessageDrivenBeanInterceptorInvocationTest
[
https://issues.apache.org/jira/browse/TOMEE-2090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg moved OWB-1198 to TOMEE-2090:
---
Key: TOMEE-2090 (was: OWB-1198)
Project: TomEE (was: OpenWebBeans)
> Randomly broken Test in CDI TCK MessageDrivenBeanInterceptorInvocationTest
> --
>
> Key: TOMEE-2090
> URL: https://issues.apache.org/jira/browse/TOMEE-2090
> Project: TomEE
> Issue Type: Bug
> Environment: Linux, FC25, Java8
>Reporter: Mark Struberg
>
> {noformat}
> [INFO] OpenEJB :: TCK :: Common ... SUCCESS [ 0.751
> s]
> [INFO] OpenEJB :: TCK :: CDI Embedded . FAILURE [04:12
> min]
> {noformat}
> {noformat}
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> INFORMATION - Invoke DecoratorTypeParamInitializerTest.testDeploymentFails:
> 1.479/1.479 Failed tests: 1 (644)
> INFORMATION - Stopping network services
> INFORMATION - Stopping server services
> INFORMATION - Destroying container system
> INFORMATION - Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB shutting
> down.
> INFORMATION - Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB paused.
> INFORMATION - Scheduler unregistered from name
> 'quartz:type=QuartzScheduler,name=OpenEJB-TimerService-Scheduler,instance=OpenEJB'
> in the local MBeanServer.
> INFORMATION - Scheduler OpenEJB-TimerService-Scheduler_$_OpenEJB shutdown
> complete.
> INFORMATION - Closing DataSource: jdbc
> INFORMATION - Closing DataSource: jdbcNonJta
> INFORMATION - Stopping ResourceAdapter: Default JMS Resource Adapter
> INFORMATION - Stopping ActiveMQ
> INFORMATION - Apache ActiveMQ 5.14.3 (localhost,
> ID:stehtnix-43855-1499679488155-0:1) is shutting down
> INFORMATION - Connector tcp://localhost.localdomain:35107 stopped
> INFORMATION - Connector vm://localhost stopped
> INFORMATION - Apache ActiveMQ 5.14.3 (localhost,
> ID:stehtnix-43855-1499679488155-0:1) uptime 4 minutes
> INFORMATION - Apache ActiveMQ 5.14.3 (localhost,
> ID:stehtnix-43855-1499679488155-0:1) is shutdown
> INFORMATION - Stopped ActiveMQ broker
> Tests run: 1479, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 250.712
> sec <<< FAILURE! - in TestSuite
> testMessageDrivenBeanMethodIntercepted(org.jboss.cdi.tck.tests.interceptors.definition.enterprise.jms.MessageDrivenBeanInterceptorInvocationTest)
> Time elapsed: 5.026 sec <<< FAILURE!
> java.lang.AssertionError: expected [true] but found [false]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertTrue(Assert.java:42)
> at org.testng.Assert.assertTrue(Assert.java:52)
> at
> org.jboss.cdi.tck.tests.interceptors.definition.enterprise.jms.MessageDrivenBeanInterceptorInvocationTest.testMessageDrivenBeanMethodIntercepted(MessageDrivenBeanInterceptorInvocationTest.java:92)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (TOMEE-2138) MockitoExtension.Bean must implement Prioritized
[
https://issues.apache.org/jira/browse/TOMEE-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved TOMEE-2138.
--
Resolution: Fixed
fixed in fb_tomee8
> MockitoExtension.Bean must implement Prioritized
>
>
> Key: TOMEE-2138
> URL: https://issues.apache.org/jira/browse/TOMEE-2138
> Project: TomEE
> Issue Type: Bug
>Affects Versions: 8.0.0
>Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 8.0.0
>
>
> The MockitoExtension.Bean is an Alternative.
> But according to a spec clarifications those manual Beans also need to either
> get activated via beans.xml or need to implement the Prioritized interface.
> I'd give them a prio of
> {code}
> @Override
> public int getPriority() {
> return Interceptor.Priority.PLATFORM_AFTER+1000;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2139) org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration
Mark Struberg created TOMEE-2139: Summary: org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration Key: TOMEE-2139 URL: https://issues.apache.org/jira/browse/TOMEE-2139 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.4 Reporter: Mark Struberg Assignee: Andy Gumbrecht Fix For: 8.0.0 Seems the latest change caused the ArchivingTest to break in OSX and Linux. java.lang.AssertionError org.apache.tomee.jul.handler.rotating.ArchivingTest.logAndRotateAndPurge(ArchivingTest.java:207) It only happens in the 2nd run (gzip). If I start gzip alone all works fine. So I assume that the delete event from the first run doesn't get consumed. And then later ends up as result in the 2nd run. Because that's what I get in the debugger: ENTRY_DELETE. I'm avail on IRC for hacking on it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TOMEE-2139) org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration
[ https://issues.apache.org/jira/browse/TOMEE-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2139: - Fix Version/s: 7.0.6 > org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration > --- > > Key: TOMEE-2139 > URL: https://issues.apache.org/jira/browse/TOMEE-2139 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg >Assignee: Andy Gumbrecht > Fix For: 8.0.0, 7.0.6 > > > Seems the latest change caused the ArchivingTest to break in OSX and Linux. > java.lang.AssertionError > org.apache.tomee.jul.handler.rotating.ArchivingTest.logAndRotateAndPurge(ArchivingTest.java:207) > It only happens in the 2nd run (gzip). > If I start gzip alone all works fine. > So I assume that the delete event from the first run doesn't get consumed. > And then later ends up as result in the 2nd run. > Because that's what I get in the debugger: ENTRY_DELETE. > I'm avail on IRC for hacking on it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TOMEE-2140) retire or fix arquillian-jpa example
Mark Struberg created TOMEE-2140:
Summary: retire or fix arquillian-jpa example
Key: TOMEE-2140
URL: https://issues.apache.org/jira/browse/TOMEE-2140
Project: TomEE
Issue Type: Task
Components: Examples and Documentation
Affects Versions: 7.0.4
Reporter: Mark Struberg
Fix For: 8.0.0
examples/arquillian-jpa is a sample for
{source}
org.jboss.arquillian.extension
arquillian-persistence-dbunit
{source}
in version 1.0.0-alpha-7.
But there was no newer version released ever.
This internally uses Arquillian-1.0.1. It is *not* compatible with newer
Arquillian versions.
So we should remove this sample.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TOMEE-2191) upgrade to OpenWebBeans-1.7.5
[ https://issues.apache.org/jira/browse/TOMEE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2191: - Issue Type: Dependency upgrade (was: Improvement) > upgrade to OpenWebBeans-1.7.5 > - > > Key: TOMEE-2191 > URL: https://issues.apache.org/jira/browse/TOMEE-2191 > Project: TomEE > Issue Type: Dependency upgrade > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > upgrade to OpenWebBeans-1.7.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2191) upgrade to OpenWebBeans-1.7.5
Mark Struberg created TOMEE-2191: Summary: upgrade to OpenWebBeans-1.7.5 Key: TOMEE-2191 URL: https://issues.apache.org/jira/browse/TOMEE-2191 Project: TomEE Issue Type: Improvement Components: TomEE Core Server Affects Versions: 7.0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 7.0.5 upgrade to OpenWebBeans-1.7.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2191) upgrade to OpenWebBeans-1.7.5
[ https://issues.apache.org/jira/browse/TOMEE-2191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2191. -- Resolution: Fixed > upgrade to OpenWebBeans-1.7.5 > - > > Key: TOMEE-2191 > URL: https://issues.apache.org/jira/browse/TOMEE-2191 > Project: TomEE > Issue Type: Dependency upgrade > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > upgrade to OpenWebBeans-1.7.5 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2153) Dependency upgrade to Johnzon 1.0.1
[ https://issues.apache.org/jira/browse/TOMEE-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2153. -- Resolution: Fixed > Dependency upgrade to Johnzon 1.0.1 > --- > > Key: TOMEE-2153 > URL: https://issues.apache.org/jira/browse/TOMEE-2153 > Project: TomEE > Issue Type: Dependency upgrade > Components: TomEE Arquillian Adapters, TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Alexandre Vermeerbergen > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > Hello, > We have several applications waiting to be migrated from TomEE+ 1.7.4 to > TomEE+ 7.x, but are impacted by the bug in Johnzon which was fixed with > JOHNZON-101. > Would it be possible to upgrade TomEE 7.0.5 dependency to at last Johnzon > 1.0.1 (or to higher Johnzon version, provided it includes JOHNZON-101) ? > *Edit:* please also make sure that this release includes fix for > https://issues.apache.org/jira/browse/JOHNZON-149 which is supposed to fix > the one which I opened: https://issues.apache.org/jira/browse/JOHNZON-160 > and we also need https://issues.apache.org/jira/browse/JOHNZON-158 to be > backported to Johnzon 1.0.1 that will be in TomEE 7.0.5 > Best regards, > Alexandre -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (TOMEE-2153) Dependency upgrade to Johnzon 1.0.1
[ https://issues.apache.org/jira/browse/TOMEE-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned TOMEE-2153: Assignee: Mark Struberg > Dependency upgrade to Johnzon 1.0.1 > --- > > Key: TOMEE-2153 > URL: https://issues.apache.org/jira/browse/TOMEE-2153 > Project: TomEE > Issue Type: Dependency upgrade > Components: TomEE Arquillian Adapters, TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Alexandre Vermeerbergen > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > Hello, > We have several applications waiting to be migrated from TomEE+ 1.7.4 to > TomEE+ 7.x, but are impacted by the bug in Johnzon which was fixed with > JOHNZON-101. > Would it be possible to upgrade TomEE 7.0.5 dependency to at last Johnzon > 1.0.1 (or to higher Johnzon version, provided it includes JOHNZON-101) ? > *Edit:* please also make sure that this release includes fix for > https://issues.apache.org/jira/browse/JOHNZON-149 which is supposed to fix > the one which I opened: https://issues.apache.org/jira/browse/JOHNZON-160 > and we also need https://issues.apache.org/jira/browse/JOHNZON-158 to be > backported to Johnzon 1.0.1 that will be in TomEE 7.0.5 > Best regards, > Alexandre -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2139) org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration
[ https://issues.apache.org/jira/browse/TOMEE-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2139: - Fix Version/s: (was: 7.0.6) 7.0.5 > org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration > --- > > Key: TOMEE-2139 > URL: https://issues.apache.org/jira/browse/TOMEE-2139 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg >Assignee: Andy Gumbrecht >Priority: Major > Fix For: 8.0.0, 7.0.5 > > > Seems the latest change caused the ArchivingTest to break in OSX and Linux. > java.lang.AssertionError > org.apache.tomee.jul.handler.rotating.ArchivingTest.logAndRotateAndPurge(ArchivingTest.java:207) > It only happens in the 2nd run (gzip). > If I start gzip alone all works fine. > So I assume that the delete event from the first run doesn't get consumed. > And then later ends up as result in the 2nd run. > Because that's what I get in the debugger: ENTRY_DELETE. > I'm avail on IRC for hacking on it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2195) Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer
[ https://issues.apache.org/jira/browse/TOMEE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515825#comment-16515825 ] Mark Struberg commented on TOMEE-2195: -- applied, thanks for the patch Gurkan! > Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer > > > Key: TOMEE-2195 > URL: https://issues.apache.org/jira/browse/TOMEE-2195 > Project: TomEE > Issue Type: Improvement > Components: TomEE Build, TomEE Core Server >Reporter: Gurkan Erdogdu > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > Attachments: TOMEE-2195.patch > > > In macOS with JDK 7 and JDK 8, AnnotationDeployer class generates a compile > time error regarding using generics. > Attached is the patch to fix compilation error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (TOMEE-2195) Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer
[ https://issues.apache.org/jira/browse/TOMEE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned TOMEE-2195: Assignee: Mark Struberg > Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer > > > Key: TOMEE-2195 > URL: https://issues.apache.org/jira/browse/TOMEE-2195 > Project: TomEE > Issue Type: Improvement > Components: TomEE Build, TomEE Core Server >Reporter: Gurkan Erdogdu > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > Attachments: TOMEE-2195.patch > > > In macOS with JDK 7 and JDK 8, AnnotationDeployer class generates a compile > time error regarding using generics. > Attached is the patch to fix compilation error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2195) Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer
[ https://issues.apache.org/jira/browse/TOMEE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2195. -- Resolution: Fixed > Compile Error in /src/main/java/org/apache/openejb/config/AnnotationDeployer > > > Key: TOMEE-2195 > URL: https://issues.apache.org/jira/browse/TOMEE-2195 > Project: TomEE > Issue Type: Improvement > Components: TomEE Build, TomEE Core Server >Reporter: Gurkan Erdogdu > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > Attachments: TOMEE-2195.patch > > > In macOS with JDK 7 and JDK 8, AnnotationDeployer class generates a compile > time error regarding using generics. > Attached is the patch to fix compilation error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2196) keyStoreFile Property is Empty in Embedded Container
[ https://issues.apache.org/jira/browse/TOMEE-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2196. -- Resolution: Fixed Assignee: Mark Struberg applied, thanks for the patch Gurkan! > keyStoreFile Property is Empty in Embedded Container > > > Key: TOMEE-2196 > URL: https://issues.apache.org/jira/browse/TOMEE-2196 > Project: TomEE > Issue Type: Improvement > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Gurkan Erdogdu > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > Attachments: TOMEE-2196.patch, TOMEE-2196_test.patch > > > keystoreFile property is ignored in connector. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2196) keyStoreFile Property is Empty in Embedded Container
[ https://issues.apache.org/jira/browse/TOMEE-2196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2196: - Fix Version/s: 8.0.0 > keyStoreFile Property is Empty in Embedded Container > > > Key: TOMEE-2196 > URL: https://issues.apache.org/jira/browse/TOMEE-2196 > Project: TomEE > Issue Type: Improvement > Components: TomEE Core Server >Affects Versions: 7.0.4 >Reporter: Gurkan Erdogdu >Priority: Major > Fix For: 8.0.0, 7.0.5 > > Attachments: TOMEE-2196.patch, TOMEE-2196_test.patch > > > keystoreFile property is ignored in connector. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2187) Upgrade to XBean 4.9
[ https://issues.apache.org/jira/browse/TOMEE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2187: - Summary: Upgrade to XBean 4.9 (was: Upgrade to XBean 4.8) > Upgrade to XBean 4.9 > > > Key: TOMEE-2187 > URL: https://issues.apache.org/jira/browse/TOMEE-2187 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Major > Fix For: 8.0.0, 7.0.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2187) Upgrade to XBean 4.9
[ https://issues.apache.org/jira/browse/TOMEE-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530337#comment-16530337 ] Mark Struberg commented on TOMEE-2187: -- And now it's even 4.9 > Upgrade to XBean 4.9 > > > Key: TOMEE-2187 > URL: https://issues.apache.org/jira/browse/TOMEE-2187 > Project: TomEE > Issue Type: Dependency upgrade >Reporter: Jonathan Gallimore >Assignee: Jonathan Gallimore >Priority: Major > Fix For: 8.0.0, 7.0.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2138) MockitoExtension.Bean must implement Prioritized
Mark Struberg created TOMEE-2138:
Summary: MockitoExtension.Bean must implement Prioritized
Key: TOMEE-2138
URL: https://issues.apache.org/jira/browse/TOMEE-2138
Project: TomEE
Issue Type: Bug
Affects Versions: 8.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 8.0.0
The MockitoExtension.Bean is an Alternative.
But according to a spec clarifications those manual Beans also need to either
get activated via beans.xml or need to implement the Prioritized interface.
I'd give them a prio of
{code}
@Override
public int getPriority() {
return Interceptor.Priority.PLATFORM_AFTER+1000;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TOMEE-2168) upgrade maven-bundle-plugin to more recent version
Mark Struberg created TOMEE-2168:
Summary: upgrade maven-bundle-plugin to more recent version
Key: TOMEE-2168
URL: https://issues.apache.org/jira/browse/TOMEE-2168
Project: TomEE
Issue Type: Bug
Components: TomEE Build
Affects Versions: 7.0.4, 8.0.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 8.0.0, 7.0.5
we use maven-bundle-plugin-2.3.7 which is known to not work properly on newer
jdks.
Causing random build errors like:
{noformat}
{{java.lang.ArrayIndexOutOfBoundsException: 18 at
aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:130) at
aQute.lib.osgi.Clazz.(Clazz.java:65) at
aQute.lib.osgi.Processor.analyzeJar(Processor.java:159)}}
{noformat}
Gonna upgrade to 3.3.0 which is a known-good version which works fine in many
projects
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (TOMEE-2168) upgrade maven-bundle-plugin to more recent version
[
https://issues.apache.org/jira/browse/TOMEE-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved TOMEE-2168.
--
Resolution: Fixed
> upgrade maven-bundle-plugin to more recent version
> --
>
> Key: TOMEE-2168
> URL: https://issues.apache.org/jira/browse/TOMEE-2168
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Build
>Affects Versions: 7.0.4, 8.0.0
> Reporter: Mark Struberg
> Assignee: Mark Struberg
>Priority: Major
> Fix For: 8.0.0, 7.0.5
>
>
> we use maven-bundle-plugin-2.3.7 which is known to not work properly on
> newer jdks.
> Causing random build errors like:
> {noformat}
> {{java.lang.ArrayIndexOutOfBoundsException: 18 at
> aQute.lib.osgi.Clazz.parseClassFile(Clazz.java:130) at
> aQute.lib.osgi.Clazz.(Clazz.java:65) at
> aQute.lib.osgi.Processor.analyzeJar(Processor.java:159)}}
> {noformat}
>
> Gonna upgrade to 3.3.0 which is a known-good version which works fine in many
> projects
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TOMEE-2169) Interceptor Bean injection does not work for EJBs
[ https://issues.apache.org/jira/browse/TOMEE-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16349376#comment-16349376 ] Mark Struberg commented on TOMEE-2169: -- committed in fb_tomee8 commit 039cc1da9858fd5cc36957 > Interceptor Bean injection does not work for EJBs > - > > Key: TOMEE-2169 > URL: https://issues.apache.org/jira/browse/TOMEE-2169 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0 > > > When injecting a Interceptor in a X interceptor class we currently blow up > with a class cast exception. > This happens e.g. during the new CDI-2.0 BuiltinMetadataSessionBeanTest, > although the problem also exists in 7.x already. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2169) Interceptor Bean injection does not work for EJBs
Mark Struberg created TOMEE-2169: Summary: Interceptor Bean injection does not work for EJBs Key: TOMEE-2169 URL: https://issues.apache.org/jira/browse/TOMEE-2169 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 When injecting a Interceptor in a X interceptor class we currently blow up with a class cast exception. This happens e.g. during the new CDI-2.0 BuiltinMetadataSessionBeanTest, although the problem also exists in 7.x already. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2167) add support for beans.xml
Mark Struberg created TOMEE-2167: Summary: add support for beans.xml Key: TOMEE-2167 URL: https://issues.apache.org/jira/browse/TOMEE-2167 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 CDI-2.0 introduced a feature to only pick up AnnotatedTypes with a scopes as CDI beans instead of picking up ALL classes as @Dependent scoped beans. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2165) remove tomcat repository as all is hosted via maven.a.o anyway
Mark Struberg created TOMEE-2165: Summary: remove tomcat repository as all is hosted via maven.a.o anyway Key: TOMEE-2165 URL: https://issues.apache.org/jira/browse/TOMEE-2165 Project: TomEE Issue Type: Bug Components: TomEE Build Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 We still have a tomcat-private-repository in tomee/pom.xml But this is imo not needed as all is hosted via the central Maven repo anyway -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2165) remove tomcat repository as all is hosted via maven.a.o anyway
[ https://issues.apache.org/jira/browse/TOMEE-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2165: - Affects Version/s: (was: 8.0.0) 7.0.4 > remove tomcat repository as all is hosted via maven.a.o anyway > -- > > Key: TOMEE-2165 > URL: https://issues.apache.org/jira/browse/TOMEE-2165 > Project: TomEE > Issue Type: Bug > Components: TomEE Build >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > We still have a tomcat-private-repository in tomee/pom.xml > But this is imo not needed as all is hosted via the central Maven repo anyway -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2165) remove tomcat repository as all is hosted via maven.a.o anyway
[ https://issues.apache.org/jira/browse/TOMEE-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2165. -- Resolution: Fixed Fix Version/s: (was: 8.0.0) 7.0.5 > remove tomcat repository as all is hosted via maven.a.o anyway > -- > > Key: TOMEE-2165 > URL: https://issues.apache.org/jira/browse/TOMEE-2165 > Project: TomEE > Issue Type: Bug > Components: TomEE Build >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 7.0.5 > > > We still have a tomcat-private-repository in tomee/pom.xml > But this is imo not needed as all is hosted via the central Maven repo anyway -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2170) LogTest is broken
[
https://issues.apache.org/jira/browse/TOMEE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16368632#comment-16368632
]
Mark Struberg commented on TOMEE-2170:
--
It's actually the following 3 tests. All of them have to do with missing a
scripted JAAS Realm it seems:
*
arquillian/arquillian-tomee-tests/arquillian-tomee-webprofile-tests/src/test/java/org/apache/openejb/arquillian/tests/securityejb/SecurityEJBPropagationTest.java
*
tomee/tomee-webaccess/src/test/groovy/org/apache/tomee/webaccess/test/units/LogTest.groovy
*
tomee/tomee-webaccess/src/test/groovy/org/apache/tomee/webaccess/test/units/ScriptingTest.groovy
> LogTest is broken
> -
>
> Key: TOMEE-2170
> URL: https://issues.apache.org/jira/browse/TOMEE-2170
> Project: TomEE
> Issue Type: Task
>Affects Versions: 8.0.0
>Reporter: Mark Struberg
>Priority: Major
>
> LogTest in tomee-webaccess seems to not use the configured LoginModule
> (JAASRealm).
>
> Wonder how this works at all as it does not contain any
> {{. There isn't even a }}web.xml.
>
> We should finally fix this test for a final 8.0.x release. But set to @Ignore
> for now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TOMEE-2170) LogTest is broken
Mark Struberg created TOMEE-2170:
Summary: LogTest is broken
Key: TOMEE-2170
URL: https://issues.apache.org/jira/browse/TOMEE-2170
Project: TomEE
Issue Type: Task
Affects Versions: 8.0.0
Reporter: Mark Struberg
Assignee: Romain Manni-Bucau
LogTest in tomee-webaccess seems to not use the configured LoginModule
(JAASRealm).
Wonder how this works at all as it does not contain any
{{. There isn't even a }}web.xml.
We should finally fix this test for a final 8.0.x release. But set to @Ignore
for now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (TOMEE-2139) org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration
[ https://issues.apache.org/jira/browse/TOMEE-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg reassigned TOMEE-2139: Assignee: Mark Struberg (was: Andy Gumbrecht) > org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration > --- > > Key: TOMEE-2139 > URL: https://issues.apache.org/jira/browse/TOMEE-2139 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > > Seems the latest change caused the ArchivingTest to break in OSX and Linux. > java.lang.AssertionError > org.apache.tomee.jul.handler.rotating.ArchivingTest.logAndRotateAndPurge(ArchivingTest.java:207) > It only happens in the 2nd run (gzip). > If I start gzip alone all works fine. > So I assume that the delete event from the first run doesn't get consumed. > And then later ends up as result in the 2nd run. > Because that's what I get in the debugger: ENTRY_DELETE. > I'm avail on IRC for hacking on it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2139) org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration
[ https://issues.apache.org/jira/browse/TOMEE-2139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519339#comment-16519339 ] Mark Struberg commented on TOMEE-2139: -- It seems there are still edge cases. https://ci.apache.org/builders/tomee-trunk-ubuntu/builds/927/steps/test/logs/stdio This still reports a failure. The original issue seems to have been that each test method started a new Thread in watch(). But those Threads never got killed. So we had 2 watcher Threads writing to the same static lastEvent variable. And depending on timing the cleanup of the first test might get recorded while the second test already runs. To avoid this situation I now shut down the first watcher thread via Thread.interrupt(). But probably we also need to wait until the thread really did die down before continuing with the 2nd test... > org.apache.tomee.jul.handler.rotating.ArchivingTest broken in 2nd iteration > --- > > Key: TOMEE-2139 > URL: https://issues.apache.org/jira/browse/TOMEE-2139 > Project: TomEE > Issue Type: Bug > Components: TomEE Core Server >Affects Versions: 7.0.4 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0, 7.0.5 > > > Seems the latest change caused the ArchivingTest to break in OSX and Linux. > java.lang.AssertionError > org.apache.tomee.jul.handler.rotating.ArchivingTest.logAndRotateAndPurge(ArchivingTest.java:207) > It only happens in the 2nd run (gzip). > If I start gzip alone all works fine. > So I assume that the delete event from the first run doesn't get consumed. > And then later ends up as result in the 2nd run. > Because that's what I get in the debugger: ENTRY_DELETE. > I'm avail on IRC for hacking on it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2224) update to apache-parent-21 for sha512
Mark Struberg created TOMEE-2224: Summary: update to apache-parent-21 for sha512 Key: TOMEE-2224 URL: https://issues.apache.org/jira/browse/TOMEE-2224 Project: TomEE Issue Type: Improvement Components: TomEE Build Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 We should update to apache-parent-21 to get sha512 create automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2224) update to apache-parent-21 for sha512
[ https://issues.apache.org/jira/browse/TOMEE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591354#comment-16591354 ] Mark Struberg commented on TOMEE-2224: -- committed, now waiting for CI and hope that all is still green ;) > update to apache-parent-21 for sha512 > - > > Key: TOMEE-2224 > URL: https://issues.apache.org/jira/browse/TOMEE-2224 > Project: TomEE > Issue Type: Improvement > Components: TomEE Build >Affects Versions: 8.0.0 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0 > > > We should update to apache-parent-21 to get sha512 create automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TOMEE-2224) update to apache-parent-21 for sha512
[ https://issues.apache.org/jira/browse/TOMEE-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved TOMEE-2224. -- Resolution: Fixed resolving. Please reopen if we broke something with the parent update. > update to apache-parent-21 for sha512 > - > > Key: TOMEE-2224 > URL: https://issues.apache.org/jira/browse/TOMEE-2224 > Project: TomEE > Issue Type: Improvement > Components: TomEE Build >Affects Versions: 8.0.0 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0 > > > We should update to apache-parent-21 to get sha512 create automatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2227) upgrade CXF to 3.2.6 and tomcat to 9.0.11
Mark Struberg created TOMEE-2227: Summary: upgrade CXF to 3.2.6 and tomcat to 9.0.11 Key: TOMEE-2227 URL: https://issues.apache.org/jira/browse/TOMEE-2227 Project: TomEE Issue Type: Improvement Components: TomEE Core Server Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 upgrade CXF to 3.2.6 and tomcat to 9.0.11 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TOMEE-2227) upgrade CXF to 3.2.6 and tomcat to 9.0.11
[ https://issues.apache.org/jira/browse/TOMEE-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591944#comment-16591944 ] Mark Struberg commented on TOMEE-2227: -- and johnzon to 1.1.8 > upgrade CXF to 3.2.6 and tomcat to 9.0.11 > - > > Key: TOMEE-2227 > URL: https://issues.apache.org/jira/browse/TOMEE-2227 > Project: TomEE > Issue Type: Improvement > Components: TomEE Core Server >Affects Versions: 8.0.0 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0 > > > upgrade CXF to 3.2.6 and tomcat to 9.0.11 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2197) openejb.xml does not work
Mark Struberg created TOMEE-2197: Summary: openejb.xml does not work Key: TOMEE-2197 URL: https://issues.apache.org/jira/browse/TOMEE-2197 Project: TomEE Issue Type: Bug Components: TomEE Core Server Affects Versions: 7.0.4 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0, 7.0.5 When declaring a deployment in openejb.xml or tomee.xml we scan sections. This contains a file= and a jar= attribute. The jar= does not work because it later gets overridden by the (often empty) file attribute. WORKAROUND: just use the file= attribute and be done Should be fixed nonetheless. And should issue a warning if both attributes are used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TOMEE-2231) update to Johnzon-1.1.9 and OWB-2.0.7
[ https://issues.apache.org/jira/browse/TOMEE-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated TOMEE-2231: - Summary: update to Johnzon-1.1.9 and OWB-2.0.7 (was: update to Johnzon-1.1.9) > update to Johnzon-1.1.9 and OWB-2.0.7 > - > > Key: TOMEE-2231 > URL: https://issues.apache.org/jira/browse/TOMEE-2231 > Project: TomEE > Issue Type: Task > Components: TomEE Core Server >Affects Versions: 8.0.0 > Reporter: Mark Struberg > Assignee: Mark Struberg >Priority: Major > Fix For: 8.0.0 > > > upgrade to Apache Johnzon-1.1.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TOMEE-2231) update to Johnzon-1.1.9
Mark Struberg created TOMEE-2231: Summary: update to Johnzon-1.1.9 Key: TOMEE-2231 URL: https://issues.apache.org/jira/browse/TOMEE-2231 Project: TomEE Issue Type: Task Components: TomEE Core Server Affects Versions: 8.0.0 Reporter: Mark Struberg Assignee: Mark Struberg Fix For: 8.0.0 upgrade to Apache Johnzon-1.1.9 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
