Why would Glassfish generate an incomplete granted.policy file? - glassfish

Version: GlassFish Server 3.1.2.2 (build 5)
I have an EAR project which contains a WAR and a single EAR.
In the META-INF folder of the EAR, I have a sun-application.xml file which maps a selection of roles to groups.
In the default file realm for Glassfish, I have configured users which map to these groups.
I am not using Default Role to Mapping and I have not actived the Security Manager.
Access works perfectly. This is further proven by removing the deployment descriptor, which causes an Authorization exception when trying to log in without it.
However when trying to access a seemingly random (but consistent) selection of my EJBs, I am greated with the infamous Glassfish "javax.ejb.AccessLocalException: Client not authorized for this invocation" exception.
I have tried to delete my generated Policy files and redeploy the server, but this does not work.
When I look into the Policy file for my EJB, straight away I notice that the afflicted EJB grants are missing.
It would appear that one or two roles per group as defined in the sun-application.xml file are being missed.
Why would Glassfish fail to generate a complete policy file from a (proven) working sun-application.xml and (proven) set of #RolesAllowed definitions?
Here's the deployment descriptor:
<!DOCTYPE sun-application PUBLIC "-//Sun Microsystems, Inc.//DTD
GlassFish Application Server 3.0 Java EE Application 6.0//EN"
"http://www.sun.com/software/appserver/dtds/sun-application_6_0-0.dtd">
<sun-application>
<security-role-mapping>
<role-name>ViewAllData</role-name>
<role-name>BasicUser</role-name>
<group-name>BasicGroup</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>DataSupervisor</role-name>
<group-name>DatasetSupervisors</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>FindData</role-name>
<role-name>FindSubData</role-name>
<group-name>DatasetUsers</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>ManageData</role-name>
<role-name>ManageSubData</role-name>
<role-name>InvokeDataload</role-name>
<group-name>DatasetManagers</group-name>
</security-role-mapping>
<security-role-mapping>
<role-name>ResolveGroup1</role-name>
<role-name>ResolveGroup2</role-name>
<role-name>ResolveGroup3</role-name>
<group-name>Decoders</group-name>
</security-role-mapping>
</sun-application>
For some reason, the roles ResolveGroup1 and ViewAllData are missing from the EJB granted.policy file, despite appearing in a couple of EJBs:
#RolesAllowed({"ResolveGroup1"})
#Stateless(mappedName = "ejb/FindGroupOneController")
#Local(FindRegistrationFragmentController.class)
#Interceptors(SpringBeanAutowiringInterceptor.class)
public class FindGroupOneControllerImpl implements FindGroupOneController{
#RolesAllowed({"ViewAllData"})
#Stateless(mappedName = "ejb/ViewDataController")
#Local(FindRegistrationFragmentController.class)
#Interceptors(SpringBeanAutowiringInterceptor.class)
public class ViewDataControllerImpl implements ViewDataController{

Unless someone can tell me otherwise, it looks like the reason I was having problems is because you may use only one <role-name> per <security-role-mapping>.

Related

Jruby: How to change the application url in war file deployed on glassfish server

I have deployed application on glassfish server. my application is accessible using url localhost:8080/test
Below is the setting in my warble.rb file
Warbler::Config.new do |config|
config.jar_name = 'test'
config.webxml.jruby.min.runtimes = 2
config.webxml.jruby.max.runtimes = 10
config.includes = FileList['init.rb']
end
The above setting create war file with name "test.war" and so it the application url i.e localhost:8080/test . what i want is i want to keep the file name as it is i.e it should be "test.war" but the application url should be localhost:8080/test_application instead of localhost:8080/test
From the Glassfish Application Deployment Guide (PDF)
When you deploy a web module, if you do not specify a context root, the default is the name of the WAR file without the .war extension. The web module context root must be unique within the server instance.
If you want to change the context root, you must do this in your deployment descriptor. There are several ways to do that, but with warbler the easiest is probably the following (although it is specific to Glassfish).
Create a file called 'glassfish-web.xml' in your Rails application root. It should have the following content:
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<context-root>test_application</context-root>
</glassfish-web-app>
Add the following to your warbler config (warble.rb) to ensure that this file gets packaged into your application war's WEB-INFO directory:
config.webinf_files += FileList["glassfish-web.xml"]
Re-warble your application and re-deploy.
It should now be accessible at localhost:8080/test_application.

jpa-store and hibernate OGM

Issue:
Try to configure infinspan cache with jpa-store and hibernate OGM. I can able to access the infinispan server cache through hotrod client with simple cache store, the configuration is follows,
I have configured following in ..\infinispan-server-8.1.0.CR1\standalone\configuration\standalone.xml and run the server by command ../bin>standalone.bat
<subsystem xmlns="urn:infinispan:server:core:8.1">
<cache-container name="local" default-cache="default" statistics="true">
...
<local-cache name="testCache">
<compatibility/>
</local-cache>
</<cache-container>
<subsystem>
In client side, accessing the cache sucessfully using hotrod client like below code.
Configuration config = new ConfigurationBuilder().addServer().host("127.0.0.1").port(11222).build();
RemoteCacheManager cacheManager = new RemoteCacheManager(config);
RemoteCache<Integer, TestEntity> cache = cacheManager.getCache("testCache");
1. How to configure jpa-store (with load from database and write into database) in standalone.xml?
I have tried with below code in standalone.xml.
<persistence passivation="false">
<jpa-store xmlns="urn:infinispan:config:store:jpa:8.0"
shared="true" preload="true"
persistence-unit="CachePersistenceUnit"
entity-class="TestEntity"
singleton="false"
batch-size="1">
</jpa-store>
</persistence>
Caused by: javax.xml.stream.XMLStreamException: WFLYCTL0198: Unexpected element '{urn:infinispan:server:core:8.1}persistence' encountered
at org.jboss.as.controller.parsing.ParseUtils.unexpectedElement(ParseUtils.java:89)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseCacheElement(InfinispanSubsystemXMLReader.java:971)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseLocalCache(InfinispanSubsystemXMLReader.java:706)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.parseContainer(InfinispanSubsystemXMLReader.java:247)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:97)
at org.jboss.as.clustering.infinispan.subsystem.InfinispanSubsystemXMLReader.readElement(InfinispanSubsystemXMLReader.java:70)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69)
at org.jboss.as.server.parsing.StandaloneXml_4.parseServerProfile(StandaloneXml_4.java:547)
at org.jboss.as.server.parsing.StandaloneXml_4.readServerElement(StandaloneXml_4.java:244)
at org.jboss.as.server.parsing.StandaloneXml_4.readElement(StandaloneXml_4.java:143)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:69)
at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:47)
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110)
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69)
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
... 3 more
How to auto deploy project (customized infinispan manager class(java class), persistence.xml and infinispan-config.xml) in infinispan server(Jboss)?
The two questions are actually related:
Infinispan Server is designed as a backend data store and hence it's not designed to have applications deployed on it.
With that in mind, since you can't deployed applications onto it, you can't deploy JPA entities and hence it does not make sense to be able to configure a JPA cache store in Server mode.
You are able to deploy JPA entities on Wildfly/EAP or similar environments, where it is possible to deploy an Infinispan based application (see tutorials here) and configure a JPA store.
Cheers,
Galder

