I am working on struts 1.x application and need to implement junit 4 test cases in it.
I have struts2-junit-plugin jars for using StutsTestCase to create test cases for Action classes. Is this possible ? Struts 1.x app using struts2-junit jars . When i am trying to run test case , its giving error - InitializationError
When i check failure Trace - its showing
java.lang.noclassdeffounderror org/springframework/core/io/resourceloader
Can anyone help me with cause . Is it something with version of junit jars or using struts2 jar in struts 1 app. Or i need to add something more or any other mistake. Please help
Thanks in advance
No.
This makes no sense--Struts 2 is a completely different framework. There is zero overlap in functionality, supporting libraries, architecture, etc.
You might be able to rework the Struts 1 StrutsTestCase to support any explicitly-JUnit 4 functionality, if it doesn't out-of-the-box, or simply build up the supporting objects (e.g., ActionForm, ActionMapping, and the normal HTTP stuff) and run "bare" tests.
There's a reason Struts 1 was EOL'd over five years ago: the architecture is antiquated and tightly coupled to itself and to HTTP, which made testing difficult. If you search around you may find some resources for updating the testing infrastructure.
Related
I've being looking around for Zend\Tool which appears in version 1 but not in version 2. I did find another SO post where it was mentioned that they've not been added yet but that was over 6 months old.
Does anyone have an update on when they will be added or can point me in the direction of similar utilities?
ZFTool is now available for Zend Framework 2: https://github.com/zendframework/ZFTool
There's no such thing as Zend Tool at the moment. They are still working on it but when it will be released, no one can tell yet. However there are two great Git-Repositories out there, that pretty much cover crucial aspects of Zend Tool - creating a bare application and new modules
zendframework/ZendSkeletonApplication
zendframework/ZendSkeletonModule
Additionally someone posted a shell script to create a new skeleton module on my Blog, you can find the script right there. However i take no responsibility for that script, as i don't use it myself. ZF2 Modules are so simple and the SkeletonModule is all i need:
zf2crmod.sh
I have used NB to add a "client web service" to a Codename one app through the NB interface. This works fine in the simulator.
The WSDL classes are generated during build automatically and I have them landing in com.myco.myapp.generated package.
Having checked the generated JAR the WSDL classes are there all ok.
But when I push this to the "build for Android" to codename1, run on the device I get
An Internal application error occurred : java.lang.NoClassDefFoundError: com.myco.myapp.generated.SimpleStockList_Service
But the class is definitely there in the JAR.
I am sure its something to do with the JAR and its manifest, but never really had to get behind the scenes with Ant and JARs and builds to know what to do.
As the classes are generated during ant build, I can not pack them up into a library. (tried that and get fail due to 2 instances of same class.)
Codename One doesn't support binary libraries at this time, you will need to integrate the source code into the build process. There are many complexities involved in supporting binary libraries in such a setup.
Thanking Shai for his help.
Ultimate answer is not to use WSDL as moving objects relies Serialization which is not included in the small Java package.
Due to this I created a custom servlet which codename1 ConnectionRequest can deal with via a standard HTTP request.
This is how I achieved it
http://www.jamesarbrown.com/?p=164
We've using groovy/grails for a couple of months and find it very nice language and framework, at least for prototyping.
The only thing constantly driving us mad is projects build time.
Compiling small app consisting of few tiny domain classes took up as much time as if we are compiling something well, something more serious )))
So, the question is - are there any techniques and approaches which can be used to reduce grails project build time?
UPD:
this question covers one of aspects, which make grail deployment slow - dependency resolution. In short, get rid of snapshot dependencies. The subquestion is how can I detect such dependencies fast?
In development, you can try running the script runner in interactive mode:
grails interactive
or, in Grails 2, simply
grails
It keeps JVM running between grails commands invocations, which greatly reduces their overhead. I found this of a great use when doing TDD, as running tests becomes much quickier that way.
Help! I'm porting a large ruby app to Grails - but the Grails startup of my application takes more than 2 minutes.
I've already set dbCreate to "read" I've ensured my high end dual processor desktop windows box gives Grails needed RAM (1 Gig). I have no plugins installed. I have 170 domain classes that used to be ruby classes.
When it starts up it prints out the line "Running Grails App.." and then hangs for a long time before it then prints out the "Server running" line.
I just did something where I migrated all my ids to bigints. That seems to have worsened the problem. Now it takes about 10 minutes to startup.
I am new to grails would you please give me a few more details on what and where to log the events at startup? As to profiling the vm, its been a few years since I did a lot of Java. What do you recommend as the best profiling tool to use now?
What else can I do to speed up Grails startup?
Unfortunately, I am not sure too much can be done beyond what you already did. As you know, there is a lot going on when it starts up, with all the plugin resolution / loading, adding dynamic methods to your domain objects, and overall dynamic nature of Groovy.
I am not sure which version you are using, but I've asked for ability to turn off dependency checking when you start up in 1.2, since that adds a bunch of time to startup time as well.
I realize above isn't too helpful, so perhaps this will be: I split up my application into several plugins. One for domain objects, one for graphing capability, one for excel import, another for some UI constructs I needed. I didn't do it just because of slow startup times, but the advantage is that I can test parts of the system separately from each other before integrating everything together.
I am about to add a piece of new functionality that involves at least 10 new domain objects, and I am first developing them in a separate plugin by having stubs for the few objects they have to interact with from the core app. That allows me to both reduce startup times, and also have my code better isolated.
So if it's an option for you, try to separate out things so you can work on them separately, which will alleviate your issue somewhat. There may also be other benefits in terms of having your team work on smaller components separately, better modularization, etc.
Hope this is helpful.
170 domain classes is fairly large, but 2 minutes still seems really long to me. Do you have a ton of plugins installed? Potentially too verbose debug settings?
I'd be curious how long it took if you created a fresh grails app, copied in all of your domain objects (and the subset of plugins that the domain objects might need to actually operate) and see how long that takes to start.
Jean's suggestion about separating things out if possible is a good one. I've done something similar on previous projects where we have a domain plugin, and our other apps all rely on that domain plugin.
You could also use the grails events to log some timing information on start up to see where your bottlenecks are. Timing the "PluginInstalled" event should be good as I think that the hibernate plugin would be caught by this in addition to the other plugins.
You may have a dependency problem. If a plugin you use relies on a library in maven that has 'open ended' dependencies, grails will go and look each time if there are newer versions to download in the range. I have no idea why anyone would specify it like this. It seems it would lead to unreliable behaviour. For me, the culprit is Amazon's java aws library, naturally used by a plugin that talks to Amazon's cloud.
http://mvnrepository.com/artifact/com.amazonaws/aws-java-sdk/1.2.10
note how some of its dependencies are like this
org.apache.httpcomponents httpclient [4.1, 5.0)
it appears that every time, grails is looking for a newer version (and downloading if it exists, I just noticed 4.2-alpha1 of httpclient come down when I ran this time).
By removing that dependency from the plugin and manually adding the required libraries to my .lib folder, I reduced my startup time from >30sec to <1sec
You might want to see if there are other knobs you can turn other than Grails in order to fix this.
Have you tried approaching this as a performance issue? You can a look at the box performance and try to find out what the bottleneck is. Is it CPU? Is it a disk read issue? Can you attach a profiler to the VM and find out what's using up most of your startup time?
Have you tried basics like these for further deployment to a servlet container of your choice or in-place .war bootstrapping?
grails -Ddisable.auto.recompile=true run-app
grails run-war
grails war
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .