How to view results of a WebLogic Deployment Plan - weblogic

I'm trying to use a weblogic deployment plan to add init-param values to a vendor-provided .war file's web.xml.
While I realize that I can open the .war file and just edit the file inside, I'd prefer to use a deployment plan to accomplish this as I will need to deploy the .war file to multiple servers with different values for the init-param in question.
I have found many examples of how to do this on-line, but my efforts are hit and miss. I think that if I could see the impact of the deployment plan on my deployed war file, I would be able to quickly figure out what I am doing wrong.
Is there a way for me to view the runtime deployment descriptors of a weblogic (10.3.3) application after the deployment plan has been applied?

I spent some time investigating this a while back, and although WL10 unpacks the WAR in a temporary directory, it does not modify the files listed in the deployment plan in that location. I also tried using getResource/getResourceAsStream to read the whole web.xml, and found it to be the original, unmodified file as well.
I never did figure out how WL applies the changes so that they get picked up by the ServletContext without them being visible anywhere else. My guess is that it's using some trickery to override the loading of those files and applying the changes dynamically.
After fighting with it for a while, I eventually settled on something like the following to list out the values of the init parameters on startup:
if (log.isTraceEnabled()) {
final Enumeration<String> names = context.getInitParameterNames();
while (names.hasMoreElements()) {
final String key = names.nextElement();
final String value = context.getInitParameter(key);
log.trace("Init Parameter '{}' = '{}'", key, value);
}
}
(Using slf4j for the logging)
Of course it doesn't help a bit if there's something wrong with the deployment plan and the values aren't being set, but it's the best I could come up with.

In 12.2.1 there is a DebugDeploymentPlan Server debug setting, if on, the server logs something like
<After applying the overrides from the deployment plan, the descriptor "META-INF/ejb-jar.xml" is:

Related

Appsettings.json How does one check to see what environment is being used?

If one has a running .net core web app and there are multiple appsettings.json files in the root, how can you tell what environmentname is set to? I guess one way is to write your own utility or status page where you use code to write out the value of this variable. Is there another way?
Instead of using some sort of transform as in the case with web.config files, you now generally deploy all the environment-specific appsettings files, and let the app determine the value of the environment. This seems kinda confusing, in that you no longer can simply look at a config file and know what settings the app is using.
You can check the value of IHostingEnvironment.Environment as William suggested in the comments, but a better approach would be to call either IHostingEnvironment.IsDevelopment() or IHostingEnvironment.IsEnvironment() and it will do the name checking for you.
Methods for checking for production (IHostingEnvironment.IsProduction()) and staging (IHostingEnvirionment.IsStaging()) exist as well.

How to reload AnalyzingInfixSuggester from the directory?

Using lucene 5.4.1 I am trying to use the AnalyzingInfixSuggester to build a suggestion library and I'm running into an issue where I am unable to load that suggester. I have one process that builds an index out of my data and I have another process(web service) that returns data by searching against that index. However, when I try to open the index, I get nothing from suggester.getCount()
I am calling commit() on my suggester after writing to the directory. On the file system, the files in the directory in question contain about 5.8M of data. However, when I open it to make a search from the web service, I get nothing. I tried calling build and refresh just in case I needed to do that to initialize and still get nothing.
I feel like I'm missing something. Can someone please point me in the direction of some example code that actually reads the suggestion documents from a file system directory?
The answer was much simpler than I thought. A compound of forgetting that my index was built on my machine while the service was running on a vagrant instance. Wrote to a shared directory, removed calls to refresh and build and it works. So to recap, all that is necessary is to construct the suggester by passing the directory and analyzer and it works as expected.

Unresolved reference to WseeFileStore

