Is the property "health.config.enabled" still valid and being processed in current Spring Cloud?
If yes, where in the code it is being done?
The property is in the current official documentation and has worked well for me so far (in cloud clients).
But as a whole string, it cannot be found anywhere in the current source code (besides the doc source).
For me as a beginner, it was easy to find in the old version of ConfigClientAutoConfiguration.java
Recent version of ConfigClientAutoConfiguration.java does not contain that whole property name, although I guess it's still being processed but in a more abstract way that I don't understand yet. Thus I'd appreciate even a hint in the form of "what used to be done on line "#ConditionalOnProperty(value = "health.config.enabled", matchIfMissing = true)" before is now roughly done on line XY".
Thanks.
It is replaced by #ConditionalOnEnabledHealthIndicator("config") (see here).
From the javadoc for that annotation
Blockquote
#Conditional that checks whether a default health indicator is enabled. Matches if the value of the management.health.<name>.enabled
So the new property is management.health.config.enabled
Related
maybe someone can help me on this. I am trying to generate a document via the DocumentGenerator interface. All in all this works well, except that the DocumentGenerator does not replace the Report Constants with actual values (which are defined on the report package stereotype.
This is the general flow of the document creation code (which generally works):
var gen = Repository.CreateDocumentGenerator();
gen.SetProjectConstant("ReportName", "My Project");
gen.NewDocument(string.Empty);
gen.ReplaceField("ReportName", "My Project");
gen.InsertCoverPageDocument(tags[REPORT_COVERPAGE]);
gen.InsertBreak(DocumentBreak.breakPage);
gen.InsertTOCDocument(tags[REPORT_TOC]);
gen.InsertBreak(DocumentBreak.breakPage);
gen.DocumentPackage((int)nativeId, 0, template);
gen.SaveDocument(fileName, DocumentType.dtDOCX);
I tried ReplaceField and SetProjectConstant both and one at a time before and after calls to NewDocument/InsertCoverPageDocument:
Strangely there is one constant that is being replaced: ReportSummary.
When I run the document generator via "F8" all constants are being replaced correctly.
Other project constants are being replaced correctly.
I can reproduce the behaviour on EA v14.1.1429 and v12.0.1215.
Does someone have a hint for further troubleshooting? Thanks in advance!
========== UPDATE ==========
When I use ReplaceField at the end (before the actual call to SaveDocument the following Report Constants get replaced: {ReportTitle} and {ReportName}
I discovered some workaround: when I manually remove the predefined {Report~} constants from the template and re-add them as Project Constants, their values get replaced correctly.
I will examine this further and give an update as
I did some further investigation on this and came to the following conclusion and workaround (as I have received no comments or answers on this):
I deleted all references to ReportConstants in my EA templates and replaced them by ProjectConstants with the same name.
In my code where I want to generate the documentation I (re)set all ProjectConstants with the actual values via SetProjectConstant and additionally added a call to ReplaceField to replace the constants with the actual values.
The previous mentioned calls are inserted directly before the call to SaveDocument document.
tags.ForEach(t =>
{
if (string.IsNullOrWhiteSpace(t.Key)) return;
generator.SetProjectConstant(t.Key, t.Value);
generator.ReplaceField(t.Key, t.Value);
});
generator.SaveDocument(fileName, DocumentType.dtDOCX);
If someone comes up with a better resonse or explanation for the behaviour I am happy to accept this as answer.
I have also found that when you call ReplaceField on these project constants in a CoverPage template, the formatting defined in the template is overwritten. It seems that some of the SetProjectConstant calls actually set the values as you would expect, and the rest do not.. hence the need to call both sets of APIs.
I have application in Angularjs2, and developers have not been using ids into it. Now I have to implement the Protractor on same application. Is there anyway to implement the Protractor without using "absolute XPath"?
Thanks in advance!
Please find a huge range of locator-possibilities on the official Protractortest API Page
Every element on a page needs to be uniquely identifiable... else the page wouldn't work, no matter which technology. Therefore with the help of any of the above provided locator-possibilities you'll always find the element you're looking for.
And there is never a need for XPath, except for this only one. (though there is an parentElementArrayFinder introduced in the meantime, so not even that one exception is valid anymore)
UDPATE
If you could use XPath, you can for sure use CSS-Locators.
Here some examples for locators:
$('div.class#id[anyAttribute="anyValue"] div.child.somewhere-below-div-point-class')
element(by.cssContainingText('div[data-index="2"]', 'select this option'))
Or as a specific example the "Learn More" of the "Tree List" section of https://js.devexpress.com/ :
treeListSection = element(by.cssContainingText('div.tab-content h2', 'Tree List')).getDriver();
learnMoreBtn = treeListSection.element(by.cssContainingText('a.tab-button','Learn More'));
learnMoreBtn.click();
Those are just examples, but there is always a way to do it.
If you provide some example-HTML in your Question, I can direct you towards a solution.
UPDATE 2
For getting the Parent Web Element, one could use getDriver() as well
I'm seeing some very strange behavior with FileMaker 14. I'm using LayoutObjectNames for some required functionality. On the development system it's working fine. It returns the list of named objects on the layout.
I close the file, zip it up and send it to the client, and that required functionality isn't working. He sends the file back and I open it and get a data viewer up. The function returns nothing. I go into layout mode and confirm that there are named objects on the layout.
The first time this happened and I tried recovering the file. In the recovered file it worked, so I assumed some corruption had happened on his end. I told him to trash the file I had given him and work with a new version I supplied. The problem came up again.
This morning he sent me the oldest version that the problem manifested in. I confirmed the problem, tried recovering it again, but this time it didn't fix the problem.
I'm at a loss. It works in the version I send him, doesn't on his system. We're both using FileMaker 14, although I'm using Advanced. My next step will be to work from a served file instead of a local one, but I have never seen this type of behavior in FileMaker. Has anyone seen anything similar? Any ideas on a fix? I'm almost ready to just scrap the file and build it again from scratch since we're not too far into the project.
Thanks, Chuck
There is a known issue with the Get (FileName) function when the file name contains dots (other that the one before the extension). I will amend my answer later with more details and a possible solution (I have to look it up).
Here's a quote from 2008:
This is a known issue. It affects not only the ValueListItems()
function, but any function that requires the file name. The solution
is to include the file extension explicitly in the file name. This
works even if you use Get (FileName) to return the file name
dynamically:
ValueListItems ( Get ( FileName ) & ".fp7" ; "MyValueList" )
Of course, this is not required if you take care not to use period
when naming your files.
http://fmforums.com/forums/topic/60368-fm-bug-with-valuelistitems-function/?do=findComment&comment=285448
Apparently the issue is still with us - I wonder if the solution is still the same (I cannot test this at the moment).
I'm using toLocalizedTime to output a date, as below
<span tal:content="python:here.toLocalisedTime(date.get('start_date'))"/>
This outputs eg. 2007/08/02, I'm just curious as to how one would alter the output so that it reads 02/08/2007
I'm not having much luck finding much info on toLocalizedTime, would someone point me in the right direction?
This depends on whether you have English selected as the site language (Site Setup >> Language). If so, then the default settings are used. You can change the defaults by dropping down into the ZMI, then into 'portal_properties', then 'site_properties'. The fields to change are either 'localTimeFormat' or 'localLongTimeFormat' depending on whether you pass in 'long_format=1' to the toLocalisedTime function.
If on the other hand, you have translations set up, the format may instead be pulled from the translation file for the locale selected. I'm not sure what is the easy way to change the format in this case (other than switching the site back to English). I guess you can register your own translation file but I've never needed to do that so you're going to have to look up the details.
Date string formatting follows the Python rules (http://docs.python.org/library/time.html#time.strftime).
Perhaps even more detail than you need:
here.toLocalizedTime()
is defined in the plone browser view at...
CMFPlone/browser/ploneview.py
which looks up the 'translation_service' utility, to call its 'ulocalized_time' function, defined at...
CMFPlone/TranslationServiceTool.py
which itself calls the 'ulocalized_time' function defined at...
CMFPlone/i18nl10n.py
As always, you can learn interesting things by grepping the source code ;-)
For an up to date answer for Plone 4.3 (after going through the source code)
These fields are now in the registry found at:
http://localhost:8080/yoursite/portal_registry
Then filter on "i18nl10n", which should give you the 4 fields you need to change.
I tried using aegis -change_attributes to change the brief_description of my current change set but it didn't work.
aegis -change_attributes description="test"
What should I do to make this work?
EDIT: The command I was looking for was
aegis -change_attributes brief_description="$DESC";
Since no answer was given (for quite some time) I'm adding the solution I gave in the comments, as the anser:
The above command is correct if you want to set the extensive description. If one wants to just set the brief description "aegis -change_attributes brief_description="$DESC"" has to be used