This method is package-private (I only checked version 7.6.0), but I found it very hard building proper failsafes into more complex components without the ability of checking the initialization states of the internal components. If I could access that method publicly it would certainly do no harm (it's a read-only method). Yet I did not find any alternative way of checking if a component instance passed initialization phase.
I see that the method is public in 8.x (https://github.com/apache/wicket/commit/d1710298c7e371f260299f732c58d0bf4d647161). So you have two options: 1) use Wicket 8.0.0-M4 or file a ticket to make it public in 7.x as well.
Related
I'm doing a Java Backed Webscript to put in Alfresco and call it via REST. This Webscript must do a set of 3 operations (find a path, create a folder and upload a document).
I read about this and found similar examples to do this operations throw the native Alfresco API, with methods like getFileFolderService, getContentService, etc. of Repository or ServiceRegistry classes. All in Java, without javascript.
But I would rather use REST calls instead of Alfresco API inside my Webscript. I think that if already exists Webscripts to do these operacions, is easier call them than use Alfresco API methods to try to do it. And if the API changes in future versions, the REST calls would remain the same. But I'm new here and I don't know if I'm wrong.
In summary: to do these 3 operacions, one after another, in my backed webscript, what is better and why? Use native API methods or use REST calls to existing webscripts?
And if I try to do the second option, is possible to do this? Using HttpClient class and GetMethod/PostMethod for the REST calls inside my Java Webscript may be the best option for Rest calls?. Or this could give me problems? Because I use a Rest call to my backed webscript that do another rest calls to another webscripts.
Thanks a lot!
I think it's bad practice to do it like this. In a lot of Alfresco versions the default services didn't change a bit. Even when they changed they still had deprecated methods.
The rest api changed as well. If you want to make an upgrade proof system I guess it's better to stick with the Webservices (which didn't change since version 2.x) or go with CMIS.
But then it doesn't make sense to have your code within Alfresco, so putting it within an interface is better.
I'd personally just stick with the JavaScript API which didn't change a lot. Yes more functions were enabled within, but the default actions to search & CRUD remained the same.
You could even to a duo: Have your Java Backendscript do whatever fancy stuff and send the result to je JavaScript controller and do the default stuff.
Executing HTTP calls against the process you are already in is a very very bad idea in general. It is slower, much more complex and error-prone, hogs more resources (two threads), and in your case, you will even lose transaction safety. Just imagine the last call fails for some reason. Besides you will most likely have to handle security context propagation yourself. Use the native public API and it will be easy, safe and stable.
We are currently using PostSharp for its standard functionality (logging, caching, transactions, and so on).
We also generate dynamically, at runtime, some custom classes, using Reflection.Emit. This obviously slows startup, and as we need to add more dynamic type generation, I am wondering, since all the information for the dynamic types is known at build time, whether we can use PostSharp to do this.
So, the question itself is, can I use PostSharp to achieve what I can do with Reflection.Emit, but at build time?
Regards
The PostSharp itself is using PostSharp.Sdk to manipulate the binary code, but this API is not publicly documented and supported at the moment. So, it's not future-proof to rely on it in your project.
The closest you can get with the documented API is probably by introducing interfaces, methods and properties: http://doc.postsharp.net/content/code-injections
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.
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)
i was reading Zend Framework Book: Survive the Deep End about resource methods. it speaks about how resource methods will override resource plugin.
But wait, there's also a Resource
Plugin
(Zend_Application_Resource_View) which
may also create a Resource called
View. Can we have two View Resources?
The answer is no - we can have one and
one only
in Zend Framework Manual,
a good way to create re-usable
bootstrap resources and to offload
much of your coding to discrete
classes is to utilize resource plugins
... the intention is that developers
should write their own to encapsulate
their own initialization needs
to me, resource methods seem like a more intuitive way to initialize resources, why then should I use plugins? is it just a question of which do I prefer? or are they used in different circumstances?
will resource methods replace or add to the functionality provided by the provided resource plugins? because if it replaces, I would need to make sure i initialize all variables or whatever I need?
By returning the new Zend_View
instance from _initView(),
Zend_Application will accept the
replacement and will not attempt to
overwrite our changes by running
Zend_Application_Resource_View to set
up a standard default Zend_View
instance with the flaws we just
corrected
if I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?
Here, we do the same thing by using
the getResource() method to retrieve
an instance of Zend_Controller_Front
created and configured by
Zend_Application_Resource_Frontcontroller
from the above, can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource() 1st?
Answering your questions:
Should I use resource plugins or methods?
I would say it's largely down to personal preference. As your quote from the manual says, if you use a resource plugin, it becomes easier to reuse the code in another project (as it's easier to move around/test a class than it is to cut'n'paste text from a method). In my opinion methods make it a little easier to see what's going on in the bootstrap, at least until they start becoming a bit complex, in which case it'd make sense to convert them into a plugin.
Will resource methods replace or add to the functionality provided by resource plugins?
I believe the way it works is that plugins are loaded up and initialised when the bootstrap class is first instantiated. The bootstrap will then go through your methods and run those. If you have a method named the same as a plugin resource, your method will override that plugin. However you can also access the existing resource from your method and modify it, in which case your method is adding to the functionality provided by the plugin.
Remember that plugins don't magically run by themselves (apart from the front controller plugin, which will always run). They will only be used if your application.ini triggers them (or if you call them from your own methods).
If I dont return a Zend_View, it will be as if I didn't have the method? can I say that I should always return something from resource methods?
It is good practice to return something from resource methods as this allows that resource to be accessed by other methods or other parts of the application. However the method will still run without the return value. But if you added an _initView method and setup a new Zend_View object, if you don't do anything with it it won't have any effect on your application.
Can i say that if i want my resource methods to have the defaults set by the provided resource plugin, i can do a getResource()
Yes. But I would make sure you return the resource in this case, just so that any other methods that access the resource are using your modified one rather than the one setup by the plugin.
Personally I would either stick to application.ini + resource plugins, or resource methods. It's easier to see what's going on if all of the resource stuff is in one place.