I am trying run SOA Suite and when I execute startWeblogic.sh I got the following message error:
Unresolved reference to WseeFileStore by [<domain name>]/SAFAgents[ReliableWseeSAFAgent]/Store
at weblogic.descriptor.internal.ReferenceManager.resolveReferences(ReferenceManager.java:310)
at weblogic.descriptor.internal.DescriptorImpl.validate(DescriptorImpl.java:322)
at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:332)
at weblogic.management.provider.internal.DescriptorManagerHelper.loadDescriptor(DescriptorManagerHelper.java:68)
at weblogic.management.provider.internal.RuntimeAccessImpl$IOHelperImpl.parseXML(RuntimeAccessImpl.java:690)
at weblogic.management.provider.internal.RuntimeAccessImpl.parseNewStyleConfig(RuntimeAccessImpl.java:270)
at weblogic.management.provider.internal.RuntimeAccessImpl.<init>(RuntimeAccessImpl.java:115)
... 7 more
Does anyone know how to fix this error?
I am running the system over 64 bits Suse
The quick and dirty way to get your admin server back up:
cd to <domain name>/config
Back up config.xml just in case
Edit config.xml, find and remove the <saf-agent> tags that point to your non-existent WseeFileStore
When you have the admin server back up. You can look at the Store-and-Forward Agents and Persistent Stores links to see what is already configured there. It sounds like a SAF agent was somehow created but the backing Persistent Store was not.
You can always created the Persistent Store later and add that SAF agent back in if you need it.
This happens simply because the automated tool used to adapt the config.xml file to the new cluster structure is... well, far from efficient.
It can create all other relevant structures ok, but the <saf-agent> entry is wrongly created.
Just open and look briefly to the config.xml file and you should see that something is not right with this entry.
I will use my environment as an example for this situation:
I have a single cluster with two managed servers named osb1 and osb2. Both are administered by the cluster's AdminServer and all these components are in a single machine called rdaVM. The whole domain was created with the Configuration wizard and, upon the first AdminServer start, I've got that dreadful error for quite some time.
The solution does reside in the config.xml file located in <DOMAIN_HOME>/config/config.xml
When I opened this file in the editor and did a quick search for WseeFileStore I got some curious entries:
<jms-server>
<name>WseeJmsServer_auto_1</name>
<target>osb1</target>
<persistent-store>WseeFileStore_auto_1</persistent-store>
</jms-server>
<jms-server>
<name>WseeJmsServer_auto_2</name>
<target>osb2</target>
<persistent-store>WseeFileStore_auto_2</persistent-store>
</jms-server>
and
<file-store>
<name>WseeFileStore_auto_1</name>
<directory>WseeFileStore_auto_1</directory>
<target>osb1</target>
</file-store>
<file-store>
<name>WseeFileStore_auto_2</name>
<directory>WseeFileStore_auto_2</directory>
<target>osb2</target>
</file-store>
but looking at the offending entry:
<saf-agent>
<name>ReliableWseeSAFAgent</name>
<store>WseeFileStore</store>
</saf-agent>
Obviously there's something missing here. Looking at the <DOMAIN_HOME> I could see two folders there: WseeFileStore_auto_1 and WseeFileStore_auto_2. So no WseeFileStore and hence that annoying error. Also, the saf-agent element doesn't have a target.
Solution: using just the underlining logic, I adapted the <saf-agent> entry to:
<saf-agent>
<name>ReliableWseeSAFAgent_auto_1</name>
<target>osb1</target>
<store>WseeFileStore_auto_1</store>
</saf-agent>
<saf-agent>
<name>ReliableWseeSAFAgent_auto_2</name>
<target>osb2</target>
<store>WseeFileStore_auto_2</store>
</saf-agent>
I.e, created a <saf-agent> for each of the cluster's managed servers, targeted each entry to a managed server and added the _auto_# suffix, where # is the ordering number for each managed server, to the <name> and <persistent-store> entries.
After it, I was able to run the startWebLogic.sh script without problems (from this source at least...)

Dynamically change connection string for UI tests

