Is it possible to call to method different to GET/SET methods from Guvnor rule wizard?
I have a simple data model in Guvnor, but if I want to create more complex rules, I need to call from my rules to other different methods, that they allow me to develop other complex task. Do I need to upload a data model different to the POJO model??
Although I can write get/set methods complex. This is other possibility. I know that in the left side of a rule I have to put a statement that tell me if something is true or false. But in the right side of the rule, maybe in some case it is possible to need to do a complex action. So, it's in these cases when I need to call to other different methods to get/set methods.
Thank in advance.
The GET/SET methods are only needed for pattern matching on the Left Hand Side of the rule. On the Right Hand Side, you can call any Java code you like.
Note a limitation. You can upload facts with any methods you like. However, you do need to be careful that if by adding those methods you are adding dependencies on external libraries (maybe a method performs database access), then you need to add Jars for those external libraries to the Guvnor classpath (explode the war and copy them into WEB-INF/lib).
Related
I'm thinking about a platform-neutral (i.e. not .NET MEF) technique of implementing chain-of-responsibliity pattern using web services as the handlers. I want to be able to add more CoR handlers by deploying new services and not compiling new CoR code, just change configuration info. It seems the challenge will be managing the metadata about available handlers and ensuring the handlers are conforming to the interface.
My question: any ideas on how I can safely ensure:
1. The web services are implementing the interface
2. The web services are implementing the base class behavior, like calling the successor
Because, in compiled code, I can have type-safety and therefore know that any handlers have derived from the abstract base class that ensures the interface and behavior I want. That seems to be missing in the world of services.
This seems like a valid question, but a rather simple one.
You are still afforded the protection of the typing system, even if you are loading code later, at runtime, that the original code never saw before.
I would think the preferred approach here would be to have something like a properties file with a list of implementers (your chain). Then in the code, you are going to have to have a way to instantiate an instance of each handler at runtime to construct the chain. When you construct the instance, you will have to check its type. In Java, for instance, that would take the form of instanceof (abomination ordinarily, but you get a pass for loading scenarios), or isAssignableFrom. In Objective C, it's conformsToProtocol.
If it doesn't, it can't be used and you can spit an error out to the console.
One requirement in our application is to implement "dual control" for everything, including CRUD operations.
Just to be clear, "dual control" is a feature that requires a change in the data to be approved by someone other than the change requestor. So when a user make changes to data, it's not directly committed to production tables. I'm aware of several ways to implement this (e.g. staging tables) but thats for other time.
The question, with such requirement, do you think we should follow the standard "data centric" way of generated Roo + GWT (which uses RequestFactory) ?
Or we'll better off implementing our own "command pattern" based framework to support dual control?
I'm inclined toward the latter. My intuition (which based on 3 days play-around with Roo+GWT) says that RequestFactory is not designed with dual control in mind, and we'll hit a wall if we try to force our way in. Would be more than happy to be proven wrong here.
Have you looked at RequestFactory's ServiceLayerDecorator? It mediates all interaction between the payload processing and your domain objects and code. As an example, you could override the getProperty and setProperty methods to read from and write into some kind of "shadow" log that holds pending mutations.
If you need to implement ACLs for objects, methods, or properties, the loadDomainObject and resolveX methods can be used to control which server-side classes any given request can interact with.
To wire in a custom decorator, you can subclass RequestFactoryServlet and call the two-arg constructor. Alternatively, you can just instantiate a SimpleRequestProcessor using the object returned from ServiceLayer.create().
Implementation note: all of RequestFactory's default domain-interaction behavior is built using a series of ServiceLayerDecorators; check out the GWT source if you want to see example code for building a ServiceLayerDecorator. One thing to note is that if your decorator calls any methods defined in the ServiceLayer API, it should use the instance provided by getTop(). ServiceLayerDecorator instances are expected to be stateless and reusable, so if you need to maintain state across method calls, consider using ThreadLocal variables, similar to RequestFactoryServlet.getThreadLocalX().
It really depends what "user experience" you want, and particularly whether you want users to validate "diffs" of what has been changed, or approve the "new version" (snapshot).
If you want diffs, because RequestFactory only sends diffs (i.e. the actual changes the user, or you code, made to the objects) to the server, then intercepting setProperty calls as suggested by Bob is certainly one way to do it (to make Bob suggestion a bit clearer: you'd "store" the diff in a static ThreadLocal so you can retrieve it from your service call). You could also use "smarter" domain objects, that build an internal diff when their setters are called; the diff would then be accessible for each object on the object itself.
If you want snapshots, then you simply have to implement your services to store the modified objects in "staging tables" or whatever rather than in the "production tables"; and then "move" them to the "production tables" when the "approve" service is called.
One thing that's clear (to me), is that you have to model your services and/or objects around "dual control" and not try to do it within "simple CRUD" operations (i.e. the "save" is not a "save", it's a "send for approval"; and there's a separate "approve" operation).
I have quite a large code base using a variety of different ADO technologies (i.e. some EF and in some cases using ADO.Net directly).
I'm wondering if there is any way to globally intercept any ADO.Net calls so that I can start auditing information - exact SQL statements that executed, time taken, results returned, etc.
The main idea being that if I can do this, I shouldn't have to change any of my existing code and that I should be able to just intercept/wrap the ADO.Net calls... Is this possible?
You can globally intercept any methods that you have access to (ie: your generated models & context). If you're needing to intercept methods in framework BCL then no.
If you just want to get the SQL generated from your EF models then intercept one of the desired methods with the OnMethodBoundaryAspect and you can do your logging in the OnEntry and OnExit methods.
Remember, you can intercept only code you have access to. Generated EF code is accessable but will over write any changes you make to it so you will need to apply the aspect using either a partial class or with an assembly declaration. I would suggest the latter since you want global interception.
Just my 2 cents: You might want to look at other alternatives for this such as SQL profiler or redesigning your architecture.
Afterthought is an open source tool that supports modifying an existing dll without requiring you to recompile from source to add aspect attributes. For this to work, you would need to create amendments (the way you describe your changes in Afterthought) in a separate dll, and this dll would need to have an assembly-level attribute implementing IAmendmentAttribute that would identify the types in your target assembly to process.
Take a look at the logging example to see how this works and let me know if you have any questions/issues.
Please note that Afterthought modifies your target assembly to make calls to static methods in another assembly (your tool). If you want to intercept calls with modifying the target assembly in any way, then I recommending looking into the .NET profiling API.
Jamie Thomas (primary author of Afterthought)
Seems like everyone is moving towards IoC containers. I've tried to "grok" it for a while, and as much as I don't want to be the one driver to go the wrong way on the highway, it still doesn't pass the test of common sense to me. Let me explain, and please correct/enlighten me if my arguments are flawed:
My understanding: IoC containers are supposed to make your life easier when combining different components. This is done through either a) constructor injection, b) setter injection and c) interface injection. These are then "wired up" programmatically or in a file that's read by the container. Components then get summoned by name and then cast manually whenever needed.
What I don't get:
EDIT: (Better phrasing)
Why use an opaque container that's not idiomatic to the language, when you can "wire up" the application in (imho) a much clearer way if the components were properly designed (using IoC patterns, loose-coupling)? How does this "managed code" gain non-trivial functionality? (I've heard some mentions to life-cycle management, but I don't necessarily understand how this is any better/faster than do-it-yourself.)
ORIGINAL:
Why go to all the lengths of storing the components in a container, "wiring them up" in ways that aren't idiomatic to the language, using things equivalent to "goto labels" when you call up components by name, and then losing many of the safety benefits of a statically-typed language by manual casting, when you'd get the equivalent functionality by not doing it, and instead using all the cool features of abstraction given by modern OO languages, e.g. programming to an interface? I mean, the parts that actually need to use the component at hand have to know they are using it in any case, and here you'd be doing the "wiring" using the most natural, idiomatic way - programming!
There are certainly people who think that DI Containers add no benefit, and the question is valid. If you look at it purely from an object composition angle, the benefit of a container may seem negligible. Any third party can connect loosely coupled components.
However, once you move beyond toy scenarios you should realize that the third party that connects collaborators must take on more that the simple responsibility of composition. There may also be decommissioning concerns to prevent resource leaks. As the composer is the only party that knows whether a given instance was shared or private, it must also take on the role of doing lifetime management.
When you start combining various instance scopes, using a combination of shared and private services, and perhaps even scoping some services to a particular context (such as a web request), things become complex. It's certainly possible to write all that code with poor man's DI, but it doesn't add any business value - it's pure infrastructure.
Such infrastructure code constitutes a Generic Subdomain, so it's very natural to create a reusable library to address such concerns. That's exactly what a DI Container is.
BTW, most containers I know don't use names to wire themselves - they use Auto-wiring, which combines the static information from Constructor Injection with the container's configuration of mappings from interfaces to concrete classes. In short, containers natively understand those patterns.
A DI Container is not required for DI - it's just damned helpful.
A more detailed treatment can be found in the article When to use a DI Container.
I'm sure there's a lot to be said on the subject, and hopefully I'll edit this answer to add more later (and hopefully more people will add more answers and insights), but just a couple quick points to your post...
Using an IoC container is a subset of inversion of control, not the whole thing. You can use inversion of control as a design construct without relying on an IoC container framework. At its simplest, inversion of control can be stated in this context as "supply, don't instantiate." As long as your objects aren't internally depending on implementations of other objects, and are instead requiring that instantiated implementations be supplied to them, then you're using inversion of control. Even if you're not using an IoC container framework.
To your point on programming to an interface... I'm not sure what your experience with IoC containers has been (my personal favorite is StructureMap), but you definitely program to an interface with IoC. The whole idea, at least in how I've used it, is that you separate your interfaces (your types) from your implementations (your injected classes). The code which relies on the interfaces is programmed only to those, and the implementations of those interfaces are injected when needed.
For example, you can have an IFooRepository which returns from a data store instances of type Foo. All of your code which needs those instances gets them from a supplied object of type IFooRepository. Elsewhere, you create an implementation of FooRepository and configure your IoC to supply that anywhere an IFooRepository is needed. This implementation can get them from a database, from an XML file, from an external service, etc. Doesn't matter where. That control has been inverted. Your code which uses objects of type Foo doesn't care where they come from.
The obvious benefit is that you can swap out that implementation any time you want. You can replace it with a test version, change versions based on environment, etc. But keep in mind that you also don't need to have such a 1-to-1 ratio of interfaces to implementations at any given time.
For example, I once used a code generating tool at a previous job which spit out tons and tons of DAL code into a single class. Breaking it apart would have been a pain, but what wasn't much of a pain was to configure it to spit it all out in specific method/property names. So I wrote a bunch of interfaces for my repositories and generated this one class which implemented all of them. For that generated class, it was ugly. But the rest of my application didn't care because it saw each interface as its own type. The IoC container just supplied that same class for each one.
We were able to get up and running quickly with this and nobody was waiting on the DAL development. While we continued to work in the domain code which used the interfaces, a junior dev was tasked with creating better implementations. Those implementations were later swapped in, all was well.
As I mentioned earlier, this can all be accomplished without an IoC container framework. It's the pattern itself that's important, really.
First of all what is IOC? It means that responsibility of creating the dependent object is taken away from the main object and delegated to third party framework. I always use spring as my IOC framework and it bring tons of benefit to the table.
Promotes coding to interface and decoupling - The key benefit is that IOC promotes and makes decoupling very easy. You can always inject an interface in your main object and then use the interface methods to perform tasks. The main object does not need to know which dependent object is assigned to the interface. When you want to use a different class as dependency all you need is to swap the old class with a new one in the config file without a single line of code change. Now you can argue that this can be done in the code using various interface design patterns. But IOC framework makes its walk in a park. So even as a newbie you become expert in levering various interface design patterns like bridge, factory etc.
Clean code - As most of object creation and object life-cycle operations are delegated to IOC container you saved from the writing broiler point repetitive code. So you have a cleaner, smaller and more understandable code.
Unit testing - IOC makes unit testing easy. Since you are left with decoupled code you can easily test the decoupled code in isolation. Also you can easily inject dependencies in your test cases and see how different component interacts.
Property Configurators - Almost all the applications have some properties file where they store application specific static properties. Now to access those properties developers need to write wrappers which will read and parse the properties file and store the properties in format that application can access. Now all the IOC frameworks provide a way of injecting static properties/values in specific class. So this again becomes walk in the park.
These are some of the points I can think right away I am sure there are more.
Still wresting with GWT and App Engine, and I have come to this problem:
I have an app engine populated with various data, which I would like to present on the client using a GWT RPC.
I have found out the hard way that, because my Model objects are annotated with JDO, i can't just send them back to the client because they aren't serializable. This means I'm going to have to create a layer of intermediate classes to extract data from my model objects, and send it back to the client to use asynchronously.
I am wondering though, it is possible to construct a GWT object in a servlet and send it back to be used? For example, the servlet would be receive my asynchronous request, pull out the data i want from the database, create a GWT VerticalPanel() with appropriate child elements for the data, and send that VerticalPanel back to the client to be injected.
My understanding of the Java / Javascript interaction that is going on here is still foggy, and I'm thinking that sending a Java object that is not compiled to Javascript after the application is deplyed will not work. Can anybody clarify this for me?
No the server can't create GWT UI objects (like vertical panels) to be used in the presentation layer, nor should it, that's why it's called a 'server' and a 'presentation layer' one serves the data and handles all the business logic, the other displays things on a screen and allows a user to interact with them.
You can however send your JPA annotated POJO's to the front end just fine (we do it in all our applications). You simply need to include the source code for the annotations themselves so that GWT knows how to compile them. You also need to make sure your POJOs's are in a package that is referenced by a NameOfXmlFile.gwt.xml file, eg:
<module>
<inherits name='com.google.gwt.user.User'/>
<source path="domain" />
</module>
This file in my case is in a folder above a package called 'domain' where all my JPA annotated POJO's live. Then in your client side you tell it to inherit that .gwt.xml file:
<module>
<inherits name='com.google.gwt.user.User'/>
<!-- Domain layer references -->
<inherits name='your.package.structure.NameOfXmlFile'/>
</module>
There are restrictions on what you can put in those classes (like for example BigDecimal is not supported, etc) but anything that can be compiled by the GWT compiler (and JPA annotations certainly can be) can be sent without needing any kind of transfer objects. This is one of the real strengths of GWT, that you can use the same JPA Pojos in your entire application, without ever needing to create any other similar object.
Edit: I just noticed you said JDO and not JPA. I assume the same applies there as well though if they are just annotations?
I've seen good answers, so I won't repeat them myself..
Anyway my simple but vital suggestion is: the only way to go is through POJO objects.. BUT IMHO to avoid problems, remember that your POJO objects SHOULD be really PLAIN
Anyway, I can suggest you also a little framework I recently did (few hours of work, so don't expect a rocket!).
It is pojo-injector: http://code.google.com/p/pojo-injector
It helps you in translating your data models to POJO and back... It's based on annotations (only on the POJO side!).
I hope it can help.
This is (imho) one of the problems with GWT.
Basically in Java Web applications it's pretty common to have data or domain objects (which would be your JDO objects) and presentation objects, which are sent to the view. Some go much further than this and can have many more layers of abstraction ("go ahead, add one more layer").
I can see the argument for this but it adds a lot of boilerplate as you translate objects between layers.
Anyway, in GWT you need to do this if your domain objects are POJOs (and as with JPA, even though they claim to be POJOs, the annotations make them not so in reality).
GWT will do this for you on objects returned by your RPC interface but there are certain classes you can't use (eg BigDecimal) as there is no Javascript equivalent (so to use BigDecimals you pass Strings around to construct BigDecimals yourself on the serverside when you ened them and convert them back to Strings when you send them to the client).