This concerns the state of Struts2 framework tooling, although currently I use no IDE plug-in, preferring to create projects with maven from scratch. At one time I did use the Netbeans Struts2 plugin but stopped when support lapsed for a time between IDE releases.
It is important to know the state of current tooling and so ask:
What features are offered by the Struts2 IDE framework plugin for your IDE(s)?
Are there any design issues with the plugin? (flaws such as wanting to include old or outdated libraries)
This answer applies to the the Netbeans plugin found here: http://plugins.netbeans.org/plugin/39218 (at time of writing the last updated was : 2011-12-17)
Features
When Starting a new project. File > New Project > Web Application
You now have the option of adding struts2 support, which can product a struts2 demo project.
Not tested, but should assist in validation.xml files.
Issues and Limitations
There is no support to create sources in a Maven Web application.
If you use annotations for validation the plug-in does not help.
There is no more support in struts.xml than provided by the IDE naturally. I would have really liked to see property suggestions at the very least, and it would have been very nice to see a list of name values when in a struts.xml constant tag. The IDE does do auto completion in applicationContext.xml where it expects a class, this would be really helpful in struts.xml for the class attribute of the action tag (among other places).
There is an annoying issue of the plug-in creating struts.xml files with a special icon but when creating new xml documents this icon does not apply (should be applied on the basis of the dtd) so you need to copy and paste the file to get the icon and then change the contents.
It only provides struts2 version 2.0.14 or 2.2.3
Over all I do not recommend this plug-in over a standard Maven Project and manually adding the dependencies.
Related
I work on a Maven project that uses Struts 2 and recently I became aware of some security vulnerabilities in Struts2 which are apparently fixed in version 2.3.26.
Unfortunately for me, the highest Struts2 version that is built to Maven is 2.3.24.1, which matches the version downloadable on the Struts2 "Download a Release" page as of just now.
I'd be happy to build v 2.3.26 to Maven if that's something the community can do, or request it from the right person otherwise, but I haven't been able to figure out what to do so far.
I believe this is the source code and tag for Struts 2.3.26.
Releases 2.3.26 and 2.3.27 had bugs: however,
Struts 2.3.28 is available from today.
It corrects both of the vulnerabilities you're talking about.
That said, if you need to build Struts2 from source code, or nightly build, or whatever, you need to follow the guides linked in this page.
Using Kentico for the first time and have inherited a version 7 project with custom web parts. There are folders with .cs files, folders with .dlls, and folders with .ascx/ascx.cs web parts. Most are active. Some are not.
What's the best way to assess what is used and what is compiled when looking at a Kentico instance? I'm trying to sort what Kentico stores for configuration, how Kentico knows what to compile, and how Kentico provides a pathway for custom ascx/ascx.cs webparts to use (via using) various libraries in folders on the Kentico instance folder structure.
Having worked with Kentico for quite a while it's pretty easy to identify them simply by looking in a few directories.
If you haven't worked with it before you might try to do a fresh install of version 7 which you can get from the Kentico Client Portal and compare them.
If the install was done with best practices, you can look in the following documentation and the "custom code" should be in the green and blue directories in the documentation.
There is an open-sourced utility called KInspector (it`s made by Kentico consulting team). This utility should show you your custom code (among the others) in Kentico instance (afaik it is in the Analysis module).
As always, i'm a little confused.
Here https://community.jboss.org/wiki/ModularWebAppsWithJSF2 i've learned that it is easy and works out of the box to bundle templates in separate jars since JSF 2.0.
The only problem is: i can't get it working. I simply deploy a "page.xhtml" in all flavors (META-INF directory, resources directory, root; with and without faces-config.xml) in a jar that is included in the web application WEB-INF/lib and request something like http://host/demo/faces/page.xhtml or do an "include" or "decorate" on the template. I get an exception.
Here Java EE6> Packaging JSF facelets (xhtml) and ManagedBeans as JAR my favorite JSF teacher explains to use a custom ResourceResolver to do exactly this. As i debugged the resource resolving i have no doubt that this will work and will give it a try.
This is the question about the mechanics - what is the difference between the two approaches?
Which resources exactly are looked up in META-INF/resources automatically?
Facelets compositions (so, just plain *.xhtml pages, templates and include files) are resolved by ExternalContext#getResource() which delegates to ServletContext#getResource(). This requires a Servlet 3.x compatible container because /WEB-INF/lib/*.jar!/META-INF/resources resolving from is new since Servlet 3.0. If you aren't on Servlet 3.x yet, or want to put those JARs on a different location for some reason, then you'd need to create a custom ResourceResolver. See also How to create a modular JSF 2.0 application?
Facelets composite components and static resources (so, <cc:xxx> components and CSS/JS/image resources which are to be loaded by <h:outputStylesheet>, <h:outputScript> and <h:graphicImage>) are resolved from the classpath by ClassLoader#getResource(). To include the JAR file in the classpath scan of JSF, you'd need to include a JSF 2.x compatible faces-config.xml file in the /META-INF folder of the JAR file. The same story applies to #ManagedBean, #FacesValidator, #FacesConverter, #FacesComponent and other JSF artifacts.
When developing in Eclipse, you can choose Web > Web Fragment Project to create such a module project. It is not much different from a normal Java project, expect that it will implicitly include JavaScript facet and a targeted runtime, autocreate a /META-INF/web-fragment.xml file and get associated with an existing Dynamic Web Project by adding itself as a deployment assembly to that project.
You can also use an existing standard Java project with the right folder structure prepared. The /META-INF folder has to go in Java source folder. The web-fragment.xml file is by the way optional. You just have to manually add the Java project to the Deployment Assembly section of the main web project properties. Do not add it as another project in project's Build Path section.
When you're (manually) building a JAR file out of it, you need to make sure that the directory entries are added to the JAR, otherwise Facelets compositions can't be resolved. If you're building by build tools like Eclipse/Ant/Maven/etc, this has also to be taken into account. If this is not controllable, a custom ResourceResolver is the most reliable approach.
Is it possible to compile and sign grails plug-in? I am thinking about distributing my application logic using grails plug-in architecture and I do not want my client to be able to read that easily .groovy or to modify it. Is it possible to package it somehow or at least distribute only compiled .class?
Yes. you need to think more traditional Java.
Create a JAR with your logic in it and sign the jar. Put the minimum Groovy code in the plugin. You have not stated where the logic is if it's a controller or GORM object so I am not sure what you looking for 100%.
Hope this helps.
It is possible to compile and package groovy/java code into a jar and then use it in a grails app. (as Scott suggests) but these classes can not directly benefit from grails ie. no way to declare grails service, domain class or controller in a separate jar.
There is an issue in grails jira describing the same problem:
http://jira.codehaus.org/browse/GRAILS-4956
Since Grails 1.4 M1 there are binary plugins, I assume this is exactly what you need. I'm not sure if signing is supported in any way, but it's at least possible to distribute the plugin without its sources.
The ASP.NET team released the script combining feature in 3.5 SP1 as detailed here http://www.asp.net/Learn/3.5-SP1/video-296.aspx. Is there a similar feature already for the MVC framework? If not, is this in scope or is it possible to somehow leverage the webforms capability in MVC? I see this site uses a custom jquery.package.master which, I assume, they have rolled themselves (maybe into the build cycle, however it is not all minified therefore I think they have manually appended the scripts together rather than some automated minify & combine task). Would be interested in any ideas how to accomplish this in MVC but I dont want to begin rolling any of my own functionality in case I will be duplicating work in progress.
Here's what I do, in case it's helpful.
In my postbuild I call a command line version of Dean Edwards's Packer. It combines the scripts and packs them for me.
For now though, I keep all of my stuff seperate and use a Helper method to include my scripts, and if the debug flag is not present it will include the packed versions, otherwise it includes the unpacked.
Another option is in the Telerik Native UI Extensions for MVC (free library and open source), called ScriptRegistar. It will combine and compress javascript for you, and is fairly feature rich. There is also a class for doing the same to css as well.
I am using this to combine +20 javascript files into one file which is downloaded by the browser.
http://www.telerik.com/products/aspnet-mvc.aspx and you can get it via NuGet.
Every day there is a different way of doing things and the techniques changes.
At this time there is a very good Nuget Package released in CodePlex.
Combres - WebForm & MVC Client-side Resource Combine Library
http://combres.codeplex.com/
http://weblogs.asp.net/gunnarpeipman/archive/2009/07/04/asp-net-mvc-how-to-combine-scripts-and-other-resources.aspx