How to solve this error during update in a CCRC view? - java

The latest update in the CCRC client triggered the following message:
CRVAP0087E (conflict): CCRC command 'Update' failed: Problems were encountered while retrieving view synchronization information and data.
ClearCase CM Server: Error: Unable to access "\rainwater\src": Permission denied.
ClearCase CM Server: Error: 1 config spec load rule problems encountered.
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.realException(StpExceptionImpl.java:493)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:572)
at com.ibm.rational.stp.cs.internal.util.StpExceptionImpl.<init>(StpExceptionImpl.java:538)
at com.ibm.rational.stp.client.internal.cc.Util.ccrcCmdStatusToWvcmException(Util.java:155)
at com.ibm.rational.stp.client.internal.cc.Util.runCommandAndCheckResults(Util.java:107)
at com.ibm.rational.stp.client.internal.cc.WebViewRefresh.run(WebViewRefresh.java:151)
at com.ibm.rational.stp.client.internal.cc.CcFileImpl.doRefresh(CcFileImpl.java:240)
at Refresh_View.main(Refresh_View.java:39)
What should I look for in order to troubleshoot this issue?

All web views in CCRC are snapshot views.
Check their config spec to see if said snapshot view refers to a directory which is no longer accessible (a bit like in technote swg21256715)
The question is: "what \rainwater\src represents for CCRC? A snapshot root directory? or the Vob rainwater and src subdirectory within that Vob?"
In the latter case, the main CLEARCASE group set in the CCRC preferences is probably wrong (it is the equivalent of the environment variable CLEARCASE_PRIMARY_GROUP when you are using a full ClearCase client): it must be part of the main group of the Vob (or one of its secondary groups)

Related

Connect Java Mission Control to Wildfly 16

