What does Grails create-service do exactly? - grails

I am developing a Grails application (with Grails 1.3.7). In service layer, I did not use the command 'create-service' to create my service but do it manually.
As the result, my service was not auto initialize in controllers and other services, and it did not handle transaction.
But I do not know where is the differences from create service by command with by manual? Because I do not see any configuration file which figure out this? (I mean in traditional Spring, we always have some configuration files which specify all beans in applications, but in Grails is not).
I want to fix this issue and commit to SVN server my fix, but I do not want to delete the old service and commit the new one which is created by Grails command. So could you please help me:
1. explain what is the differences from create service by command with by manual?
2. how to change the the service created by manual to service created by command without replacing the old one?
Thank you so much!

explain what is the differences from create service by command with by manual?
Assuming you put your service in grails-app/services and followed the naming convention using a postfix of Service The only difference is that you get a nice template that looks like
class SomeService {
boolean transactional = true
def someMethod() {
}
}
and it automatically creates a unit test with the name SomeServiceTests. That is it. BTW transactional defaults to true if you do not include it.
how to change the the service created by manual to service created by command without replacing the old one?
There is nothing to do assuming you followed the conventions. If you did follow the conventions and you are still experience problems please update your question with more details such as how are you trying to use your service and a example of your service.

As long as you put your class in the grails-app/services directory, it should act just like any other service (and work as a spring bean).
If you put it in src/java or src/groovy, it's not considered a service (and not loaded as a service artefact by grails). It could still be a spring bean, but you'd have to manually add it to the resources.groovy file.

Also note that the Grails autowiring of the beans must be exact, so if you have MyService and you want to use it in the controller, make sure you have "def myService" or "MyService myService." If you would prefer different names of your member variables, you can also use the Spring Autowired annotation directly, though I've only tried autowiring grails types (e.g. a grails service) autowired to a bean I declared in resources.xml
If you put services, or any other bean in the resources.xml or resources.groovy files, they will also be autowired intro controllers, other services, etc.
It's best to think of Grails as "rapid Spring", so the autowiring, transactions, etc all are backed by Spring configuration and such.

Related

Symfony 3.4.4 + Sonata ADmin Bundle + already existing entities

I'm starting with Symfony 3.4.4 + SonataAdmin Bundle.
Everything works correctly for me.
I already have entities generated and in the integration of entities within SonataAdmin bundle by means of "php bin/console sonata:admin:generate" entities are generated in "src/AppBundle/Resources/config/services.yml
And that file is not integrated into my bundle.
I have read that using Dependency Injection is the most correct way to load that file, but I do not know how it is done.
Can someone explain to me how to install dependency injection and that this file be loaded correctly by means of the "good practices" of symfony?
I think you are confusing something.
Dependency injection is a principle in software development to decouple a classes dependency from other classes by not setting properties inside a class directly. Instead you give it for example to the constructor or set it afterwards by a public setter method. With this your classes are replaceable and thats beneficial especially for testing your source code.
So you cant install a software development principle.
And your entities are not generated in your services.yml. Your services are defined here and your entities normally going to src/AppBundle/Entity.
Symfony/Sonata is using dependency injection by defining services in the services.yml and telling them, which parameters they will get.
For example
services:
mailer:
class: Mailer
arguments: ['%mailer.transport%']
Here the mailer.transport parameter will be injected to the Mailers class constructor.
There are many yml files in your app/config folder, but the all are united in the config.yml
So if you have no instruction like
- { resource: "#AppBundle/Resources/config/services.yml" }
in your app/config/config.yml your services will never be loaded.

Force weblogic to exclude IncludeTimestamp from generated wsdl

I have an EJB that plays the role of my web service class too. I use Oracle Weblogic 12.1.2 as JavaEE container.
Here is the code of that class:
#Stateless
#WebService(serviceName="MyService")
#Policy(uri = "Wssp1.2-2007-Https-UsernameToken-Plain.xml", attachToWsdl=true)
#XmlAccessorType(XmlAccessType.FIELD)
public class MyWebServiceBean{
// some web methods ...
}
The attached policy and its corresponding wsse tags is properly can be seen in generated WSDL file. However, there is a IncludeTimestamp tag in the generated file that forces clients to send Timestamp in their request. As in my environment clients may have different times, I perefer not to force them to send the time! Then I simply omit the IncludeTimestamp Tag from the server wsdl and everything goes well after that! But I do not want to handle it by hand. Is there any setting in weblogic 12.1.2 to configure existence of mentioned tag?
After a lot reading and searching for this matter i found that we should create Custom Policy. Firstly we should find the xml file of the desired policy. Flow this post to do so. Then we should edit it and copy the edited version in our classpath and for #Policy annotation we should use new address of our xml file! That's it.