I'm using WebAii library for UI testing - I want to test whether my component displays the same records as there are in database therefore I need to switch my application's connection string to point to the test database just for the time of running tests. What is the best way to do it? How to dynamically change the connection string prior to running the app? Thanks
Are you storing the connection string in the Web.config file? If so, I would deploy a new Web.config just before starting the test and then use the command line to send an IISRESET.
FYI, these are the kinds of questions we answer all day long on our public forum dedicated to WebAii.
Cody
Telerik Technical Support
What kind of application is it? This is first probably an indication of not-well-factored code. Next, it is common to have a separate environment for testing code.
If you are, for example, deploying to ASP.NET with Visual Studio, you can use Web.config file transformations to set a different value when you deploy to e.g. test.contoso.com vs. www.contoso.com. The transformation syntax allows you to define a new connection string, or change an existing one from the base Web.config, when deploying a different configuration.
If you have a single environment, and control over it, you could probably write a couple of (Power)shell scripts to copy a web.config with "test" connection strings to your app root prior to the test. Then run a second script to reset the original web.config after the test is run.
If you have access to your deploy directory within the context you will be running your tests, you could even simply have a Web.test.config file included in your unit test project. In [AssemblyInitialize]:
File-copy _\\{your app server}{your app directory}\Web.config to \\{your app server}{your app directory}\Web.config.orig.
File-copy Web.test.config to \\{your app server}{your app directory}\Web.config.
Sleep for a few seconds?
Then do the reverse in [AssemblyCleanup].
Other strategies exist, too. You could build in an override to your application when in debug mode, that checks various things (special file, additional config, cookies, extra query string). Or you could have a Settings manager in your app that you can instrument in test setup when arranging your test (click through UI to change DB settings).
Very likely, however, you may get the best compounding rewards by factoring your code to reduce dependencies. Then you can write unit tests which stub/mock/fake the database. You can use code coverage tools to verify that you've tested specific scenarios, or to see that additional integration tests would be duplication of coverage at that point.

File not found exception while reading .sql file present in grails-app/conf/sql

I have an sql query in my controller action (select * from table....where.....et al). This query is fired when the user submits a page.
It is a 50 lines code that takes in 3 parameters.
For eg: select * from employee where empDate='params.empDt' and empNum=params.empNum order by params.sort asc.
In the above case the query takes in 3 parameters (params.empDt, params.empNum and params.sort) dynamically and is executed.
Since it is a huge query, I am looking at externalising the query to an sql file. The file thus externalised would be called in the service and the query would be executed.
So i created the .sql file in grails-app/conf/sql/read_date.sql.
When i read this file and the run the app, using run-app, it wrks fine. I am able to read the file and execute the query.
However, when I create a war and deploy it on tomcat, the appn doesnt read the file and I get a FileNotFound Exception.
java.io.FileNotFoundException: grails-app/conf/sql/read_date.sql (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:106)
Inputs??
Well you see the thing is, the grails-app/conf structure does not exist within the war. If you use something like 7-zip to open up the war and take a look around in it, you will see that all the Classes in conf are now in Web-Inf/classes. The directory structure is only really guaranteed through development. If you created an Sql file in web-app/sql, this might solve the problem for you as the directories under web-app are respected during War generation. Web-app contains thing like javascript files that are required by the application and are then accessible via http://myhost:port/AppName/sql/my.sql. If I were you, I would database the sql though.
Hope this helps.
John
I can't really see the point of putting the actual SQL in an external file. Just put the SQL statements in the service class, things will be fine. There is probably no increase in speed if you have the SQL statements in an external file (that needs to be read from disk every time the query needs to be executed). If you need to change the SQL Statement often (which would be a good reason to externalise the statement), you could evaluate the possibility of reading it from the database itself (like from a text field, or something)...
If you really want to use the external text file approach from a service or controller the easiest method is probably to use ServletContext.getResource to get a reference to the data packaged in your web app. Since getResource does take a context-relative URL, you can use
getResource("/someSQLstatements.txt") and trust it to work, regardless of the location of your web application on the server's local filesystem OR the path it's mapped to via the servlet container. That should work well. (see also :http://www.velocityreviews.com/forums/t131134-specifying-path-for-file-to-be-read-by-servlet-with-tomcat.html)
have fun.