[GitHub] [tomee-site-generator] cesarhernandezgt commented on a diff in pull request #59: TOMEE-4186 - Updated donwload page with discontinued branches
cesarhernandezgt commented on code in PR #59: URL: https://github.com/apache/tomee-site-generator/pull/59#discussion_r1108723216 ## src/main/jbake/content/download.adoc: ## @@ -83,9 +83,9 @@ IMPORTANT: Note: Information on possible ways to migrate from `javax` to `jakart |https://www.apache.org/dyn/closer.cgi/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war[icon:download[] TomEE Webapp WAR] |7.1.4|25 Sep. 2020|29 MB |https://downloads.apache.org/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war.asc[icon:download[] PGP] https://downloads.apache.org/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war.sha512[icon:download[] SHA512] |=== -IMPORTANT: Note: TomEE 7.1.4 was released two years ago. New releases from this branch are **unlikely**, but we are open for contributors to step up and lead the efforts in fixing CVEs and updating dependencies. +IMPORTANT: This branch is discontinued. No upcoming releases are planned due to transitive dependencies reached their end of life. Review Comment: Agree. Thank you for the feedback @rzo1 . I'm pushing now the improved text. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: Backporting changes between 8.x, 9.x and 10.x
About the website message for discontinued branches, I created TOMEE-4186 for a proposal for the Download page that won't move (yet) the discontinued versions to the archive but instead marked them as discontinued branches. As Richard mentioned, having the discontinued version on the actual download page may create a false impression, so we can have two steps, first make clear on the download page the branches that are discontinued, and then after 3 or 6 months, we can move then to the archive section but keeping the discontinued text in the same way many milestones releases has the information on the archive page. El mié, 15 feb 2023 a las 2:54, Richard Zowalla () escribió: > Thanks for all the opionions and answers, so far. Here are my thoughts > on the branches: > > ## TomEE 10.x > > Happy to help - currently, I have a bit of work to do for my $$-job, > though, but hope to have some more time to work on it soon :-) > > ## TomEE 9.x > > I am fine to help maintaining this one for a short period of time > (until we have some a 10.x release) and fixing bugs, etc. (like the > *.exe issue yesterday). > > If we can't upgrade to Tomcat 10.1 without breaking the EE9.1 TCK, we > would need to volunteer time in Tomcat to maintain 10.0.x, which they > eol'ed a few months ago. I most likely won't have time for that as I > would like to focus on EE10. > > ## TomEE 8.x > > I am fine with the proposed date / strategy regarding transient > dependencies. > > Regarding CXF 3.5.x - I think, that it should be possible for EE8 to > upgrade. I have a related PR, which is sufficient to have a green > build, but don't know the TCK status for it [1]. > > I am also happy to help maintain this branch until we have an EE10 > release ready. > > ## TomEE 1.7.x / 7.0.x / 7.1.x > > It seems, that we have an agreement on marking 1.7.x and 7.1.x / 7.0.x > as discontinued. We currently have a note on the download page for these > versions: > > "Note: TomEE 1.7.5 was released five years ago. New releases from this > branch are unlikely, but we are open for contributors to step up and > lead the efforts in fixing CVEs and updating dependencies." > > We might need to make it a bit more clear though. I like the idea by > Jon to add a list of CVEs for each of the discontinued release lines. > We could even move these artifacts to a separate download page (not > archive!) and explicitly mention CVEs + unlikeliness of future > releases, so there isn't a false impression on the actual downloadpage, > that these artifacts are still maintained, etc. > > > [1] https://github.com/apache/tomee/pull/1010 > > > Am Dienstag, dem 14.02.2023 um 10:58 -0600 schrieb Cesar Hernandez: > > +1 working on maintaining TomEE 9 branch since currently is the > > only > > option users have to migrate to Jakarta namespaces with a TomEE GA > > version. > > > > +1 on TomEE 8 strategy to check transitive dependencies reaching EOL > > to > > analyze its life span. > > > > +1 on label TomEE 7.x and 1.7 as discontinued. > > > > > > > > > > > > > > > > > > El mar, 14 feb 2023 a las 5:03, Jonathan Gallimore (< > > jonathan.gallim...@gmail.com>) escribió: > > > > > I very much agree with specifying where you're willing to spend > > > your time, > > > as opposed to just what you'd like to see. > > > > > > - TomEE 10: I'm happy to contribute to the development of that as I > > > can. > > > I'm currently working on the concurrency changes needed for EE10. > > > - TomEE 9: I'm happy to contribute towards maintaining this until a > > > little > > > after TomEE 10 is released. If we discontinued this now, I think > > > users > > > would potentially avoid actually doing their migration from javax > > > to > > > jakarta. I don't see any way we can discontinue this until there is > > > a GA > > > TomEE 10 release. > > > - TomEE 8: I agree we need to determine what its lifespan is, and > > > this is > > > to a certain extent determined by all of the components we use. I > > > suspect > > > CXF may be tricky in this area - as 3.4.10 is the last 3.4 release, > > > and I'm > > > not sure what is involved in 3.5.x or it is suitable for EE8 etc. > > > If we > > > don't determine a lifespan for TomEE 8, there's a real danger that > > > people > > > will try and stick with it forever rather than migrate to newer > > > versions. > > > I'd be happy to help maintain this branch for a short time > > > - Older branches: I wouldn't want to contribute to these any more, > > > and > > > would be in favor of marking them as discontinued. > > > > > > The EOL policy you've suggested is really clear, and I think it > > > strikes a > > > reasonable balance with what's achievable from a maintenance > > > perspective, > > > while giving time for users to upgrade. While I don't necessarily > > > object to > > > releases from older branches, if there was a strong desire to do > > > so, I do > > > think the responsible thing to do is clearly list every single CVE > > > in each > > > library that hasn't
[GitHub] [tomee-site-generator] rzo1 commented on a diff in pull request #59: TOMEE-4186 - Updated donwload page with discontinued branches
rzo1 commented on code in PR #59: URL: https://github.com/apache/tomee-site-generator/pull/59#discussion_r1108721352 ## src/main/jbake/content/download.adoc: ## @@ -83,9 +83,9 @@ IMPORTANT: Note: Information on possible ways to migrate from `javax` to `jakart |https://www.apache.org/dyn/closer.cgi/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war[icon:download[] TomEE Webapp WAR] |7.1.4|25 Sep. 2020|29 MB |https://downloads.apache.org/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war.asc[icon:download[] PGP] https://downloads.apache.org/tomee/tomee-7.1.4/tomee-webapp-7.1.4.war.sha512[icon:download[] SHA512] |=== -IMPORTANT: Note: TomEE 7.1.4 was released two years ago. New releases from this branch are **unlikely**, but we are open for contributors to step up and lead the efforts in fixing CVEs and updating dependencies. +IMPORTANT: This branch is discontinued. No upcoming releases are planned due to transitive dependencies reached their end of life. Review Comment: Maybe: > This branch is discontinued. No upcoming releases are planned due to transitive dependencies reached their end of life, i.e. they might be affected by security vulnerabilities. Just to make it clear? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomee.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Connections to ActiveMQ brokers
One of the things I've been looking into recently is the number of
connections that TomEE will make to an ActiveMQ broker. If you consider an
application that has 10 Message Driven Beans, and another bean that sends
messages using a connection factory, that application when started will
make 20 connections to ActiveMQ - 10 for the connection pool, and an
additional connection for each message driven bean.
Conversely, I could create (and it occurs to me that I should) a Spring
application that listens on 10 destinations, sends messages from another
bean, and uses just 1 connection: a JMS connection is capable of managing
several sessions at the same time. At a small scale, the number of
connections isn't an issue, but if you have hundreds of applications
connecting to ActiveMQ, each making dozens of connections, this can become
a bit of a challenge.
There are some options around this:
* Have the MDBs use connections from the connection pool - this is already
possible using an activation property "ConnectionFactoryLookup", for
example:
# Do not start the embedded ActiveMQ broker
BrokerXmlConfig =
ServerUrl = tcp://localhost:61616
UserName system
Password manager
ResourceAdapter = MyJmsResourceAdapter
PoolMaxSize 10
PoolMinSize 0
ResourceAdapter = MyJmsResourceAdapter
activation.ConnectionFactoryLookup=MyJmsConnectionFactory
This means that the connections for the message driven beans will come from
the same pool as connections used to send messages, so you can at least
manage the full set. You'll still need at least + 1
connections in that pool, however.
* Override the resource adapter behaviour where connections are created.
Connections are made here:
https://github.com/apache/tomee/blob/main/container/openejb-core/src/main/java/org/apache/openejb/resource/activemq/jms2/TomEEManagedConnectionFactory.java#L67.
I hacked up some code to override makeConnection():
private final Map
physicalConnections = new HashMap<>();
@Override
public ActiveMQConnection makeConnection(ActiveMQConnectionRequestInfo
connectionRequestInfo, ActiveMQConnectionFactory connectionFactory) throws
JMSException {
ActiveMQConnection activeMQConnection = null;
if (singleton) {
synchronized (this) {
activeMQConnection =
physicalConnections.get(connectionRequestInfo);
if (activeMQConnection == null) {
activeMQConnection =
super.makeConnection(connectionRequestInfo, connectionFactory);
physicalConnections.put(connectionRequestInfo,
activeMQConnection);
}
}
} else {
activeMQConnection =
super.makeConnection(connectionRequestInfo, connectionFactory);
}
return activeMQConnection;
}
The idea here is that only one physical connection per
username/password/client ID combination would be created, and can be shared
by different sessions. I added a parameter to the connection factory called
"singleton" (perhaps needs a better name) to turn this behaviour on.
The good news is that broadly speaking, it does work - I'm working on some
itests, but unit tests and actually running TomEE and ActiveMQ look good.
Does anyone have any thoughts or reservations on this (or any specific
cases that ought to be tested)?
Jon
