Updated Grails from 2.2.0 to 2.2.4.
Before: http://localhost:8180/sub:favorites
After: http://localhost:8180/sub%3Afavorites
As you can see Grails encodes URL's params by default. How can I disable it and encode it manually?
Chances are high that there is an easier way. But if there isn't you can do the following:
Grails registeres a bean named grailsLinkGenerator. This bean is used for creating links (createLink(..) or <g:createLink />) within the the application. I think the default implementation is a CachingLinkGenerator which is a subclass of DefaultLinkGenerator which again implements the interface LinkGenerator.
You could extend one of these classes and override the bean in resources.groovy:
grailsLinkGenerator(YourLinkGenerator) {
..
}
Related
I want to override a bean that's used by Quarkus to disable authentication/authorization.
With the following implementation, it works that REST endpoints can be configured at start time to not be secured:
#Alternative
#Priority(1)
#ApplicationScoped
public class CustomOidcAuthController extends TestAuthController {
private static final Logger LOGGER = Logger.getLogger(CustomOidcAuthController.class);
#ConfigProperty(name = "quarkus.oidc.enabled", defaultValue = "false")
boolean quarkusOidcEnabled;
#PostConstruct
public void check() {
LOGGER.info("isAuthorizationEnabled(): " + isAuthorizationEnabled());
}
#Override
public boolean isAuthorizationEnabled() {
return quarkusOidcEnabled;
}
}
This is with the Bean residing in the same Quarkus module.
However, I want to externalize this class into a separate library and if I do this, it no longer works.
Noteworthy:
Yes, the #Priority of my bean (1) is higher than the default (3000)
The beans are discovered, if I explicitly inject them.
They are however not used, if I inject the subtype that Quarkus uses internally (either TestAuthController or AuthorizationController).
Therefore the endpoints are always secured
As can be seen here from the IntelliJ debugger
Currently I have an empty beans.xml, but with building a Jandex Index I also observe the same behavior (related How to create a Jandex index in Quarkus for classes in a external module)
I can get the behavior I want, if I use quarkus.arc.selected-alternatives=com.xxx.CustomOidcAuthController, however this is not preferable, since each Service using the library would need to configure this and this will certainly cause problems, because it can be easily forgotten.
Well, the priority of the TestAuthController is indeed 3000 and therefore it takes precedence. Injection of CustomOidcAuthController works because there's no other bean that has CustomOidcAuthController in its set of bean types.
In other words, it works as expected (and defined by the spec).
Yes, the #Priority of my bean (1) is higher than the default (3000)
According to CDI specification, an alternative with highest priority is selected. See this part of the CDI 2.0 specification.
Here is a CDI TCK test asserting that higher priority 'wins' during typesafe resolution.
Therefore, your approach is correct and you just need to make sure your custom bean is an alternative with priority value higher than that of TestAuthController.
I Have a JSF-2.2 web app on a WildFly 8.1 app server shiping Hibernate-validator 5.1
I want to set some constrainst programmaticaly using the fluent API, because they depends on the case for example a min and max of a #Size constraint could vary or a field could be #NotNull or not...
so I try to programmaticaly configure constraints such as describe here : http://docs.jboss.org/hibernate/validator/5.0/reference/en-US/html_single/#section-programmatic-api
I do somthing like that to try (in a EJB #Singleton #Startup):
HibernateValidatorConfiguration configuration = Validation
.byProvider( HibernateValidator.class )
.configure();
ConstraintMapping constraintMapping = configuration.createConstraintMapping();
constraintMapping
.type( Car.class )
.property( "manufacturer", FIELD )
.constraint( new NotNullDef() )
.property( "licensePlate", FIELD )
.ignoreAnnotations()
.constraint( new NotNullDef() )
.constraint( new SizeDef().min( 2 ).max( 14 ) );
Validator validator = configuration.addMapping( constraintMapping )
.buildValidatorFactory()
.getValidator();
But then JSF don't use this new constraints mapping.
I can submit forms without problem even if I break the constraints programmaticaly set
I don't know how to configure the Validator or ValidatorFactory JSF is using or how to provide to JSF an other Validator or ValidatorFactory...
Or may be It's more about configuring WildFly server, something to do in a config file or JNDI, I don't have a clue...
EDIT
I try to bind new Validator and validator factory in JNDI
But I can't because "Naming context is read-only"
Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
Context context = new InitialContext(jndiProperties);
context.bind("java:comp/Validator", factory.getValidator());
context.bind("java:comp/ValidatorFactory", factory);
Thank you Hardy
As you proposed I post Hibenate Validator improvement
https://hibernate.atlassian.net/browse/HV-955
There is no way atm to do what you are after. Hibernate Validator has indeed the programmatic mapping, but it is a Hibernate Validator specific feature. There is no way to bootstrap this functionality in a Bean Validation way. I am saying this, since the only way to customize your ValidatorFactory and hence Validator instance within the container is via validation.xml. And there is no mechanism for the fluent API in this configuration file.
Your JNDI idea is in principal good, but as you say, it is only read only.
validation.xml allows for vendor specific properties though. One could imagine a property like org.hibernate.validator.config_factory=acme.MyConfig. The value of the property would point to a fully specified class which would contain some sort of factory method which returns the programmatic mapping to be added to the configuration. Unfortunately, such a property does not yet exist. You could open an issue here though ;-)
For some reasons, I would like to deploy my application as two separate artifacts: Users-ejb.jar and Users-war.war, not packaged in the same ear (but still, deployed in the same JBoss AS 7.1 instance). In the Users-war.war I have a backing bean (annotated as a JSF managed bean) where I wish to inject an EJB3 packaged in the Users-ejb.jar. The simple #EJB injection that worked when everything was packaged in a single ear no longer works when the Users-ejb.jar and the Users-war.war are deployed seperately.
A narrowed-down simplified example of my setup follows:
EJB3 bean
import javax.ejb.*;
(...)
#Stateless(name="userFacade")
#Local(IUserFacadeLocal.class)
#Remote(IUserFacadeRemote.class)
public class UserFacade extends AbstractFacade<User> implements IUserFacadeLocal, IUserFacadeRemote {
Backing bean
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.ejb.EJB;
import entities.User;
import facades.IUserFacadeRemote;
import facades.IUserFacadeLocal;
#ManagedBean(name="indexBackingBean")
#SessionScoped
public class IndexBackingBean implements Serializable {
#EJB(beanName="userFacade")
private IUserFacadeLocal userFacade;
I've tried various combinations like declaring the type of the EJB3 bean in the backing bean as IUserFacadeRemote (as opposed to IUserFacadeLocal) but they all fail with the same exception when the Users-war.war module is deployed:
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException:
JBAS014543: No EJB found with interface of type 'facades.IUserFacadeLocal' and
name 'userFacade' for binding controllers.IndexBackingBean/userFacade
The Users-ejb.jar is deployed to JBoss AS 7.1 without any complains but when the Users-war.war is deployed, JBoss complains that it can't find the bean he's supposed to inject.
However, I am able to obtain a reference to the EJB3 bean using JNDI using:
String jndiName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote";
this.userFacade = (IUserFacadeRemote) new InitialContext().lookup(jndiName);
Despite that, the #EJB injection doesn't seem to work.
UPDATE:
I followed the suggestion give below by Tom Anderson and the injection that does work is the:
#EJB(mappedName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
which if I understand correctly uses the vendor-specific mappedName attribute. I couldn't get the injection to work in a vendor-independent way.
I wish i understood this area of the EE spec well enough to give you a definitive answer, but i don't.
The JBoss EJB documentation has this to say:
The #EJB annotation also has a mappedName() attribute. The specification leaves this a vendor specific metadata, but JBoss recognizes mappedName() as the global JNDI name of the EJB you are referencing. If you have specified a mappedName(), then all other attributes are ignored and this global JNDI name is used for binding.
If you specify #EJB with no attributes defined [...] Then the following rules apply:
The EJB jar of the referencing bean is searched for an EJB with the interface, used in for #EJB injection. If there are more than one EJB that publishes same business interface, then an exception is thrown. If there is only one bean with that interface then that one is used.
Search the EAR for EJBs that publish that interface. If there are duplicates, then an exception is thrown. Otherwise the matching bean is returned.
Search globally in JBoss for an EJB of that interface. Again, if duplicates, an exception is thrown.
#EJB.beanName() corresponds to . If the beanName() is defined, then use the same algorithm as #EJB with no attributes defined except use the beanName() as a key in the search. An exception to this rule is if you use the ejb-link '#' syntax. The '#' syntax allows you to put a relative path to a jar in the EAR where the EJB you are referencing lives. See spec for more details
The "Search globally in JBoss for an EJB of that interface" certainly suggests that an injection like the one you wrote should work. Indeed, that it should work without the beanName. However, my suspicion is that from the point of view of a component in the WAR, a component in the EJB-JAR is remote, and therefore you will need to use the remote interface.
So, the first thing i'd try is:
#EJB
private IUserFacadeRemote userFacade;
Without a beanName, in case that's making trouble. It sounds like you've tried that, though.
If the normal approach to injection doesn't work, i might fall back to trying an injection via a mappedName, which in JBoss is a global JNDI name. So:
#EJB(mappedName = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeRemote userFacade;
This is obviously rather ugly.
Anyway, good luck!
EDIT: Something else you could try is to use a qualified relative beanName which explicitly names the EJB-JAR:
#EJB(beanName = "Users-ejb.jar#userFacade")
private IUserFacadeRemote userFacade;
Because the WAR and EJB-JAR are not packaged in an EAR, this might need to be:
#EJB(beanName = "../Users-ejb.jar#userFacade")
private IUserFacadeRemote userFacade;
But by this point i'm just guessing.
EDIT STRIKES BACK: We may have overlooked something very simple. The lookup attribute of the #EJB annotation lets you specify "A portable lookup string containing the JNDI name for the target EJB component", hence:
#EJB(lookup = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeRemote userFacade;
Might work. This is essentially a portable version of the JBoss-specific use of mappedName.
I have been testing this scenario in Wildfly and found that it will work with local interfaces as described above if there is a jboss-deployment-structure.xml inside of the war pointing to the ejb. Otherwise a ClassNotFoundException is thrown as the war above can't really "know" about the ejbs classes due to the modular class loading in JBoss and Wildfly. The content of the file should be:
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="deployment.Users-ejb.jar" />
</dependencies>
</deployment>
</jboss-deployment-structure>
And then the JSF bean can use:
#EJB(lookup = "java:global/Users-ejb/userFacade!facades.IUserFacadeRemote")
private IUserFacadeLocal userFacade;
As #TomAnderson said, the standard way to achieve cross-artifact lookup is the lookup attribute of the #EJB annotation.
Here's a complete Maven project to illustrate how this works:
https://github.com/mrts/remote-ejb-injection
You don't need to use the name attribute of the EJB class, providing the class name in lookup is sufficient. Quoting from the example above:
// in API JAR
#Remote
public interface HelloService { ... }
// in EJB JAR
#Stateless
public class HelloServiceImpl implements HelloService { ... }
// in WAR
#WebServlet("/hello")
public class HelloServlet extends HttpServlet {
#EJB(lookup = "java:global/service-ear/service-ejb-impl/HelloServiceImpl!" +
"ee.mrts.service.HelloService")
private HelloService helloService;
...
}
(So, using HelloServiceImpl directly in lookup Just Works™.)
i am new at grails spring security, and i wanted to know if it is possible to enable/disable security of in my app thru an xml entry.
rather than having
grails.plugins.springsecurity.active = true
I d like to read the value from a bean that i declared in my resources.xml file.
grails.plugins.springsecurity.active = com.myorg.util.BeanUtil.getBean("repositorySettings").getIsSecured()
Using this approach throws errors. is there a way that i can accomplish this, and read the true/false value from a bean in the resources.xml
It's somewhat possible. resources.xml and resources.groovy are loaded after the plugin is, but parsed before. So you can put code in resources.groovy that will run while it's being parsed, before the plugin loads the config, and determines whether it's enabled. But you can't use a bean for that since it wouldn't be ready until it's too late. This wouldn't be possible in resources.xml since that's just XML but resources.groovy allows Groovy code and bean definitions:
import com.pbbi.mimgr.util.BeanUtil
beans = {
def grailsApplication = springConfig.unrefreshedApplicationContext.grailsApplication
def securityConfig = grailsApplication.config.grails.plugins.springsecurity
securityConfig.active = BeanUtil.getBean('repositorySettings').isSecured
}
If BeanUtil accesses the ApplicationContext then this won't work. But if it's accessing singletons that aren't Spring beans it should be fine.
How can we add some common constraints (i.e. maxLength, nullable) to a property of a Groovy class? I know we can do it at Grails domain class, but is it possible if that is a Groovy class (I use it as a DTO class for my Grails project)?
Thank you so much!
You can add constraints to command classes. If a command class is in the same .groovy file as a controller (in Groovy you can have more than one public class in each .groovy file), you don't need to do anything special for Grails to recongise it as a command class.
However, if your command class is somewhere else (e.g. under src/groovy), you need to annotate it with #Validateable and add the package name to the grails.validateable.packages parameter in Config.groovy. Here's an example of a command that's not in the same file as a controller
pacakge com.example.command
#Validateable
class Person {
Integer age
String name
static constraints = {
name(blank: false)
age(size 0..100)
}
}
Add the following to Config.groovy
grails.validateable.packages = ['com.example.command']
Command classes have a validate() method added by Grails. After this method is called, any errors will be available in the errors property (as per domain classes).
Using a grails Command Object is probably your best bet. It has constraints and validation, but no database backing. It's normally a value object that controllers use, but you could instantiate one outside of a controller without any problems.
Not sure if this is relevant to your use (I am not familiar with DTOs), but in the current version (2.3.8), you can also add Grails constraints to an abstract class, and they will be inherited by the domains that extend it. Your IDE might not like it though ;)