I try to connect Java Mission Control (JMC) with Wildfly 16. Application server lays on Docker.
I successfully connected to wildfly via jconsole, to manage it I followed steps described here.
Unfortunately, I have no luck to connect via JMC. The URL which I use looks like this:
service:jmx:remoting-jmx://192.168.99.100:9990
I tried to set Xbootclasspath to jboss-cli-client.jar as it was described here, but I just get Unable to connect error.
I set the same jars, which are used for jconsole, but still I got Unable to connect.
I gave a try to adding flags on container site, as it was shown here, but with these flags, even wildfly haven't started.
Then, I found here the idea to hardcode some jboss classes to enable connection via remoting-jmx. I changed version of jars, according to these provided by wildfly16 and put it to jmc.ini like this.
-Xbootclasspath/a:"C:/Program Files/Java/jdk-10.0.2/lib/missioncontrol/dropins/jboss-cli-client.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting-jmx/main/remoting-jmx-3.0.1.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/remoting/main/jboss-remoting-5.0.8.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logging/main/jboss-logging-3.3.2.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/main/xnio-api-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/xnio/nio/main/xnio-nio-3.6.5.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/main/jboss-marshalling-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/marshalling/river/main/jboss-marshalling-river-2.0.6.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/cli/main/wildfly-cli-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/staxmapper/main/staxmapper-1.3.0.Final;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/protocol/main/wildfly-protocol-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/dmr/main/jboss-dmr-1.5.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/as/controller-client/main/wildfly-controller-client-8.0.0.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/threads/main/jboss-threads-2.3.3.Final.jar;C:/wildfly-16.0.0.Final/modules/system/layers/base/org/jboss/logmanager/main/jboss-logmanager-2.1.7.Final.jar"
After that, finally, I have another error, which is
Could not initialize class org.jboss.remotingjmx.RemotingConnector
I added dependencies of remoting-jmx-3.0.1.Final to Xbootclasspath, but I got still the same error.
My question is, have you got any idea, how to make this connection works ? Maybe someone have done it in different way ?
Any advices how can i debug this problem, will be priceless? Because I'm lack of ideas how to solve it.
In %WILDFLY_HOME%\bin\standalone.conf.bat
put:
set "JAVA_OPTS=%JAVA_OPTS% -XX:+FlightRecorder"
In jmc.ini below -vmargs put
-Xbootclasspath/a:C:\%wildfly_home%\bin\client\jboss-cli-client.jar
(%wildfly_home% is different of course, or just copy jboss-cli-client.jar to another directory and correct the path)
3. Run JMC, then Create New Connection - in Connection Properties pane push the button "Custom JMX service URL", put:
service:jmx:http-remoting-jmx://localhost:9990
In the credentials fields just put user and password, they should be created for Realm Management (e.g. using %wildfly_home%\bin\add-user.bat)
Hope this helps someone.
Solution doesn't work on java 11 for me. Mission control fails on connect to wildfly with error:
Caused by: java.lang.NoClassDefFoundError: org/ietf/jgss/GSSManager
at java.base/java.lang.Class.getDeclaredConstructors0(Native Method)
at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137)
at java.base/java.lang.Class.getConstructor0(Class.java:3342)
at java.base/java.lang.Class.getConstructor(Class.java:2151)
at java.base/java.security.Provider.newInstanceUtil(Provider.java:152)
at java.base/java.security.Provider$Service.newInstance(Provider.java:1824)
at org.wildfly.security.WildFlyElytronBaseProvider$ProviderService.newInstance(WildFlyElytronBaseProvider.java:218)
at org.wildfly.security.sasl.util.SecurityProviderSaslClientFactory.createSaslClient(SecurityProviderSaslClientFactory.java:94)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ProtocolSaslClientFactory.createSaslClient(ProtocolSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.ServerNameSaslClientFactory.createSaslClient(ServerNameSaslClientFactory.java:50)
at org.wildfly.security.sasl.util.FilterMechanismSaslClientFactory.createSaslClient(FilterMechanismSaslClientFactory.java:102)
at org.wildfly.security.sasl.util.AbstractDelegatingSaslClientFactory.createSaslClient(AbstractDelegatingSaslClientFactory.java:66)
at org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory.createSaslClient(LocalPrincipalSaslClientFactory.java:76)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.lambda$createSaslClient$0(PrivilegedSaslClientFactory.java:64)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.wildfly.security.sasl.util.PrivilegedSaslClientFactory.createSaslClient(PrivilegedSaslClientFactory.java:64)
at org.wildfly.security.auth.client.AuthenticationConfiguration.createSaslClient(AuthenticationConfiguration.java:1545)
at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.createSaslClient(AuthenticationContextConfigurationClient.java:430)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:419)
at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:244)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Besides, jmc that was embedded to jdk 8 isn't able to start flight recording for java 11 process.
So after investigation i found out that this class is loaded with bootstrap classloader. According to https://openjdk.java.net/jeps/261
jdk.security.jgss module isn't defined to bootstrap classloader. But classes in jboss-cli-client.jar(it originates from wildfly-elytron project) need jgss classes in runtime.
So i found out dirty workaround for this problem: bootstrap needed classes from jre 8 in jmc.ini. Full option for linux is:
-vmargs -Xbootclasspath/a:<path_to_wildfly>/jboss-cli-client.jar:<path_to_jdk8>/jre/lib/rt.jar
And for windows:
-vmargs -Xbootclasspath/a:<path_to_wildfly>\jboss-cli-client.jar;<path_to_jdk8>\jre\lib\rt.jar
after this jmc(run on 11 jdk) succesfully connects to wildfly(run on 11 jdk) and can start and analyze flight recordings.

websphere - CWWKE0054E error unable to open file

i am trying run the websphere liberty profile server from the command line. I am following the steps told here : https://developer.ibm.com/wasdev/downloads/liberty-profile-using-non-eclipse-environments/
I have created the server with the name server1.
But when the extraction completes and I try to start the server using the command : server start server1
the server throws an error : CWWKE0054E: Unable to open file C:\wlp\wlp\usr\servers\server1\logs\C:\Users\Furquan\AppData\Local\Temp\\ihp_custom_batches.log.. Now I know this cant be a valid path, but I dont know where and how to change it. Please help !!
This error is related to the LOG_FILE environment variable that you have defined in your environment by some other program. To solve that, you have the following opions:
Remove LOG_FILE env variable, if it is no longer needed by your system
If you cant do that, override it via server.env file, that you can create in the wlp\usr\servers\serverName directory with the following content:
LOG_FILE=console.log
As last resort (this is not recommended, will make your installation NOT SUPPORTED and in certain installations might get overwritten by updates) - modify the server.bat command line script - in the script find the following section:
if not defined LOG_FILE (
set X_LOG_FILE=console.log
) else (
set X_LOG_FILE=!LOG_FILE!
)
And after the line set X_LOG_FILE=!LOG_FILE! just add another line that will override it with the default like this set X_LOG_FILE=console.log
In general, I'd recommend second solution (with the server.env file), as it is the most portable and will work in any environment.
I have the similar problem for IBM Support Assistant V5. After I deleted %LOG_FILE% from Environment Variables, it worked.