Injecting a service in Grails PluginDescriptor.groovy file?

I am trying to transform/Convert my Grails application into a Grails plugin. This post has been very helpful for me in doing so:
http://burtbeckwith.com/blog/?p=1973
While copy pasting the files, and following the above link I am stuck with Bootstrap.groovy file. While I have to paste my Bootstrap.groovy's init() code into ".doWithApplicationContext" , which I have done so, I have a problem regarding injection of sevices. Here is my Application's Bootstrap file:
class BootStrap {
//Injecting voice recordign service
def processRecordingVoiceRecognizitonService
//Injecting Service to Connect to AMQ Server to Send Recording
def AMQConnectionManagementService
//Injecting AMQ Publisher to Publish Voice Recognition Results
def messagePublisherService
//Injecting AMQ Consumer to Consume Voice Model Creation Notifications
def messageConsumerService
.
.
.
.
.
.
.
One can see I am injecting Services in my Bootstap.
I have pasted that piece of code at the start of PluginDesciptor.groovy but Intellij Idea is not showing injection sign which means services are not being injected.
Is it actually possible to inject a service in Plugin Descriptor? If not then what is the wok around to initialize and establish necessary connections in the services files?
I have found a related question but couldn't understand. here is the link just in case. inject service into instance of src/groovy class
The equivalent point to BootStrap in the lifecycle of a plugin descriptor is doWithApplicationContext, which receives a reference to the ApplicationContext from which you can fetch whatever services you need. You can't inject services into the descriptor in the normal way because the descriptor is instantiated (and several of its key methods are called) before the ApplicationContext has been set up.
def doWithApplicationContext = { applicationContext ->
applicationContext.messagePublisherService.someMethodName()
Alternatively, a plugin can provide a bootstrap artefact to applications by naming it something like MyPluginBootStrap.groovy - any Groovy class in grails-app/conf whose name ends with BootStrap will be treated as a bootstrap artefact, it's only the plain BootStrap.groovy in the plugin that is excluded from being "contributed" to applications that depend on the plugin.

Getting "unable to resolve class" exception when importing application domain objects into a plugin in grails

I am working with the Grails Authentication plugin and trying to add a domain class from the plugin into my GORM. I am able to use plugin objects in my application when importing them with, "import com.grailsrocks.authentication.AuthenticationUser", but getting "unable to resolve class" exception when trying to access my application objects from the plugin (I am trying to use the domain class "User" and my import command is "import blap.User" - package name is blap). Both import commands work from the shell, and the import statement is not triggering an error in STS.
I am new to grails, so I'm probably doing something very wrong. But, at this point I am running out of ideas, so any help would be greatly appreciated. Thanks!
Vitaly
While I haven't used the Grails Authentication plugin before, I don't think you should be modifying the plugin classes. In general, you should extend the plugin class you want to modify in your application and use your application class instead.
Actually, from reading the docs, it looks like you should use the event handling to modify the plugin behavior.
From the plugin docs:
The default AuthenticationUser domain class is minimal. If you want to change constraints or add fields (you may consider using a separate class instead for extra user data) you just redefine the onNewUserObject event and return your own instance of a domain class or similar wrapper around another authentication database such as LDAP

Getting Grails not to create packages from hyphenated app names

If I create a Grails app called a-b-c-d, doing a grails create-domain-class User will result in Grails creating a class User in the sub-directory grails-app/domain/a/b/c/d, giving it the package a.b.c.d. How do I prevent Grails from creating these package names?
You should definitely use packages, but you can customize the default package by changing the value of grails.project.groupId in Config.groovy. The default value is appName which is your application name, but you can change it to any value package, e.g. 'com.foo.bar'.
In addition you can specify the package when running a create script, and if you do want to create classes in the default package, you can use this syntax:
grails create-service .Person
and it won't use a package.
I have no idea, this sounds like a bug. There are two obvious workarounds
change your app to have a name without dashes
don't use the Grails commands create-domain-class, create-controller-class, etc. I never use these commands because they don't actually do anything other than creating the class (and a corresponding empty test class). Personally, I find it easier just to create the class myself than to run the Grails command
You can specify the package when you call the cli command...
grails create-domain-class your.package.name.User

Resources