Archived

This forum has been archived. Please start a new discussion on GitHub.

IcePack questions

First of all, I have an outstanding thread out called "Proxy reconnection to reactivated adapter" that I would love to get a reply for when anybody has the chance please.

Secondly, I've sucessfully built an application using Ice, IceBox, and IceStorm, and am now trying to integrate IcePack and have a number of questions. I tried to search for answers in existing threads, but could not find the specific ones I'm looking for...


1) My java services get AccessControlExceptions even though I use the vm-option attribute of a server. Here is an example message:


java.security.AccessControlException: access denied (java.util.PropertyPermission Ice.Warn.Dispatch read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:269)
at java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
at java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1276)
at java.lang.System.getProperty(System.java:573)
at Ice.PropertiesI.getPropertyAsIntWithDefault(PropertiesI.java:61)
at IceInternal.Incoming.invoke(Incoming.java:217)
at IceInternal.Connection.message(Connection.java:1067)
at IceInternal.ThreadPool.run(ThreadPool.java:681)
at IceInternal.ThreadPool.access$100(ThreadPool.java:17)
at IceInternal.ThreadPool$EventHandlerThread.run(ThreadPool.java:1063)

I set my vm-option to this for both service and server:

vm-option="-Djava.security.policy=/home/..../allPermissionsPolicy"

The policy file contains this:

grant {
permission java.security.AllPermission;
};

I've used this file successfully outside of IcePack for a very long time.

Any ideas why I am still getting thses exceptions?


2) Is there an easier way to re-initialize an IcePack node and registry besides removing the files by hand -- e.g. :