How to upload CSV data to datastore

I am trying to populate my datastore Entity with data which I have in csv file but don't have success.
This is my CSV file places.csv:
name,placeId,location,key,address
A store at City1 Shopping Center,store101,"47,-122",1,"Some address of the store in City 1"
A big store at Some Mall,store102,"47,-122",2,"Some address of the store in City 2"
bulkloader.yaml:
python_preamble:
- import: base64
- import: re
- import: google.appengine.ext.bulkload.transform
- import: google.appengine.ext.bulkload.bulkloader_wizard
- import: google.appengine.ext.db
- import: google.appengine.api.datastore
- import: google.appengine.api.users
transformers:
- kind: Place
connector: csv
connector_options:
property_map:
- property: __key__
external_name: key
export_transform: transform.key_id_or_name_as_string
- property: address
external_name: address
# Type: String Stats: 6 properties of this type in this kind.
- property: location
external_name: location
# Type: GeoPt Stats: 6 properties of this type in this kind.
import_transform: google.appengine.api.datastore_types.GeoPt
- property: name
external_name: name
# Type: String Stats: 6 properties of this type in this kind.
- property: placeId
external_name: placeId
# Type: String Stats: 6 properties of this type in this kind
upload_data.sh:
#!/bin/sh
../Eclipse/plugins/com.google.appengine.eclipse.sdkbundle_1.9.1/appengine-java-sdk-1.9.1/bin/appcfg.sh upload_data --config_file bulkloader.yaml --url=http://localhost:8888/remote_api --filename places.csv --kind=Place -e nobody#nowhere.com
I created folder gae and placed there upload_data.sh, bulkloader.yaml and places.csv.
After I run sudo ./upload_data.sh, I receive the message:
sudo: ./upload_data.sh: command not found
After I run sudo sh upload_data.sh I receive the following error:
Bad argument: Expected an action: [update, request_logs, rollback, update_indexes, update_cron, update_dispatch, update_dos, update_queues, cron_info, vacuum_indexes, help, download_app, version, set_default_version, resource_limits_info, start_module_version, stop_module_version, backends list, backends rollback, backends update, backends start, backends stop, backends delete, backends configure, backends, list_versions, delete_version, debug]
usage: AppCfg [options] <action> [<app-dir>] [<argument>]
Action must be one of:
help: Print help for a specific action.
download_app: Download a previously uploaded app version.
request_logs: Write request logs in Apache common log format.
rollback: Rollback an in-progress update.
start_module_version: Start the specified module version.
stop_module_version: Stop the specified module version.
update: Create or update an app version.
update_indexes: Update application indexes.
update_cron: Update application cron jobs.
update_queues: Update application task queue definitions.
update_dispatch: Update the application dispatch configuration.
update_dos: Update application DoS protection configuration.
version: Prints version information.
set_default_version: Set the default serving version.
cron_info: Displays times for the next several runs of each cron job.
resource_limits_info: Display resource limits.
vacuum_indexes: Delete unused indexes from application.
backends list: List the currently configured backends.
backends update: Update the specified backend or all backends.
backends rollback: Roll back a previously in-progress update.
backends start: Start the specified backend.
backends stop: Stop the specified backend.
backends delete: Delete the specified backend.
backends configure: Configure the specified backend.
list_versions: List the currently uploaded versions.
delete_version: Delete the specified version.
Use 'help <action>' for a detailed description.
options:
-s SERVER, --server=SERVER
The server to connect to.
-e EMAIL, --email=EMAIL
The username to use. Will prompt if omitted.
-H HOST, --host=HOST Overrides the Host header sent with all RPCs.
-p PROXYHOST[:PORT], --proxy=PROXYHOST[:PORT]
Proxies requests through the given proxy server.
If --proxy_https is also set, only HTTP will be
proxied here, otherwise both HTTP and HTTPS will.
--proxy_https=PROXYHOST[:PORT]
Proxies HTTPS requests through the given proxy server.
--no_cookies Do not save/load access credentials to/from disk.
--sdk_root=root Overrides where the SDK is located.
--passin Always read the login password from stdin.
-A APP_ID, --application=APP_ID
Override application id from appengine-web.xml or app.yaml
-M MODULE, --module=MODULE
Override module from appengine-web.xml or app.yaml
-V VERSION, --version=VERSION
Override (major) version from appengine-web.xml or app.yaml
--oauth2 Use OAuth2 instead of password auth.
--enable_jar_splitting
Split large jar files (> 10M) into smaller fragments.
--jar_splitting_excludes=SUFFIXES
When --enable-jar-splitting is set, files that match
the list of comma separated SUFFIXES will be excluded
from all jars.
--disable_jar_jsps
Do not jar the classes generated from JSPs.
--enable_jar_classes
Jar the WEB-INF/classes content.
--delete_jsps
Delete the JSP source files after compilation.
--retain_upload_dir
Do not delete temporary (staging) directory used in
uploading.
--compile_encoding
The character encoding to use when compiling JSPs.
-n NUM_DAYS, --num_days=NUM_DAYS
Number of days worth of log data to get. The cut-off
point is midnight UTC. Use 0 to get all available
logs. Default is 1.
--severity=SEVERITY Severity of app-level log messages to get. The range
is 0 (DEBUG) through 4 (CRITICAL). If omitted, only
request logs are returned.
-a, --append Append to existing file.
-n NUM_RUNS, --num_runs=NUM_RUNS
Number of scheduled execution times to compute
-f, --force Force deletion of indexes without being prompted.
What can I do to upload that data to datastore? Thank you.
I think you are using appcfg.sh instead of appcfg.py. See:
https://developers.google.com/appengine/docs/python/tools/uploadingdata
Also, your output clearly shows why you got the Bad Argument error - the action parameters listed by appcfg.sh do not include "update_data", but that is what your script passes as the action.
I was doing this exact thing and didn't immediately make the leap of intuition either:
Download the python SDK, which will give you the appcfg.py tool. Just call that one in your upload_data.sh script.
The appcfg.sh program doesn't have the upload_data action. Which I found weird.

