Classpath settings and configurability

[adamjk-dev]

Hello sir,

So, I wasn't sure of all the ways that we can set the classpath for the servers. The readme mentions a post_classpath, and searching the code yielded a few more results.

Do you have a moment to explain how the classpath is configurable? I have a client wishing to change the classpath and puppet is enforcing it on them.

Is there a way to let the classpath be manually modified and tell puppet not to enforce it?

Thanks!

[biemond]

post classpath in wls_setting in combination with your own jar in the domain/lib folder is for configuring own authentication providers or something else with a wls resource type

but you can also use the classpath parameter on wls_server.

mostly I see people is putting their jars in the domain lib folder ( after the domain creation and before startup domain )

[adamjk-dev]

Interesting, thanks for the explanation. I guess it is partly my lack of understanding, but placing our own JARs and the like, would that allow for custom classpaths to be set etc.?

[biemond]

in the domain lib it will affect all managed servers, with the classpath parameter on wls_server it will only be used on this managed server.

[dblaisdell]

How can users change the custom class path, without puppet overwriting their changes? Or maybe a better question, How can I backdown management of the classpaths typically modified by server engineers?

[biemond]

You cannot and you don't want this. else you got 2 versions of the truth . Puppet should be the correct one, so you got consistency for your whole environment. They can send git pull requests and you can merge them after they are ok on test and acceptance.

[adamjk-dev]

The only other option I see is to set the hiera value for classpath to be equal to the value of a fact, so we can set the fact on disk on the machine. This allows a user of the machine managed via puppet to change the fact on-disk to change the classpath if necessary.

wls_setting_instances:
  'default':
    ...
    post_classpath: "%{::weblogic_post_classpath}"

[dblaisdell]

I completely agree with you biemond. Unfortunately, that's not shared amongst the infrastructure team. They don't want to venture into the application space at all, really just want to install WL10 or 12 and walk away.

[LTangaF]

I was trying to figure this out, too. Setting it in wls_server looks like it overrides the entire classpath, which means that I'd have I'd have to be aware of other things that weblogic's startup scripts put in there depending on the environment and duplicate that behavior. I really just want that post_classpath behavior at the managed server level. Putting jars in lib isn't always the best option. For instance, we're adding Introscope instrumentation. That gets installed somewhere else on the disk and needs a couple jars added.

I suppose that I can just symlink them in the short term, but you can't control ordering with that.