Weblogic Work Manager: There is a requirement to create the work manager to effectively handle the threads. I need to create the WorkManager at domain level. So when I create the workManager at domain level do I need to define the workmanager in web.xml or weblogic.xml , or Just defining in config.xml will work. How the container or the weblogic knows about the custom workmanager created ?
How do we test the same?
Any thoughts will be appreciated.
If you create a work manager at the domain level (using the admin console), this modifies config.xml to make it available to all applications. Then in your individual application (weblogic.xml or weblogic-application.xml) you can reference it like:
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>my_workmanager_name_from_config_xml</param-value>
</init-param>
Related
we are using the Jboss fuse 6.2 along with technical stack blueprint,camel ,activeMQ and Mybatis.
We need to know about how to configure the property files in OSGI ,
as per my knowledge we could configure .cfg files, but is there any simplest way to use like spring configuring the configuring.
In Our code we are reading from property files . using namespace ext:proeprtyplaceHolder giving that bean id and values we are giving .
Help to provide is there any simplest way to read the property files
There is several ways to add configuration, because OSGi services can access configuration via ConfigurationAdmin service. The blueprint also can access property values over it.
JBoss fuse using karaf, so you can use the following methods.
(There is some quotes from http://www.liquid-reality.de/display/liquid/2011/09/23/Karaf+Tutorial+Part+2+-+Using+the+Configuration+Admin+Service)
Configuration with Blueprint
The integration with our bean class is mostly a simple bean definition where we define the title property and assign the placeholder which will be resolved using the config admin service. The only special thing is the init-method. This is used to give us the chance to react after all changes were made like in the pure OSGi example.
For blueprint we do not need any maven dependencies as our Java Code is a pure Java bean. The blueprint context is simply activated by putting it in the OSGI-INF/blueprint directory and by having the blueprint extender loaded. As blueprint is always loaded in Karaf we do not need anything else.
<cm:property-placeholder persistent-id="ConfigApp" update-strategy="reload" >
<cm:default-properties>
<cm:property name="title" value="Default Title"/>
</cm:default-properties>
</cm:property-placeholder>
<bean id="myApp" init-method="refresh">
<property name="title" value="${title}"></property>
</bean>
After you can put a cfg file (which is a standard java property file) to
karaf's etc or deploy directory with the name of of the given persistent-id which is MyApp in our example. (For example: /etc/ConfigApp.cfg)
title=Configured title
I have a project that I am deploying to CloudBees and I have defined some param-names inside my cloudbees-web.xml file. I would like to access these from my java application but have tried System.getProperty(),(String)env.lookup("email.user.name") all with no luck.
How can I access these from within Java?
Below is my cloudbees-web.xml file which is located under WEB-INF:
<?xml version="1.0"?>
<cloudbees-web-app xmlns="http://www.cloudbees.com/xml/webapp/1">
<!-- Changed for Privacy -->
<appid>CB_ACCOUNT/APPNAME</appid>
<!-- Extra context parameters -->
<context-param>
<param-name>email.user.name</param-name>
<param-value>test#gmail.com</param-value>
</context-param>
</cloudbees-web-app>
You can access those context parameters just like you can access any context parameter defined in your WEB-INF/web.xml, in other words:
getServletContext().getInitParameter("email.user.name")
Note that you need to be in a class instance that has access to the ServletContext, or else you need to pass the ServletContext from a class that has access to it.
Typically you will have requests served by a Servlet or JSP page... or the framework you are using will provide a means to access the context (e.g. Java Server Faces provides the external context concept - which is either a ServletContext or a PortletContext because JSF supports both containers) so in those cases it is just a question of accessing the parameter from your servlet.
If you are starting background threads to do work (which is strictly against the Servlet specification... or at least out of scope) you should be starting (and stopping - don't forget to stop them) those threads via a ServletContextListener... which also is fed the ServletContext... if you are a bold person and starting background threads from class static initializers... well your only solution is to have a ServletContextListener pull the config and hand it over to the background thread... at which point you are better off starting the tread from the ServletContextListener (also solves the loading multiple contexts from the same .war file issue... not that you'll have that on RUN#cloud)
I want to expose custom operations using jboss console. Like in jboss 4.2, we were using xmbeans to create our own interface & then invoke operations.
I found sample (https://docs.jboss.org/author/display/AS7/Example+subsystem) related to creating custom subsystem but that can be accessed using CLI only.However If its possible to expose the same set of operations and attributes in the web (admin) console?
If not, is there any plan for it?
Thanks for your help.
Best Regards,
Divya Garg
I'm porting a legacy application from JBoss 4.2.3 to JBoss 7 (the web profile version). They used a custom login module and used a valve to capture the login failure reason into j_exception. They did this by putting context.xml into the web-inf directory of the war, with the following contents:
<!-- Add the ExtendedFormAuthenticator to get access to the username/password/exception ->
<Context cookies="true" crossContext="true">
<Valve className="org.jboss.web.tomcat.security.ExtendedFormAuthenticator"
includePassword="true" ></Valve>
</Context>
The login is working for me, but not that valve. When there's a login exception, the j_exception is still empty and the logic that depends on analyzing why the login was rejected fails. According to this link: http://community.jboss.org/wiki/ExtendedFormAuthenticator, everything looks right. However that link is very old, and it's possible things have changed since then. What's the new way?
It seems that security valves are now defined directly in jboss-web.xml, like this:
<jboss-web>
<security-domain>mydomain</security-domain>
<valve>
<class-name>org.jboss.web.tomcat.security.ExtendedFormAuthenticator</class-name>
<param>
<param-name>includePassword</param-name>
<param-value>true</param-value>
</param>
</valve>
</jboss-web>
However, the ExtendedFormAuthenticator class wasn't ported to JBoss 7.0.1. A ticket has been opened for me, so it should be present in JBoss 7.1.0:
https://issues.jboss.org/browse/AS7-1963
In the code for our project there is this line:
(Properties) new InitialContext().lookup("properties")
One of the other developers said I had to add the entry through the admin for my instance of Glassfish. Having to use the admin to do this seemed suspect to me. Isn't there a way to add a JNDI entry at startup in web.xml, or something similar?
I think the idea here is that it must be done via the admin application so that the values aren't embedded in the application.