org.eclipse.jgit.errors.LockFailedException when using Hawtio

I am using HawtIo war in my code. When I run this code in local, it works fine, but on unix box I get the following exception:
Failed to pull from remote repo io.hawt.git.RuntimeIOException: org.eclipse.jgit.api.errors.JGitInternalException: Stashing local changes did not successfully complete: io.hawt.git.RuntimeIOException: org.eclipse.jgit.api.errors.JGitInternalException: Stashing local changes did not successfully complete
at io.hawt.git.GitFacade.gitOperation(GitFacade.java:737)
at io.hawt.git.GitFacade$2.run(GitFacade.java:108)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
Caused by: org.eclipse.jgit.api.errors.JGitInternalException: Stashing local changes did not successfully complete
at org.eclipse.jgit.api.StashCreateCommand.call(StashCreateCommand.java:327)
at io.hawt.git.GitFacade.gitOperation(GitFacade.java:730)
... 3 more
Caused by: org.eclipse.jgit.errors.LockFailedException: Cannot lock /remote/projusers/aptdevjboss/.hawtio/config/.git/index
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:224)
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:301)
at org.eclipse.jgit.dircache.DirCache.lock(DirCache.java:267)
at org.eclipse.jgit.lib.Repository.lockDirCache(Repository.java:1051)
at org.eclipse.jgit.api.StashCreateCommand.call(StashCreateCommand.java:225)
... 4 more
Please tell me what am I missing?
Also most likely what's happening is your home directory is on an NFS (or other distributed filesystem) share that doesn't support distributed locks, which is common enough.
You may want to set hawtio.config.dir to point to a local filesystem location that your user account has read/write permissions for. You can set this either via a blueprint.properties file or building a custom hawtio-web.war with this parameter set as per our configuration guide.
The configuration guide for hawtio is at http://hawt.io/configuration/index.html
Try with below command:
rm -f ./.git/index.lock
below link might helpful.
Git - fatal: Unable to create '/path/my_project/.git/index.lock': File exists
Hawtio tries to copy a git repo for showing things in Dashboards and Wiki tabs. You are probably facing a permissions issue in /remote/projusers/aptdevjboss/.hawtio/config/.git/index.
Also, If you don't want to copy the git repo everytime you start hawtio, there is a offline version you can download: https://oss.sonatype.org/content/repositories/public/io/hawt/hawtio-default-offline/1.2.1/hawtio-default-offline-1.2.1.war

