How to configure Java Properties File location in WLW

Question

How do we tell Workshop 7.0 where to look for Java properties files (loaded by
PropertyResouceBundle in code) ?
Thanks,
Ray

Answer 1

Ray,
The build number indicates that you have not upgraded to Service Pack 2 of
version 7.0. I will strongly recommend you to do so. That will shield you
from the issues which were fixed in the 2 service packs.
Regards,
Anurag
"Ray Yan" <[email protected]> wrote in message
news:[email protected]...
>
Raj,
We are using WebLogic Workshop Build 7.0.1.0.0829.0 on Windows 2000.
We shut down the WebLogic Server on Solaris 2.6, log off, log back on,startWebLogic
in production nodebug mode, and re-run jwsCompile on the same source code.The
error does not occur anymore. Everything seems to be fine now.
Thanks,
Ray
"Raj Alagumalai" <[email protected]> wrote:
Hello Ray,
Can you let me know if you are using the GA version of WebLogic Workshop
or
if you have the latest Service Pack.
Thank You,
Raj Alagumalai
WebLogic Workshop Support
"Ray Yan" <[email protected]> wrote in message
news:[email protected]...
Anurag:
Thanks for your response!
By moving the property files to WEB-INF/classes from WEB-INF, we arealmost there.
But we have a follow up problem. We use a static initializer to loadthe
log4j
property file like this:
static {
try {
ClassLoader cl= (new Log()).getClass().getClassLoader();
InputStream is = cl.getResourceAsStream(logfile);
Properties props = new Properties();
props.load(is);
PropertyConfigurator.configure(props);
} catch (Exception e) {
e.printStackTrace();
When we run jwsCompile, we keep getting this:
Compiling: com/****/TestWS.jws
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[weblogic.management.Admin
may only be used on the Server ]
at weblogic.management.Admin.getInstance(Admin.java:104)
at
weblogic.security.internal.ServerPrincipalValidatorImpl.getSecret(ServerPrin
cipalValidatorImpl.java:79)
at
weblogic.security.internal.ServerPrincipalValidatorImpl.sign(ServerPrincipal
ValidatorImpl.java:59)
at
weblogic.security.service.PrivilegedActions$SignPrincipalAction.run(Privileg
edActions.java:70)
at java.security.AccessController.doPrivileged(Native Method)
at
weblogic.security.service.SecurityServiceManager.createServerID(SecurityServ
iceManager.java:1826)
at
weblogic.security.service.SecurityServiceManager.getServerID(SecurityService
Manager.java:1839)
at
weblogic.security.service.SecurityServiceManager.sendASToWire(SecurityServic
eManager.java:538)
at
weblogic.security.service.SecurityServiceManager.getCurrentSubjectForWire(Se
curityServiceManager.java:1737)
at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:434)
at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:
88)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:255)
at
weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java
:230)
at
weblogic.jndi.internal.ServerNamingNode_WLStub.lookup(Unknown
Source)
atweblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:337)
atweblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:332)
at javax.naming.InitialContext.lookup(InitialContext.java:345)
at weblogic.knex.bean.EJBGenerator$1.run(EJBGenerator.java:101)
at
weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManage
r.java:780)
atweblogic.knex.bean.EJBGenerator.lookupAdminHome(EJBGenerator.java:84)
atweblogic.knex.bean.EJBGenerator.ensureAdminHome(EJBGenerator.java:122)
at weblogic.knex.bean.EJBGenerator$6.run(EJBGenerator.java:660)
at
weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManage
r.java:821)
atweblogic.knex.bean.EJBGenerator.generateJar(EJBGenerator.java:482)
at
weblogic.knex.dispatcher.DispJar.generateJar(DispJar.java:401)
atweblogic.knex.dispatcher.DispCache.ensureDispUnit(DispCache.java:695)
atweblogic.knex.compiler.JwsCompile.compileJws(JwsCompile.java:872)
at
weblogic.knex.compiler.JwsCompile.compile(JwsCompile.java:619)
at weblogic.knex.compiler.JwsCompile.main(JwsCompile.java:109)
ejbc successful.
Generating EAR ...
The EAR was generated and we can even deploy it on Solaris. But whatdoes
the
AssertionError mean?
Thanks,
Ray
"Anurag Pareek" <[email protected]> wrote:
Ray,
ResourceBundle looks for the properties file in the current thread's
classpath.
Since a Workshop webservice's project is nothing but a webapp, the
properties files can be kept in the WEB-INF/classes directory, which
is part
of the webapp classpath.
You can also use
Thread.currentThread().getContextClassLoader().getResourceAsStream("MyProp
s
properties"); to get access to the properties file.
Thanks,
Anurag
"Ray Yan" <[email protected]> wrote in message
news:[email protected]...
How do we tell Workshop 7.0 where to look for Java properties files(loaded by
PropertyResouceBundle in code) ?
Thanks,
Ray