[JBoss JIRA] (ELY-1410) Digest auth does not support nonce count, causing browsers to replay every request
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1410?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1410:
----------------------------------
Fix Version/s: 1.1.6.CR1
> Digest auth does not support nonce count, causing browsers to replay every request
> ----------------------------------------------------------------------------------
>
> Key: ELY-1410
> URL: https://issues.jboss.org/browse/ELY-1410
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 1.1.6.CR1
>
>
> The results in every single request being retried. This has two negative impacts. The extra request adds a round trip which hurts response time on high latency connections. Additionally large posts have double the bandwidth consumption and can be interpreted as failures. For example a 300 mb upload in the console would likely lead to the user assuming a hang.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9446) mvn idea:idea in parent pom giving error
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9446?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-9446.
----------------------------------
Resolution: Rejected
This is not something we support, and it sounds like a bug in the idea plugin anyway. Many of the development team use idea but it can directly import the project.
> mvn idea:idea in parent pom giving error
> ----------------------------------------
>
> Key: WFLY-9446
> URL: https://issues.jboss.org/browse/WFLY-9446
> Project: WildFly
> Issue Type: Feature Request
> Reporter: sujay hegde
> Assignee: Jason Greene
>
> [INFO] WildFly Test Suite: Integration - Smoke ............ SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 04:48 min
> [INFO] Finished at: 2017-10-16T18:37:36+05:30
> [INFO] Final Memory: 148M/388M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-idea-plugin:2.2.1: idea (default-cli) on project wildfly-clustering: Execution default-cli of goal org.apache.maven.plugins:maven-idea-plugin:2.2.1:idea failed.: NullPointerExcept ion -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e swit ch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please rea d the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutio nException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR] mvn <goals> -rf :wildfly-clustering
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (JGRP-2225) Allow for sending of message batches in JChannel and protocols
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/JGRP-2225?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on JGRP-2225:
-----------------------------------
yes it will be. If Infinispan receives a batch of reads or writes, we can handle the reads right away and send a batch with the responses.
> Allow for sending of message batches in JChannel and protocols
> --------------------------------------------------------------
>
> Key: JGRP-2225
> URL: https://issues.jboss.org/browse/JGRP-2225
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 5.0
>
>
> Currently, we receive messages and message batches, but we're not able to _send_ message batches. Investigate adding a {{JChannel.send(MessageBatch)}} and {{Protocol.down(MessageBatch)}}.
> The use case is that if we want to send 10 messages to the same destination, we currently send 10 messages. Because they're on the same thread, they;re _not_ likely to end up in the same batch.
> Sending a message batch down the stack ensures that all messages end up in the same message batch (unless the max bundle size is exceeded).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-5838) Use WildFly thread pools in Artemis
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5838?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-5838:
-----------------------------------
dev analysis: https://github.com/wildfly/wildfly/pull/10585
> Use WildFly thread pools in Artemis
> -----------------------------------
>
> Key: WFLY-5838
> URL: https://issues.jboss.org/browse/WFLY-5838
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created.
> WildFly could leverage that to inject these services so that their thread pools are managed by WildFly.
> We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension.
> The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools.
> {noformat}
> * server
> * bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service
> * scheduled-thread-pool -> for scheduled executor service
> {noformat}
> Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9453) JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9453?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos updated WFLY-9453:
----------------------------------------
Description:
Currently, I am looking at an application whose deployment time I am trying to optimize.
Not only Wildfly, but as well on Weblogic.
One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
I an exception takes place, the deployment fails.
And they also cound like official deployment time of the WAR application.
Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
Now for this application, whose deployment time I am trying to optimize, two things are clear:
(a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
(b) They should however not break application deployment or even count as cost of application deployment time.
Point (a) is something I will only attack at a later point in time, perhaps.
But point (b) is something I have now addressed and that brings me to this enhancement request.
In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
More Application life cycle events should be offered.
@Startup, @PostDeploy, @PreUndeploy
As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
But back onto topic.
For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
- Scanning Jars
- Preparing class loaders
- Bind EJBs to the JNDI tree
- Setup Managed Beans for the APP
- Invoking @Startup ejbs that are OK to be part of the deployment phase
- Initializing Mojarra
The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
In fact, it seems like there is an obvious need for this because.
if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
The documentation listed above, is not perfect.
it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
Then there are substancial differences on what happens on the Listener.
In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
And that they are highly application server specific.
In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
The @Startup @PreDestroy are clearly not enough, in my oppinion.
And the way to do what I have done should be made much simpler in the future.
It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
Many thanks for considering this request.
Final Note:
- On the topic of application deployment, It might be of interest to you to keep an eye on the progress of Mojarra on the following issue:
https://github.com/javaserverfaces/mojarra/issues/4298
Bootstrap cost of Mojarra, at least on wildfly is quite expensive for a pair of well indentified reasons. I suspect the same issues will exist on weblogic as well because the initialization algorithm of Mojarra does not change with app server. But I have not benchmarked it yet. So perhaps it is good that you guys keep an eye on the progress of this issue so that ona future edition of Wildfly a mojarra version with this bugfix could be included. It would help a lot.
was:
Currently, I am looking at an application whose deployment time I am trying to optimize.
Not only Wildfly, but as well on Weblogic.
One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
I an exception takes place, the deployment fails.
And they also cound like official deployment time of the WAR application.
Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
Now for this application, whose deployment time I am trying to optimize, two things are clear:
(a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
(b) They should however not break application deployment or even count as cost of application deployment time.
Point (a) is something I will only attack at a later point in time, perhaps.
But point (b) is something I have now addressed and that brings me to this enhancement request.
In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
More Application life cycle events should be offered.
@Startup, @PostDeploy, @PreUndeploy
As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
But back onto topic.
For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
- Scanning Jars
- Preparing class loaders
- Bind EJBs to the JNDI tree
- Setup Managed Beans for the APP
- Invoking @Startup ejbs that are OK to be part of the deployment phase
- Initializing Mojarra
The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
In fact, it seems like there is an obvious need for this because.
if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
The documentation listed above, is not perfect.
it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
Then there are substancial differences on what happens on the Listener.
In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
And that they are highly application server specific.
In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
The @Startup @PreDestroy are clearly not enough, in my oppinion.
And the way to do what I have done should be made much simpler in the future.
It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
Many thanks for considering this request.
> JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9453
> URL: https://issues.jboss.org/browse/WFLY-9453
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Nuno Godinho de Matos
> Priority: Optional
>
> Currently, I am looking at an application whose deployment time I am trying to optimize.
> Not only Wildfly, but as well on Weblogic.
> One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
> Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
> I an exception takes place, the deployment fails.
> And they also cound like official deployment time of the WAR application.
> Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
> Now for this application, whose deployment time I am trying to optimize, two things are clear:
> (a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
> (b) They should however not break application deployment or even count as cost of application deployment time.
> Point (a) is something I will only attack at a later point in time, perhaps.
> But point (b) is something I have now addressed and that brings me to this enhancement request.
> In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
> More Application life cycle events should be offered.
> @Startup, @PostDeploy, @PreUndeploy
> As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
> But back onto topic.
> For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
> - Scanning Jars
> - Preparing class loaders
> - Bind EJBs to the JNDI tree
> - Setup Managed Beans for the APP
> - Invoking @Startup ejbs that are OK to be part of the deployment phase
> - Initializing Mojarra
> The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
> In fact, it seems like there is an obvious need for this because.
> if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
> https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
> The documentation listed above, is not perfect.
> it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
> Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
> Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
> But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
> In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
> On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
> Then there are substancial differences on what happens on the Listener.
> In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
> On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
> On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
> The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
> And that they are highly application server specific.
> In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
> In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
> The @Startup @PreDestroy are clearly not enough, in my oppinion.
> And the way to do what I have done should be made much simpler in the future.
> It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
> And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
> Many thanks for considering this request.
> Final Note:
> - On the topic of application deployment, It might be of interest to you to keep an eye on the progress of Mojarra on the following issue:
> https://github.com/javaserverfaces/mojarra/issues/4298
> Bootstrap cost of Mojarra, at least on wildfly is quite expensive for a pair of well indentified reasons. I suspect the same issues will exist on weblogic as well because the initialization algorithm of Mojarra does not change with app server. But I have not benchmarked it yet. So perhaps it is good that you guys keep an eye on the progress of this issue so that ona future edition of Wildfly a mojarra version with this bugfix could be included. It would help a lot.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9453) JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-9453?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos updated WFLY-9453:
----------------------------------------
Description:
Currently, I am looking at an application whose deployment time I am trying to optimize.
Not only Wildfly, but as well on Weblogic.
One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
I an exception takes place, the deployment fails.
And they also cound like official deployment time of the WAR application.
Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
Now for this application, whose deployment time I am trying to optimize, two things are clear:
(a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
(b) They should however not break application deployment or even count as cost of application deployment time.
Point (a) is something I will only attack at a later point in time, perhaps.
But point (b) is something I have now addressed and that brings me to this enhancement request.
In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
More Application life cycle events should be offered.
@Startup, @PostDeploy, @PreUndeploy
As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
But back onto topic.
For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
- Scanning Jars
- Preparing class loaders
- Bind EJBs to the JNDI tree
- Setup Managed Beans for the APP
- Invoking @Startup ejbs that are OK to be part of the deployment phase
- Initializing Mojarra
The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
In fact, it seems like there is an obvious need for this because.
if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
The documentation listed above, is not perfect.
it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
Then there are substancial differences on what happens on the Listener.
In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
And that they are highly application server specific.
In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
The @Startup @PreDestroy are clearly not enough, in my oppinion.
And the way to do what I have done should be made much simpler in the future.
It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
Many thanks for considering this request.
was:
Currently, I am looking at an application whose deployment time I am trying to optimize.
Not only Wildfly, but as well on Weblogic.
One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
I an exception takes place, the deployment fails.
And they also cound like official deployment time of the WAR application.
Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
Now for this application, whose deployment time I am trying to optimize, two things are clear:
(a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
(b) They should however not break application deployment or even count as cost of application deployment time.
Point (a) is something I will only attack at a later point in time, perhaps.
But point (b) is something I have now addressed and that brings me to this enhancement request.
In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
More Application life cycle events should be offered.
@Startup, @PostDeploy, @PreDeploy
As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
But back onto topic.
For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
- Scanning Jars
- Preparing class loaders
- Bind EJBs to the JNDI tree
- Setup Managed Beans for the APP
- Invoking @Startup ejbs that are OK to be part of the deployment phase
- Initializing Mojarra
The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
In fact, it seems like there is an obvious need for this because.
if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
The documentation listed above, is not perfect.
it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
Then there are substancial differences on what happens on the Listener.
In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
And that they are highly application server specific.
In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
The @Startup @PreDestroy are clearly not enough, in my oppinion.
And the way to do what I have done should be made much simpler in the future.
It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
Many thanks for considering this request.
> JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
> ------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9453
> URL: https://issues.jboss.org/browse/WFLY-9453
> Project: WildFly
> Issue Type: Enhancement
> Components: EJB
> Affects Versions: 11.0.0.CR1
> Reporter: Nuno Godinho de Matos
> Priority: Optional
>
> Currently, I am looking at an application whose deployment time I am trying to optimize.
> Not only Wildfly, but as well on Weblogic.
> One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
> Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
> I an exception takes place, the deployment fails.
> And they also cound like official deployment time of the WAR application.
> Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
> Now for this application, whose deployment time I am trying to optimize, two things are clear:
> (a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
> (b) They should however not break application deployment or even count as cost of application deployment time.
> Point (a) is something I will only attack at a later point in time, perhaps.
> But point (b) is something I have now addressed and that brings me to this enhancement request.
> In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
> More Application life cycle events should be offered.
> @Startup, @PostDeploy, @PreUndeploy
> As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
> But back onto topic.
> For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
> - Scanning Jars
> - Preparing class loaders
> - Bind EJBs to the JNDI tree
> - Setup Managed Beans for the APP
> - Invoking @Startup ejbs that are OK to be part of the deployment phase
> - Initializing Mojarra
> The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
> In fact, it seems like there is an obvious need for this because.
> if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
> https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
> The documentation listed above, is not perfect.
> it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
> Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
> Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
> But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
> In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
> On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
> Then there are substancial differences on what happens on the Listener.
> In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
> On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
> On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
> The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
> And that they are highly application server specific.
> In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
> In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
> The @Startup @PreDestroy are clearly not enough, in my oppinion.
> And the way to do what I have done should be made much simpler in the future.
> It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
> And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
> Many thanks for considering this request.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9453) JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
by Nuno Godinho de Matos (JIRA)
Nuno Godinho de Matos created WFLY-9453:
-------------------------------------------
Summary: JEE @Startup is not sufficient - More Lifecycle phases should be supported naturally on JEE containers
Key: WFLY-9453
URL: https://issues.jboss.org/browse/WFLY-9453
Project: WildFly
Issue Type: Enhancement
Components: EJB
Affects Versions: 11.0.0.CR1
Reporter: Nuno Godinho de Matos
Priority: Optional
Currently, I am looking at an application whose deployment time I am trying to optimize.
Not only Wildfly, but as well on Weblogic.
One thing that was necessary to refactor to gain about 13 seconds on "official deloyment time" was the fact that the Application would have a @Startup EJB (ApplicationInitializerEagerIntializerEjb) that would fire some CDI events to have other Beans or EJBs observe the event and do on-startup eager initialization.
Now the @Startup EJBs have a very important charectristic, regardless of app server, they are part of the deployment phase.
I an exception takes place, the deployment fails.
And they also cound like official deployment time of the WAR application.
Then you have other aspects to them, such as depending on how the container is implementing their invocation, in Weblogic, for example, you will get swallowed exceptions and other sorts of interesting events.
Now for this application, whose deployment time I am trying to optimize, two things are clear:
(a) Many of the EagerIntialized components could infact be Lazyly initialized and no have anything to do with deployment time - this would be a second wave of refactoring.
(b) They should however not break application deployment or even count as cost of application deployment time.
Point (a) is something I will only attack at a later point in time, perhaps.
But point (b) is something I have now addressed and that brings me to this enhancement request.
In my oppion, the JEE standard must in the near future do much better than just offer developers the @Startup annotation as API to on startup eager logic.
More Application life cycle events should be offered.
@Startup, @PostDeploy, @PreDeploy
As well as some basic apis, that some times are need to know what application server is my code running on. Today, if an application needs to know where it is running, because it is compatible with multiple vendors. One has to come around with rabbit hat tricks, such as Looking a InitialContext() impplementation class, or any other obsucer approach.
But back onto topic.
For my particular use case, I would like that after Wildfly has gone through the deployment logic - that I would call real deployment logic:
- Scanning Jars
- Preparing class loaders
- Bind EJBs to the JNDI tree
- Setup Managed Beans for the APP
- Invoking @Startup ejbs that are OK to be part of the deployment phase
- Initializing Mojarra
The application server should facilitate application developers to have additional metadata (preferably via jboss-ejb3.xml to not force non JEE standard annotations into code) to support such needed additional life cycle event phases.
In fact, it seems like there is an obvious need for this because.
if we look at weblogic, as an example, for EAR applications, and EAR applications alone (big-fail) they do offer a weblogic-application.xml where one can create LifeCycleListeners that would get invoked, for example after deploy.
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/lifecycle.htm#WLPRG367
The documentation listed above, is not perfect.
it does not make it clearly explicit that your WAR application would be forced to be repackaged as an EAR just so that you could create your WeblogicLifecycleListner.
Nor does it mention that your META-INF file would be forced to have the so called "weblogic application version: v1" metadata in there, for the listener to not be ignored.
Nor does it mention that the listner you get does not Support any sort of CDI and it is a pure Pojo etc...
But you see the ground work of application deployment metadata, that is app server specific to support what I am saying.
In the end, my current approach to be able to know that an application has been deployed is similar on Wildfly and Weblogic.
On both cases, during the @Startup phase, what i am currently doing is registering a ManagedBeanEventListener, that taps into the appropriate ManagedBean, and will get a JMX notification when the deployment is finished.
Then there are substancial differences on what happens on the Listener.
In case of the Wildfly, I was easily able to reagister an ApplicationScoped bean as Listener that could invoke a @Local EJB to fire my CDI evets after deployment.
On Weblogic, I was having "class loading" chaos and was forced to Put a message on a Topic notifying that the post deploy phase has reached.
On weblogic, I also essentially had to hack my wayt to finding the right managed bean to this while on wildfly it was fairly simple to find the managed bean that would give me the notification that an application was deployed.
The main point is, that I do not think that Registering JMX Listeners and unregistering when their job is done is the most appropriate API to do such things.
And that they are highly application server specific.
In fact , I was starting to believe that in Weblogic I would have no other alrenative than bundle the application as an EAR and use their not so user friendly listneer mechanism to achieve the task - until I got lucy and found the right managed bean.
In my oppinion, I think it would be good if you guys could take into consideration the principle behind offering more LifeClye application events.
The @Startup @PreDestroy are clearly not enough, in my oppinion.
And the way to do what I have done should be made much simpler in the future.
It could start with a wildfly specific metadata approach, where an Application is allowed to register an @EJB to such life cycle phases via an existing deployment descriptor such like jboss-ejb3.xml.
And in the furue all JEE providers should harmonize their APIs for these life cycle events, so that one does not have to hack is way to do this.
Many thanks for considering this request.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9452) An easy way to configure EAP from an OpenShift ConfigMap
by Jeremy Davis (JIRA)
Jeremy Davis created WFLY-9452:
----------------------------------
Summary: An easy way to configure EAP from an OpenShift ConfigMap
Key: WFLY-9452
URL: https://issues.jboss.org/browse/WFLY-9452
Project: WildFly
Issue Type: Feature Request
Environment: OpenShift
Reporter: Jeremy Davis
Assignee: Jason Greene
It would be good to have a simple way of pulling configuration from an OpenShift ConfigMap so for example values for database drivers could be controlled from OpenShift. This would enable a better dev/test/qa/workflow
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months