If using the Clearcase Remote client and have a View (View1) created against Server1, is it possible to change the view's configuration so that View1 uses Server2?
Not easily (it would involve a mktag -view, which can be done only on CCRC Server2, since rcleartool doesn't include that command).
It is best to create a second view, using server2, with the same config spec as the first view.
Related
I am using Oracle XE 18 with APEX 19.1 installed via EPG.
The only way to access the workspace login page is by locating the additional path /apex.
Is there a way to access/redirect/change the workspace login page (or a specific application) to the root of the hostname - such as http://localhost instead of http://localhost/apex ?
PS.: I am using Windows
The out of the box answer is: no
With APEX you need that, it can be changed to something like /app or similar.
If it was a deal breaker you can always front that APEX with a proxy that forwards the calls, one that comes to mind is nginx but its not perfect, something like an F5-like device can do the redirection pretty smoothly.
For Windows in particular you can try the DNS service which allows you to define some forwarding rules but I sincerely don't know how far you can go with this approach.
I suggest you choose /a or similar (instead of /apex) and save yourself a ton of problems and headaches. What you want doesn't exist, it was not designed to do that.
Yes that is possible but to do this you need a network layer, a network layer can be a firewall or web server(apache/glassfish). So in my case i use glassfish. You can specify redirect properties on glassfish config file domain.xml like this:
<virtual-server network-listeners="http-listener-1" id="server">
<property name="redirect_1" value="from= url-prefix=/apex/"></property>
<property name="redirect_2" value="from=/my_app_name url-prefix=/apex/f?p=my_number_app"></property>
</virtual-server>
So the first property as the rule you need to redirect /apex to /.
The second property you can use to redirect any application to a route name.
i have two ODI instances installed on the same machine with the same home directory.
i am trying to import scenarios using ./startcmd.sh command and it is working but it is always deploy the scenario to instance1.
the question is where i can redirect the deployment to instance2 instead of instance1?
are there any properties file or something else providing that ?
A scenario is not imported into an instance / path on the machine. It's imported in a work repository in a database.
OdiImportScen does not have a parameter to specify the repository in which you want to import.
Instead you can use OdiImportObject and specify the WORKREPNAME parameter.
We have a number of (developer) existDb database servers, and some staging/production servers.
Each have their own configuration, that are slightly different.
We need to select which configuration to load and use in queries.
The configuration is to be stored in an XML file within the repository.
However, when syncing the content of the servers, a single burnt-in XML file is not sufficient, since it is overwritten during copying from the other server.
For this, we need the physical name of the actual database server.
The only function found, request:get-server-name that is not quite stable since a single eXist server can be accessed through a number of various (localhost, intranet or external) URLs. However, that leads to unnecessary duplication of the configuration, one for each external URL...
(Accessing some local files in the file system is not secure and not fast.)
How to get the physical name of the existDb server from XQuery?
I m sorry but I don't fully understand your question, are you talking about exist's default conf.xml or your own configuration file that you need to store in a VCS repo? Should the xquery be executed on one instance and trigger an event in all others, or just some, or...? Without some code it is difficult to see why and when something gets overwritten.
you could try console:jmx-token which does not vary depending on URL (at least it shouldn't)
Also you might find it much easier to use a docker based approach. Either with multiple instances coordinated via docker-compose or to keep the individual configs from not interfering with each other when moving from dev to staging to production https://github.com/duncdrum/exist-docker
If I understand correctly, you basically want to be able to get the hostname or the IP address of a server from XQuery. If the functions in the XQuery Request module are not doing as you wish, then another option would be to set a Java System Property when starting eXist-db. This system property could be the internal DNS name or IP of your server, for example: -Dour-server-name=server1.mydomain.com
From XQuery you could then read that Java System property using util:system-property("our-server-name").
I created a new development stream out of an Integration stream. On the dev stream I created a dynamic view and an activity. I then added a new directory to an existing directory using clearfsimport.
e.g. cd to the parent directory where I want to add the new dir. then run:
clearfsimport -recurse -follow -nsetevent -c "adding new version" ~/newdir .
When it's all done I try to deliver the activity using clearcase project explorer. This throws an error like so:
"Merge Manager: warning: Element xxxx is not visible in view <Integration view name>
... ... ...
If this element should be visible cancel this operation, fix the prolem, and re-run the operation"
I have been doing this every week for months now and never had an issue. I'm really not sure what am I missing here or how to fix it. If it helps, the mastership of the Integration stream was transfered from a remote replica to ours. All my previous delivers were on the remote replica. But now I have complete mastership over the integration stream.
It depends on the nature of the target view (the one in which you are doing the deliver, the one associated with the integration stream): snapshot or dynamic.
You would need to check if the parent folder of xxxx is correctly checked out (or if you can check it out).
A cleartool ls in that parent folder of 'xxx' in the target (integration) view can help to test if everything seems ok.
If you are using a snapshot view, a cleartool update before the deliver can help too.
Since the integration stream mastership has just been transferred from a remote replica to your site, I would suggest the following:
1) Make sure you have created a view associated to the integration stream on your site
2) Make sure that the default delivery view is set to your integration view. You might need to reset it using the command
cleartool deliver -reset -to your-integration-view
The command above has to be launched from your development view.
I suggest you have a look at the cleartool deliver command
On the project I am working on, there are some proxy items that were added at some point from source location A to location B. However right now is not possible to check the source of the proxy and the proxy folder in B does not show anything that suggests that it's a proxy, besides the visual cue that it's grayed out.
When I analysed this article, I looked into the web.config and found this:
<proxiesEnabled>false</proxiesEnabled>
<publishVirtualItems>true</publishVirtualItems>
This seems to suggest that when the proxies were published they were published as regular items, losing any connection to their source, so since I want to recreate the proxies, due to some weird issues related to layout on the standard values item on the template not propagating correctly to the proxied items, I wanted to try to rename the old proxy folder and create a new one, however when I wanted to rename I got a modal alert with this message:
"This item occurs in other locations. If you rename it, the item will be renamed in the other locations as well. Are you sure you want to rename 'MyFoo'?"
Does this means the item still is attached to the source?
I am using Sitecore 6.2.0 (rev. 100701)
I suppose that the settings you mentioned are for master database. Now if you take a closer look at the article you reference, it lists 2 valid cases of proxies setup:
when web database also relies on proxies
when web database contains regular items only which came from publishing
These both cases assume that master database has proxiesEnabled='true'. Look, it doesn't have any sense otherwise - if proxies are disabled, the rest of the mechanism doesn't work, there are no virtual items.
And I can see proxiesEnabled='false' in the example you mentioned.
I'm not sure about the message you get. But if I need to change the proxy definition, I would do the following:
make sure proxiesEnabled='false' for web database (I guess this is your intention)
disable proxies for master database and change the proxies definition the way you want
set publishVirtualItems to true for master database
turn the proxies on for master database
make sure virtual items are in place and publish the site
Try this on some test environment and experiment to get the behavior you'd like - playing with the live site is a bad karma :)