[JBoss JIRA] (WFCORE-87) Display deployment timestamp
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFCORE-87:
----------------------------------------
Here's the requirement from EAP6-223:
- When an application is Deployed/Undeployed or Enabled/Disabled then there should be some mechanism in order to track the timestamp of these events using some CLI commands.
- This will help in tracking when last time the application was enabled/disabled/deployed/undeployed.
So, I believe we need to provide the undeploy time as well. The deploy time is undefined if the thing isn't deployed, and vice versa.
I think this should provide both a long value (for machines to use) and a formatted value.
If a deployment isn't enabled at boot, we don't know the 'undeployed" time, so both the deployed and undeployed time are undefined.
> Display deployment timestamp
> ----------------------------
>
> Key: WFCORE-87
> URL: https://issues.jboss.org/browse/WFCORE-87
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Minor
>
> Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBAS-9545) AS7: HttpSession sharing between WAR modules (Clone)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/JBAS-9545?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated JBAS-9545:
-----------------------------------
Assignee: (was: Brian Stansberry)
> AS7: HttpSession sharing between WAR modules (Clone)
> ----------------------------------------------------
>
> Key: JBAS-9545
> URL: https://issues.jboss.org/browse/JBAS-9545
> Project: Application Server 3 4 5 and 6
> Issue Type: Feature Request
> Components: Clustering, Web (Tomcat) service
> Affects Versions: Open To Community
> Reporter: Avner Linder
> Fix For: No Release
>
>
> Creating a redacted version of JBAS-1909, which was opened as a non-public JIRA issue by a customer.
> Our J2EE application is composed of several modules, each one addressing one facet of our business process, and currently this application has one web module (WAR) and several JAR modules (EJB).
> We need to divide this web module into several smaller web modules.
> In order to separate our unique WAR file into several WARs we must guarantee HttpSession sharing. This is due to the fact that we have a lot of session attributes that are used throughout the entire application and we cannot afford to refactor the application, in fact, that's impossible.
> The security aspects for this requirement are completely addressed by the JBoss/Tomcat Single Sign-On mechanism but the session sharing requirements are not.
> The ideal scenario is to keep the same HttpSession (same object in the heap, same session ID) when authenticating into one application (HttpSession created) and then forwarding to another application.
> The current SSO mechanism allows the user to access the second application without reauthentication, as you know, but it creates a new HttpSession object. Also, if the two WARs have different session timeouts, if you access application A, migrates to application B, stays there until session in application A expires and then returns to application A from application B, a new HttpSession is also created in application A.
> The ideal solution is to have one unique, monolithic session to all web applications configured to share a common session. IBM WebSphere and BEA WebLogic do have this configuration and feature. Please check the links below in case you want more information:
> WebSphere Application Server V5: Sharing Session Context - http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0215.ht...
> BEA Weblogic - Enabling Web applications to share the same session - http://e-docs.bea.com/wls/docs90/webapp/sessions.html
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JBMETA-373) [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/JBMETA-373?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved JBMETA-373.
-------------------------------------
Fix Version/s: 7.0.9.Final
Resolution: Done
> [backport JBMETA-371] DefaultPropertyReplacer + PropertyResolver is broken for vault expressions
> ------------------------------------------------------------------------------------------------
>
> Key: JBMETA-373
> URL: https://issues.jboss.org/browse/JBMETA-373
> Project: JBoss Metadata
> Issue Type: Bug
> Components: common
> Affects Versions: 7.0.4.Final
> Reporter: Chris Dolphy
> Assignee: Brian Stansberry
> Fix For: 7.0.9.Final
>
>
> The DefaultPropertyReplacer + PropertyResolver algorithm is broken for vault expressions. It's based on the assumption that the contents of the expression string between "${" and "}" have a fixed format a la the old JBoss AS system properties (e.g. propertyname[: default value]) and then the PropertyResolver tries to resolve "propertyname".
> This is incorrect in the case of vault expressions, which do not follow this format. In particular the ":" char appears multiple places in a vault expression and does not serve as a delimiter between "propertyname" and "default value".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-88) Management interface to track (timestamp) when an application was last deployed.
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-88:
--------------------------------------
Summary: Management interface to track (timestamp) when an application was last deployed.
Key: WFCORE-88
URL: https://issues.jboss.org/browse/WFCORE-88
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
- When an application is Deployed/Undeployed or Enabled/Disabled then there should be some mechanism in order to track the timestamp of these events using some CLI commands.
- This will help in tracking when last time the application was enabled/disabled/deployed/undeployed.
I have some reservations about this as it's not clear why these management resources should be treated differently from other resources in terms of showing this kind of information about their history. But there's user demand for it and Claudio Miranda is doing good work on implementing it, so I'm fine with it.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (JGRP-1877) System.nanoTime() can be negative
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ]
David Lloyd commented on JGRP-1877:
-----------------------------------
Nope. If a thread is interrupted once, then interrupt state must persist until the thread pool's root method clears it. That's the contract of interruption. The reason it is this way is that you can have a stack 1000 levels deep, and 10 people can be using interruption for 10 different purposes. You cannot know if interruption is intended for you or not. This is why things which use interrupt also employ additional "exit" or "terminate" flags, though having such a flag set *still* does not mean you can assume that an interrupt was meant for you because each party might separately interrupt the same thread for different purposes. Only the root thread task itself has suitable information and position to safely clear the interrupt state of the thread.
> System.nanoTime() can be negative
> ---------------------------------
>
> Key: JGRP-1877
> URL: https://issues.jboss.org/browse/JGRP-1877
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5.1, 3.6
>
>
> According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future.
> Code like the one below might fail:
> {code:title=Responses.waitFor()|borderStyle=solid}
> public boolean waitFor(long timeout) {
> long wait_time;
> final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns
> lock.lock();
> try {
> while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
> try {
> cond.await(wait_time,TimeUnit.NANOSECONDS);
> }
> catch(InterruptedException e) {
> }
> }
> return done;
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> When computing {{target_time}}, {{System.nanoTime()}} could return a negative value (numeric overflow) or a value in the future. In the first case, {{target_time}} could be negative, so the method would not block at all. In the latter case, {{target_time}} could be huge, so the method would block for a long time.
> Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-87) Display deployment timestamp
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ]
Claudio Miranda edited comment on WFCORE-87 at 9/5/14 10:53 AM:
----------------------------------------------------------------
Add it as runtime attribute in CLI, later I will do it in HAL, see the result
{code}
[standalone@localhost:9990 /]
/deployment=jboss-helloworld.war:read-resource(include-aliases=true,include-defaults=true,include-runtime=true,recursive=true)
{
"outcome" => "success",
"result" => {
"content" => [{"hash" => bytes {
0x56, 0xf2, 0xe5, 0xb5, 0x7c, 0x78, 0x20, 0x7b,
0x6e, 0x42, 0x88, 0x2c, 0x94, 0xf9, 0x94, 0x11,
0x63, 0x44, 0xe2, 0xac
}}],
"enabled" => false,
"name" => "jboss-helloworld.war",
"persistent" => true,
"runtime-name" => "jboss-helloworld.war",
"status" => "STOPPED",
"timestamp" => "Fri Sep 05 00:42:19 BRT 2014",
"subdeployment" => undefined,
"subsystem" => undefined
}
}
{code}
was (Author: claudio4j):
Add it as runtime attribute in CLI, later I will do it in HAL, see the result
[standalone@localhost:9990 /]
/deployment=jboss-helloworld.war:read-resource(include-aliases=true,include-defaults=true,include-runtime=true,recursive=true)
{
"outcome" => "success",
"result" => {
"content" => [{"hash" => bytes {
0x56, 0xf2, 0xe5, 0xb5, 0x7c, 0x78, 0x20, 0x7b,
0x6e, 0x42, 0x88, 0x2c, 0x94, 0xf9, 0x94, 0x11,
0x63, 0x44, 0xe2, 0xac
}}],
"enabled" => false,
"name" => "jboss-helloworld.war",
"persistent" => true,
"runtime-name" => "jboss-helloworld.war",
"status" => "STOPPED",
"timestamp" => "Fri Sep 05 00:42:19 BRT 2014",
"subdeployment" => undefined,
"subsystem" => undefined
}
}
> Display deployment timestamp
> ----------------------------
>
> Key: WFCORE-87
> URL: https://issues.jboss.org/browse/WFCORE-87
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha5
> Reporter: Claudio Miranda
> Assignee: Brian Stansberry
> Priority: Minor
>
> Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-87) Display deployment timestamp
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFCORE-87?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFCORE-87:
---------------------------------------
Add it as runtime attribute in CLI, later I will do it in HAL, see the result
[standalone@localhost:9990 /]
/deployment=jboss-helloworld.war:read-resource(include-aliases=true,include-defaults=true,include-runtime=true,recursive=true)
{
"outcome" => "success",
"result" => {
"content" => [{"hash" => bytes {
0x56, 0xf2, 0xe5, 0xb5, 0x7c, 0x78, 0x20, 0x7b,
0x6e, 0x42, 0x88, 0x2c, 0x94, 0xf9, 0x94, 0x11,
0x63, 0x44, 0xe2, 0xac
}}],
"enabled" => false,
"name" => "jboss-helloworld.war",
"persistent" => true,
"runtime-name" => "jboss-helloworld.war",
"status" => "STOPPED",
"timestamp" => "Fri Sep 05 00:42:19 BRT 2014",
"subdeployment" => undefined,
"subsystem" => undefined
}
}
> Display deployment timestamp
> ----------------------------
>
> Key: WFCORE-87
> URL: https://issues.jboss.org/browse/WFCORE-87
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 1.0.0.Alpha5
> Reporter: Claudio Miranda
> Assignee: Jason Greene
> Priority: Minor
>
> Display the deployment timestamp, that is the date of last modified deployment. It is useful for users to see the date and time of deployments.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month