Using the context-root from glassfish-web.xml in GlassFish 3

We recently switched to Glassfish 3.1.2.2 and have several Web-Applications packaged as war files. At times the desired context-root for these applications differs from the filename.
Back when we used Weblogic we achieved this by declaring the context-root in the weblogic.xml like this
<context-root>path/to/our/App</context-root>
We noticed that the same Tag exists in the glassfish-web.xml. But no matter what we define there, the server always determines the filename as the context-root.
Now we find the option --contextroot in the asadmin utility that would allow us to overwrite the filename at deploy time, but we'd prefer to do define it directly in the archive itself so that whoever will deploy it in the end won't need to know the desired contex-root.
Is there any way to achieve this?
In GlassFish 3 and GlassFish 4 the configuration of a web application is done via glassfish-web.xml. In your case the desired configuration file would look like this:
<!DOCTYPE glassfish-web-app PUBLIC
"-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN"
"http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<context-root>/path/to/our/App</context-root>
</glassfish-web-app>
You can find further details in section GlassFish Server Deployment Descriptor Files of Oracle GlassFish Server Application Deployment Guide. A online version of this document can be found at http://docs.oracle.com/cd/E18930_01/html/821-2417/.
Normally this should work with a glassfish-web.xml looking like this:
<!DOCTYPE glassfish-web-app PUBLIC
"-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN"
"http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<context-root>/path/to/App</context-root>
</glassfish-web-app>
But here it looks like you need a file called sun-web.xml for your task.
Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD GlassFish Application Server 3.0 Servlet 3.0//EN"
"http://www.sun.com/software/appserver/dtds/sun-web-app_3_0-0.dtd">
<sun-web-app error-url="">
<context-root>/path/to/our/App</context-root>
</sun-web-app>

ExtendedFormAuthenticator in JBoss 7

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

No factories configured while using Jetty 7 embedded + Myfaces 1.2

I am using an embedded version of jetty 7 to load a web application using Apache MyFaces 1.2 in a junit 4 test class on the advice from another thread.
While running the test i get this error.
java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml.
A typical config looks like this;
<listener>
<listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class>
</listener>
This application works fine with tomcat, weblogic and even oc4j!
How can i get this to work with jetty?
I solved this by adding the myfaces-impl jar which had the .tld file inside the WEB-INF/lib directory.