i need to optimize the CQ5 lucene indexing configuration for my application.
I want to provide a custom search configuration but i struggle to really understand the default configuration.
Source: https://helpx.adobe.com/experience-manager/kb/SearchIndexingConfig.html)
First question:
Are the "include"-tags used in the default configuration correct?
For example:
The default configuration uses the tag "include" to include the Property "jcr:content/jcr:lastModified" for the nt:file-Aggregate
<aggregate primaryType="nt:file">
<include>jcr:content</include>
<include>jcr:content/jcr:lastModified</include>
</aggregate>
Compare this to the Jackrabbit wiki which uses the "include-property" for the exact same case. Source: http://wiki.apache.org/jackrabbit/IndexingConfiguration
<aggregate primaryType="nt:file">
<include>jcr:content</include>
<include-property>jcr:content/jcr:lastModified</include-property>
</aggregate>
I only can assume it doesn't matter but i can't find any source to confirm this.
Second question: for the nodeType "cq:PageContent" all properties of four levels are aggregated.
<aggregate primaryType="cq:PageContent">
<include>*</include>
<include>*/*</include>
<include>*/*/*</include>
<include>*/*/*/*</include>
</aggregate>
I assume that because of the aggregation all properties are indexed which are contained within these 4 levels.
Or do i must consider the index rules for the nodeType nt:base which basicly only includes properties which are matching the pattern ".:.".
<index-rule nodeType="nt:base">
<property nodeScopeIndex="false">analyticsProvider</property>
<property nodeScopeIndex="false">analyticsSnippet</property>
...
<property isRegexp="true">.*:.*</property>
</index-rule>
Best regards
The default configuration is ideed incorrect as confirmed by the Adobe CQ5 Support.
For the aggegate to work correctly properties must be included by the "include-property"-Tag
So the default search configuration (or atleast the documentation) is not correct https://helpx.adobe.com/experience-manager/kb/SearchIndexingConfig.html)
Related
I want to use the .car file on another server without using integration studio. So I want to be able to change the hostname and port dynamically using a configuration file. My endpoint URL has variables in it {uri.var.x} that's why I can't use $FILE:x to get the complete URL from file.properties.
I have already tried How to read a property injected from file.properties in WSO2 - micro integrator? but it did not work.
You can simply read the Property from the file and assign it to the variable you desire. Then use it in your Endpoint configurations.
<property expression="get-property('file', 'x')" name="uri.var.x"/>
You can store the values in a properties file called file.properties in the MI_HOME/conf folder and it will be loaded automatically. If you are using a different fileName you can pass it to the server startup script like -Dproperties.file.path=/home/dev/dev.properties. Then you can read them through a Property Mediator.
Further, if you want to construct the full URL from multiple properties you can use Xpath functions.
<property expression="concat('https://', get-property('file', 'host'), ':', get-property('file', 'port'))" name="uri.var.x" scope="default" type="STRING" />
If the properties are not picked from the default file, pass the file path like below.
sh micro-integrator.sh -Dproperties.file.path=./conf/file.properties
Update on WSO2 EI
It seems file scope is not supported in EI. But instead, you can read variables from Environment variables with get-property('env', 'NAME_OF_VARIABLE')
<property expression="concat('https://', get-property('env', 'host'), ':', get-property('env', 'port'))" name="uri.var.x" scope="default" type="STRING"/>
If you want to read them from a properties file, you can do something like the below. Assuming you have a properties file like below.
stockQuoteEP=http://localhost:9000/services/SimpleStockQuoteService
ycr=test1234
host=localycr
port=6676
Add the following script to integrator.sh to export the properties as environment variables. You can improve the script as you require.
while read line; do
echo "Exporting $line"
export $line
done < /home/wso2/wso2ei-6.6.0/conf/file.properties
Then in your integration read them as below.
<property expression="concat('https://', get-property('env', 'host'), ':', get-property('env', 'port'))" name="uri.var.x" scope="default" type="STRING"/>
Update 2 on File Scope in Property mediator
As Sanoj mentioned, file scope in the property mediator is only available from MI 4.0 onward vanilla packs. If you have a WSO2 subscription you can get it as an update for both MI and EI.
I have a WiX installer project that I'm creating where I'd like the installer to check to see if another application is already installed on the user's machine. If it is, then I'd like to set the install level of one of the features to "1", otherwise it should remain hidden (i.e. install level = 0). To find out where the application is installed, I first do a registry search:
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'/>
</Property>
You'll notice that the registry value that I end up getting is actually the directory of the installed application including the actual program name with extension (let's say myapp.exe). So, once I get the full path of the installed application, I check to see if the file exists:
<Property Id="MYAPPINSTALLED">
<DirectorySearch Id="CheckFileDir" Path="[MYAPPINSTALLFOLDER]" AssignToProperty="yes">
<FileSearch Id="CheckFile" Name="myapp.exe" />
</DirectorySearch>
</Property>
Now, what I would expect to see is that if the file actually exists in that location, then the Property called "MYAPPINSTALLED" would be set to 1, otherwise it would be 0. Then, when I setup my features I use something like this:
<Feature Id="ThirdPartyPlugins" Title="Third Party Plugins" Level="0">
<Condition Level="1">MYAPPINSTALLED</Condition>
<ComponentGroupRef Id="MyAppPlugin" />
</Feature>
However, when I run my installer the third party plugin feature is always hidden. I've enabled msi datalogging by setting the property like this:
<Property Id="MsiLogging" Value="voicewarmupx"/>
And when I check the log file I can definitely see that the MYAPPINSTALLFOLDER property gets changed to the correct file path when it does the registry search. However, if I search the log for the property MYAPPINSTALLED, then I can see the following:
AppSearch: Property: MYAPPINSTALLED, Signature: CheckFileDir
Action ended 15:55:06: AppSearch. Return value 1.
So, it looks like it worked, however it doesn't seem to ever set the Property to equal the search value. Am I doing something wrong? Can someone explain why my feature install level never gets set to 1 even though the application file exists?
Edit
Ok, after more debugging... I think the issue is that the directory search is trying to use a path that includes the file name and extension (i.e. C:/Program Files/MyApp/myapp.exe") instead of just the directory where the file comes from. This is because the registry search has the full path including the file name stored (but not just the install directory). If I do a directory search just using the correct absolute directory (not using the registry search) then the process works. So, my follow up question is... my Property MYAPPINSTALLFOLDER contains the full path with file name and extension. Is there a way to strip the file name and extension from this property so that I just have the proper directory name to search for?
You're checking to see if another application is installed but that's rather a long way around. Also, the file search returns a path, not zero or 1, but either way a full verbose log should tell you if the properties are being set. It might help if you could post the entire log somewhere rather than the parts you think are the only relevant ones. e.g. There's probably an AppSearch in the execute sequence for silent installs.
It's requently easier to do a single search for other applications that were installed with MSI packages in these ways:
If you know the other product's UpgradeCode (and version ranges if applicable) then add Upgrade/UpgradeVersion elements with onlydetect set to yes, and that search will set a property if the product is detected.
If you know (or can find out) the Component id of any of the relevant components from that other product, then you can use them in a WiX ComponentSearch. If you get the target property set then that component is installed. This post contains a couple of ways to find out component guids:
How to find out which application requires a certain assembly from GAC?
It's also puzzling that the AppSearch log extract you posted only refers to one property. The Directory/FileSearch is also an AppSearch, so if the MSI actually contains two searches in AppSearch there should be references to all the properties being set. Again, that's a reason to post the entire log and look in the MSI file for those searches. The RegLocator search is documnented to occur before the DRLocator, so why is there no MYAPPINSTALLFOLDER property in the AppSearch log entry? You're not on a 32-bit system are you? (noticing the win64 search).
Per the WiX documentation:
Use the AssignToProperty attribute to search for a file but set the outer property to the directory containing the file. When this attribute is set to yes, you may only nest a FileSearch element with a unique Id or define no child element [of the DirectorySearch].
I added the text in the brackets to make it more clear.
So, after reading this sentence a few times and cross referencing your WiX XML, I think I see what the problem is with your current WiX XML. You perform a separate registry search from the directory search. Instead, you should nest these. There are two ways to perform the search, depending on what you want to do. One way is to simply retrieve the registry value from the registry, and if the value exists, then you make the assumption that the feature's required application is installed, at which point you appropriately set a property that would enable hiding/showing the feature within your installer's feature selection tree. The other way is to actually find the file you're interested in, using the results of the registry search as the basis for the file search.
Below is the XML for just a registry search, which doesn't check that the file actually exists on disk. You're making the assumption that if this registry value exists, the file is installed and available.
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'/>
</Property>
<Property Id="SHOW_APP_FEATURE" Value="hidden" />
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<!-- If MYAPPINSTALLFOLDER is defined and contains any non-empty value, this
evaluates to TRUE; otherwise, it evaluates to FALSE.
-->
MYAPPINSTALLFOLDER
</SetProperty>
<!-- You could also be more explicit:
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<![CDATA[MYAPPINSTALLFOLDER <> ""]]>
</SetProperty>
-->
<Feature Id="MyAwesomeFeature" Title="My Awesome App Feature"
Display="[SHOW_APP_FEATURE]">
... <!-- Component/ComponentRefs go here -->
</Feature>
If you want to ensure that, even if the registry value exists in the registry, that the file it points to is 1) actually a file path; and 2) that the file actually exists on disk, then you need to perform a nested file search within a directory search, which itself is nested within a registry search. You would again need to use a SetProperty custom action to set a property that would enable the hiding/showing of the feature within your installer's feature selection tree. Here's the XML for this search:
<!-- Performing a FileSearch nested within a DirectorySearch,
which is itself nested within a RegistrySearch
This search twill ensure that the file exists on disk, and
if so, assign the full filename and path to the
MYAPPINSTALLFOLDER property.
-->
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'>
<DirectorySearch Id='InstallPathDirectory' AssignToProperty='yes'>
<FileSearch Id='InstallPathFile' Name='myapp.exe' />
</DirectorySearch>
</RegistrySearch>
</Property>
<Property Id="SHOW_APP_FEATURE" Value="hidden" />
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<!-- If MYAPPINSTALLFOLDER is defined and contains any non-empty value, this
evaluates to TRUE; otherwise, it evaluates to FALSE.
-->
MYAPPINSTALLFOLDER
</SetProperty>
<Feature Id="MyAwesomeFeature" Title="My Awesome App Feature"
Display="[SHOW_APP_FEATURE]">
... <!-- Component/ComponentRefs go here -->
</Feature>
This should allow you to accomplish what you're trying to achieve.
I would love to add support for Working Sets for my Eclipse plugin that used the Common Navigator framework.
In Eclipse bugzilla there is mention that this is supported
None of the online manuals for the Common Navigator explain how to do it
I do not know where to start even since there is no extension point for it, and the Working Set implementation classes are all "internal". I have a very basic navigator setup showing default project resources and some additional IFileSystem stuff implementing ITreeContentProvider.
You can get the working set manager using:
IWorkingSetManager manager = PlatformUI.getWorkbench().getWorkingSetManager();
and from that get the visible working sets with:
IWorkingSet [] workingSets = manager.getWorkingSets();
the members of a working set can be accessed with:
IAdaptable [] elements = workingSet.getElements();
so you could use the working sets list as the input for the tree viewer and adjust your tree content provider to deal with this.
In retrospect the following is a better solution. Instead of implementing ITreeContentProvider and traversing the working sets ourselves, we can reuse existing standard providers for the same content, which might work better.
You can use them like so:
<extension
point="org.eclipse.ui.navigator.viewer">
<viewerContentBinding
viewerId="rascal.navigator">
<includes>
<contentExtension pattern="org.eclipse.ui.navigator.resourceContent" />
<contentExtension pattern="org.eclipse.ui.navigator.resources.filters.*"/>
<contentExtension pattern="org.eclipse.ui.navigator.resources.linkHelper"/>
<contentExtension pattern="org.eclipse.ui.navigator.resources.workingSets"/>
</includes>
</viewerContentBinding>
In particular the org.eclipse.ui.navigator.resources.workingSets is what adds working sets capabilities to your navigator.
Adding your own content then becomes an issue of adding another content provider which ignores workingsets and projects and other kinds of resources which are already taken care of, e.g. like so:
<extension
point="org.eclipse.ui.navigator.navigatorContent">
<navigatorContent
activeByDefault="true"
contentProvider="org.rascalmpl.eclipse.navigator.NavigatorContentProvider"
id="org.rascalmpl.navigator.searchPathContent"
labelProvider="org.rascalmpl.eclipse.navigator.NavigatorContentLabelProvider"
name="Rascal search path"
priority="normal">
<triggerPoints>
<or>
<instanceof value="org.eclipse.core.resources.IResource"/>
</or>
</triggerPoints>
<possibleChildren>
<or>
<instanceof value="java.lang.Object"/>
</or>
</possibleChildren>
<actionProvider
class="org.rascalmpl.eclipse.navigator.NavigatorActionProvider"
id="org.rascalmpl.navigator.actions">
</actionProvider>
<commonSorter
class="org.rascalmpl.eclipse.navigator.Sorter">
</commonSorter>
</navigatorContent>
<commonWizard
type="new"
wizardId="rascal_eclipse.wizards.NewRascalFile">
<enablement></enablement>
</commonWizard>
<commonWizard
type="new"
wizardId="rascal_eclipse.projectwizard">
<enablement></enablement>
</commonWizard>
</extension>
and in the NavigatorContentProvider class we implement getElements and getChildren but only for our own additional content.
For simplicity, say I have a resource users. The HTTP call GET users/ returns a list of links to concrete users:
<users>
<link rel='user' href='/users/user/1/'/>
<link rel='user' href='/users/user/2/'/>
<link rel='user' href='/users/user/3/'/>
....
</users>
The result representation is described in a specific media type:
application/vnd.company.Users+xml
In our frontends, we want to display a table with all users. This means we need to be able to fetch user information to display, such as the name, gender, friends, ... I would like to avoid that we need a separate request for each user (GET /users/user/x/) to retrieve this information. In addition, some frontends will only display the name, while other frontends will display the name and his/her friends. And so on.
In essence, we are still returning users, but with extentions depending on what the frontend needs.
Which option would you choose? Why?
(1) Make GET users/ customizable via parameters such that the customizations are listed. Depending on the customizations , different media types might be returned, since the syntax of one version/combination might be very different than one of another version/combination:
GET users/ -> application/vnd.company.Users+xml
GET users/?fields=name,gender -> application/vnd.company.Users+xml
GET users/?fields=name,gender,friends -> application/vnd.company.UsersWithFriends+xml
(2) Different resources are created to distinguish different between media types. Parameters are still used for basic customizations covered by the media type. This gives:
GET users?fields=name -> application/vnd.company.Users+xml
GET users?fields=name,gender -> application/vnd.company.Users+xml
GET users_with_friends?fields=gender -> application/vnd.company.UsersWithFriends+xml
(3) The same as (1), but instead of parameters, the desired media type is set by the client in the Accept header. Customizable fields covered by the media type are still set via parameters:
GET users/?fields=name ACCEPT application/vnd.company.Users+xml
GET users/?fields=name,gender ACCEPT application/vnd.company.Users+xml
GET users/?fields=name,gender ACCEPT application/vnd.company.UsersWithFriends+xml
(4) Something else?
To answer my own question, I think that:
Solution (1) is very very wrong. The media type must not be dependant on parameters.
Solution (2) and (3) are more or less equal and up to preferences. I prefer (3) since this would not introduce an explosion of resources to be introduced. In addition, in essence we are still returning users. The only difference is the amount of information, reflected by different media types, that is returned. So one might argue that there is no real need to introduce new resources as done in (2).
Do you agree? What do you think?
(3) is surely the best using strict Media Type, but would require specific HTTP Request client and won't be accessible through basic URL open library or browser.
Why not using solution 1 with another extra parameter : names "expect" or "as".
ie:
users/?fields=name,gender&expect=application/vnd.company.Users+xml
users/?fields=name,gender&expect=application/vnd.company.UsersWithFriends+xml
This would be the same as ACCEPT solution but won't need very custom client library to forge the request.
However you'll have to parse the parameter to provide correct output (the (3) would also have this requirement for parsing the ACCEPT)
Personally, I'm not a fan of using query string parameters to allow clients to pick the data elements they wish to include in a representation. I find it makes it hard to optimize the server and it pollutes the cache with many overlapping variants. Also, you really shouldn't try and use conneg to select between representations that contain different sets of data. Conneg is really just for selecting the serialization format.
With the Hal media type you can approach this problem a bit differently. Consider a service with a root representation that looks like:
<resource rel="self"
href="http://example.org/userservice"
xmlns:us="http://example.org/userservice/rels">
<link rel="us:users" name="users" href="http://example.org/users">
<link rel="us:userswithfriends" href="http://example.org/userswithfriends">
</resource>
When you use hal, instead of using the media type documentation to describe your application domain, you can use link relations. In this case, the us:users link points to a document that contains a list of users. I know the namespace stuff looks a bit wierd, but it is not really being used as an XML namespace, just as way of making a Compact URI (CURIE). When you invent your own rel values, they need to be specified in the form of a URI to try and ensure uniqueness.
The list of users would look something like:
<resource rel="self"
href="http://example.org/users"
xmlns:us="http://example.org/userservice/rels">
<resource rel="us:user" name="1" href="/user/1">
<name>Bob</name>
<age>45</age>
<resource>
<resource rel="us:user" name="2" href="/user/2">
<name>Fred</name>
<age>Bill</age>
<resource>
</resource>
and 'us:userswithfriends' points to a different resource that contains the list of users with each user containing a list of friends.
<resource rel="self"
href="http://example.org/users"
xmlns:us="http://example.org/userservice/rels">
<resource rel="us:user" name="1" href="/user/1">
<name>Bob</name>
<resource rel="us:friend" name="1" href="/user/10">
<name>Sheila</name>
<resource>
<resource rel="us:friend" name="2" href="/user/74">
<name>Robert</name>
<resource>
<resource>
<resource rel="user" name="2" href="/user/2">
<name>Fred</name>
<resource rel="us:friend" name="1" href="/user/14">
<name>Bill</name>
<resource>
<resource rel="us:friend" name="2" href="/user/33">
<name>Margaret</name>
<resource>
<resource>
</resource>
With hal it is the documentation of your rels (us:users, us:friend) that decribes what data elements are allowed to exist in the resource element. You are free to embed all of the data of the resource, or more likely just a subset of the data. If the client wants to access a completely representation of the embedded resource then it can follow the provided link.
I have a solution that was created with NHib 1.2 which we're upgrading to NHib 3.0.
Our hbm file has the following property:
<property name="ContentId" column="ContentId" access="field.camelcase-underscore" />
The class doesn't have a ContentId property. This was working fine in NHib 1.2 but now we're getting getting the following exception:
Could not compile the mapping document: XXXX.Core.Domain.Video.hbm.xml ---> NHibernate.MappingException: Problem trying to set property type by reflection ---> NHibernate.MappingException: class Core.Domain.Video, Core, Version=1.0.0.29283, Culture=neutral, PublicKeyToken=null not found while looking for property: ContentId ---> NHibernate.PropertyNotFoundException: Could not find the property 'ContentId', associated to the field '_contentId', in class 'Core.Domain.Video'.
Why would this stop working? Is it still supported in NHib 3?
We have many many properties like this that we might need to add.
NHibernate greatly improved its error messaging and diagnostics in NH2.X and again in NH3.X. You are telling NHibernate that you have a property and you want to map it via field access to a field named by _camelCase convention. You don't have a property named ContentId and NHibernate is letting you know that you lied to it. :)
Try updating your mapping to:
<property name="_contentId" column="ContentId" access="field" />
You will need to update any HQL or Criteria queries to use _contentId rather than ContentId. Another option would be to add a private ContentId property.
I'd like to provide information which helped me answer this question:
http://groups.google.com/group/nhusers/browse_thread/thread/e078734a221c3c0c/ec8b873b385d4426?lnk=gst&q=field+camelcase+underscore#ec8b873b385d4426
In this link Fabio explains the same problem you are having like this:
This mapping
<property name="PositiveValue" access="field.camelcase-underscore" />
mean: For my property named "PositiveValue" you (NH) have to access to
the field; to discover which is the associated field you (NH) have to
use the strategy "camelcase-underscore".
If there is no property you can't use the accessor with a specific
strategy.
Which struck me as a little odd because it meant adding dummy, unused properties, just to make the nhibernate3 compiler happy. The underlying functionality is the same.