rm -rf db/node/* db/registry/*

The "shutdown" command in icepackadmin does not remove the files.


3) Is there a way that the XML descriptor file can share properties? For example, would be nice to not have to repeat properties like "IceStorm.TopicManager.Proxy" in every single service descriptor that acts as an IceStorm client. I tried putting properties in the configuration file given to icepacknode and icepackadmin, but the servants cannot read the properties.



4) Is there a way that the CLASSPATH variable can be substituted in a descriptor file instead of including it explicitly for each service? We have very long classpaths. We also generated the CLASSPATH variable on the fly in scripts so that users do not need to have to do construct it themselves. Currently the only way we see around this problem is to source our common script file first to export the CLASSPATH. I think I know the answer to this one, but wanted to double check in case it can be put in as a new feature later.


5) Even using the CLASSPATH workaround above, for some reason our gui's cannot find icons using the the following code which works fine outside of IcePack:

Button.setIcon( new ImageIcon( getClass(). getResource( "/xxx/yyy/zzz.gif" ) )

Everything else in the CLASSPATH seems to be working except this. Again, this works fine outside of IcePack.


That's all for now. Any help on any of these issues would be greatly appreciated. Let me know if it would be better to post items like this separately next time.

Thanks again,

Brian

Comments

  • mes
    mes California
    Hi Brian,

    I just wanted to let you know that we're looking into these issues.

    - Mark
  • Mark,

    Thanks for letting me know. Appreciate the response.

    Brian
  • mes
    mes California
    Hi Brian,

    1) I can't think of anything that Ice or IcePack could be doing to cause a security exception. This does indicate that the Ice.Properties implementation probably needs to trap (and ignore) security exceptions, but I don't think that's your point. I'm assuming you think the server should be able to access the system property, correct?

    If so, my best guess is an environmental issue. I suggest running IcePack with the IcePack.Node.Trace.Activator=1 property defined, so that you can see the exact command line IcePack is using when launching the JVM. Perhaps that will provide a clue as to what's happening.

    2) The shutdown command isn't intended to wipe the node's databases, it is only meant to gracefully shutdown the node process. Wiping the databases is something that is rarely necessary in deployment. However, I can understand how it would be nice to have during development, but currently there's no automatic way to do that.

    3) Not presently, but we will keep it in mind as a future enhancement. For example, it might be nice to define a property at the application or node level and have it apply to all of the sub-entities.

    4) What do you mean by "substituted"? Can you provide an example of how you're setting the CLASSPATH now?

    5) You're using IcePack to launch Java applications that have GUIs?? Do you mind if I ask why? :)

    Take care,
    - Mark
  • Thanks for the response Mark. Here are some responses to your questions:

    1) I actually had IcePack.Node.Trace.Activator set to 3, but I reset it to 1 and got the output that I have attached. No matter what tracing option I set, I have never seen any output relating to JVM options. I also have Trace.Adapter=2 and Trace.Server=3. There are two services, IceStorm and "Demo_Validator". It is when I make a call to start the Demo_Validator servant that the problem happens. Again, this issue does not happen when I am not using IcePack.

    4) Right now, we are sourcing a file that sets a very long classpath using bash syntax and exports it to the shell. When not using IcePack, we do not have to explicitly export our CLASSPATHs to each shell we run icepacknode or icepackadmin in. By "substitute" I mean it would be nice to be able to say ${CLASSPATH} in a descriptor and have it automatically import whatever classpath is current set in the shell. At this point, the only way we see to set the classpath for deployment is to explicitly "hardcode" this huge CLASSPATH value into EVERY descriptor that needs it. Also, if the CLASSPATH needs to change even the slightest bit, we then have to change in a lot of places. Very unappealing. Is there any other way to do this more efficiently at this point?

    5) Not to be flip, but why not? We want to treat our objects that have gui interfaces as servants that can be started as services on any number of hosts just like our objects that don't have guis. The problem is we get this weird problem where getResource(...) can't find the icon. Again, this problem does not happen when we are not using IcePack. Any help would be appreciated.

    Thanks again Mark.
  • Mark,

    Upon further investigation ....

    1) Solved this issue, but not without some pain. The problem here was that the "vm-option" element was not being set properly in my server xml file, but the XML parser did not complain so I assumed that I was using it correctly. I was using it as an attribute of the server element. I finally realized that I should be using it as an element, but since there were no examples in the manual and no examples I could find in the installation of using this element. Also I glommed that I should be using <vm-options> to wrap each <vm-option> by looking at the example in ...test/IcePack/deployer/server.xml and looking at the use of the <envs> element. Undoubtedly, I made the big error here, but I have some suggestions in case anybody else screws up like I did:

    a) provide examples of using all elements/attributes in IcePack, 20.9.
    OR
    b) provide examples in demo or test source installation.
    c) provide stricter XML parsing using whatever mechanism (dtd or schema) you are using to specify the form of legit files.

    Again, if I had read the manually more carefully my problem would not have taken as long for me to diagnose, but a little more doc stuff would be nice.


    4) I think I also screwed up here. My CLASSPATH seems to be working now as long as I wrap the call to icepacknode or icepackadmin inside a shell that sources the CLASSPATH we need. Still, it would be nice to have some mechanism for pulling in and substituting environment variables set in the shell using a syntax like you have for using ${name} in the xml examples. We do not want to have to "hardcode" our env vars using the <env> option. Since we will have many xml files for our different servers and since the setting of some of our environment variables are using dependent, we would like to deploy the same xml files for anyone for any server, but pull in ${ENV_VAR} as contextually for each user. For example:

    <vm-option -DENV_VAR=${ENV_VAR}</vm-option>

    OR
    <env>ENV_VAR=${ENV_VAR}</env>

    Did I describe that okay?

    In order to circumvent this problem, we will probably end up having to gen some of our xml files on the fly and substitute in the proper env vars where necessary.


    5) This problem actually turned out to not be a CLASSPATH issue, but a permission issue. Since we now understand how to use the <vm-option>, we think this is solved as well.

    Anyway, still interested in your comments. Hopefully, you guys have not put in much time trying to diagnose our problems. Wanted to update you as soon as we could to avoid that.

    Thanks,

    Brian
  • mes
    mes California
    Hi,

    1) Agreed, we need better documention for the XML descriptors.

    4) We'll look into adding support for substituting environment variables. At first glance, it sounds good to me.

    Thanks,
    - Mark