RMI Registry Issue: rmiregistry may cause unintended exceptions when binding with codebase using the "file:" URL scheme

Please see the passage "RMI Registry Issue" of this article for the background on Java Update 1.6.0_29 first.
If I understand correctly (I'm german), the update introduces a bug in the rmiregistry which fails to work with the file: pattern in the codebase.
I.E. the following won't work any more with 1.6.0_29:
-Djava.rmi.server.codebase="file:myproject/bin/ ..."
We are currently using the feature of having a codebase with file: syntax. Does anyone know a workaround for making this work?
Note: No, we do not want to start a local webserver or ftp server.
Update:
On Naming.bind this exception is thrown:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
java.lang.ClassNotFoundException: access to class loader denied
at sun.rmi.server.UnicastServerRef.oldDispatch(UnicastServerRef.java:400)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:248)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
I had the same problem, and can confirm that downgrading JDK to earlier version solves the problem. I know, it's not a solution you're looking for, but at least it makes it to work.
Take running in windows as an example:
Step 1. In C:\Users\Jimmy.java.policy (create it if not exist), append below content:
grant { permission java.security.AllPermission; };
Of course "C:\Users\Jimmy\" is the user home, please change to your home accordingly.
Adding AllPermission is just for quick resolving your issue. you'd better config a more accurate FilePermission here.
Step 2. Start rmiregistry:
C:\JDK\bin>rmiregistry -J-Djava.rmi.server.codebase=file://C:/workspaces/MyLab/target/classes/
(Please note codebase must ended with "/")
Step 3. Run your server and client program.
References:
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/codebase.html
http://docs.oracle.com/javase/7/docs/technotes/guides/security/spec/security-spec.doc3.html
http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/enhancements-7.html
It looks like there is no workaround because it is a bug, so wait for the fix
See details at
https://bugzilla.redhat.com/show_bug.cgi?id=751203
Code fix
http://icedtea.classpath.org/hg/icedtea6/rev/67df573b0734
If you do not need dynamic code downloading (in which case you can use ftp codebase) the solution is simply to set CLASSPATH environment variable to the path to your jar file:
Windows:
set CLASSPATH="path_to_jarfile"
Linux (batch):
CLASSPATH="path_to_jarfile"
export CLASSPATH
Best place to do it is in some script that invokes the RMI server.
Setting class path in the command line (-cp option) when starting RMI server does not help because it does not affect rmiregistry classpath!
If you start the rmiregistry in the working directory of your project, it works.
So essentially working directory of your project and current directory for rmiregistry should be same.
I recently encountered this issue as well. I can confirm that when using the file: protocol the rmiregistry must either:
be started in the root of the directory containing the shared classes; or
set the classpath to point to the shared classes or shared class jar; or
use a protocol other than file:// (I set up ngnix and served the jar from that).
Maybe not what you want, but you could resolve this with classpath rather than codebase. The client JVM will work fine if you add the required classes to its classpath. If you are using the file: URL scheme, then the classes must already be available on the localhost.
I had the same problem but I couldn't change the JDK version. Turns out you can solve it by running/starting the rmiregistry from the same directory as your code base, which in my case was target/classes. So cd project/target/classes and then run rmiregistry &

Categories

Resources