I have a problem which is hard to explain so lets get started:
Context: I have a application running on a tomcat server Lets call it "admin". The admin have an import/export function. Our own application is an extension to that and we need to gather some information when the "admin apps" use the import/export function.
Problem: The third party jar that contain the class ImportController is located there: ~/someFolder/admin/WEB-INF/lib/admin.jar. The goal is to gather the Old project ID and the new Project ID so that our extension can link our class to the right project. Since i know the method signature i though i could use AOP to do so.
Idea: The idea i came with is to put something like idHiJacker.jar that would contain a single pointcut and advice into the ~/someFolder/admin/WEB-INF/lib/ and enable load-time weaving. That advice would simply put the information into an xml file so our extension would be able to read it when we want to put the link back after a project import.
Also i must say I'm a pure newbie with AOP and web stuff. But i do not wish to import a monster for just doing this small operation with AOP. At the moment im reading on aspectJ and AspectWerkz
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
2) If this is possible what would be the good practice to do it in a very clean manner?
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
4) Am i doing this for nothing? Is there an easier way to do that operation?
Edit: Also if you have good tutorial to link with answer, it would be awesome
Thanks for your time and answer
Question:
1) Am I in the right direction? Do you see anything that would make this idea not work at all?
I can't see any reason why this will not work. Aspect Oriented Programming and cross-cutting concerns apart, the notion of advice is to execute some before or after some other pointcut and often to influence the behavior of that advised function. You are doing exactly that here.
2) If this is possible what would be the good practice to do it in a very clean manner?
There is some inherent chaos with aspects/advices -- since the control flow is hijacked more then a simple sequential reading of code is needed to understand whats going on.
3) Should i do it with AspectJ? AspectWerkz? Or Something else?
I have never used AspectWerkz but I have very good experience with AspectJ; especially in terms of the support here on stackoverflow and perhaps even more on its mailing list.
4) Am i doing this for nothing? Is there an easier way to do that operation?
Unless you can change the code of import controller or change the clients to make extra calls to do the linking thing this interception based approach seems best IMHO.
I have suggestion for a simpler solution - use a decorator pattern to wrap around the third party ImportController, put your functionality before the third party library is called. You should be able to do this since you seem to have access to the admin application.
This is essentially doing what AOP is doing, but using code. Your approach using load time weaver should also work, but is in my opinion complicated - if you absolutely plan to go this way, do use AspectJ.
Related
I've read about how to use Spring in standalone applications but I'm not sure what should be the approach for refactoring a large code base of 120,000 lines for making the change as gradual as possible.
As far as I understand Spring won't inject anything in an object unless that object is managed by the application context. If this is true, I think I have two choices:
1- Start refactoring from the main class down, but this means complicated scenarios will appear soon.
2- Share the application context statically so that I can start refactoring the simplest things, scalating in difficulty when I'm ready.
I'm not a fan of static access so I would try to avoid that choice, but I don't know if it's a good idea to start with the huge classes that are loaded at startup. Any ideas of the best approach?
By the way, is it OK to inject Swing components until I can fix the dependencies?
I think that before approaching such a big technology change, it may be a good idea to start asking yourself if you are following the architecture that Spring guides you to have when you start using it from the beginning.
Therefore, is your application based on the MVC pattern?
If not, maybe your product is not yet ready for being refactored to
use Spring. In this case, I would suggest refactoring the product
design first, so that it complies with the MVC architectural pattern.
If yes, then I would proceed with a use-case-based approach, starting
from the use cases that required a complicated design and
implementation.
E.g. I would look for very important entity classes or business classes containing a lot of logic. This way, you can reduce the risk of doing a lot of refactoring before realizing that, for example, Spring is not a good fit for the core of your product.
After identifying the most critical use case, you can start to experiment how refactoring works on your current product by introducing Spring from end to end on a single critical scenario (user input - business logic - entity manipulation - persistence). If you are successful, then you keep refactoring, otherwise you can go back and try to understand where you need to change your current product before introducing Spring.
Of course, this works when you have some experience with Spring and you do not have to cope with newcomer's issues. If you are new to Spring, then I would recommend getting some experience with Spring before starting the adventure of refactoring such a big project.
Start simply and wire new code/class with spring. You'll amend your existing main method to initialise the ApplicationContext and load your new feature. Over time then as change requests arrive you'll refactor and migrate the existing codebase to use spring dependency injection.
I need advice on how to rewrite a java GUI. Ultimate goal is easier to maintain & enhance.
What I have built is a Java Applet Client interface that acts and behave similar to Eclipse. developer can design their data entry forms without using a single line of code (drag and drop), and define its attribute. This part is pretty well iron out. however, i am left with more than 40,000 lines of codes that is very difficult to maintain.
Each time a bug is occur or a new enhancement, i normally cant program in a more direct way. more than half the time, i need to workaround the problem and that adds up the lines of code.
Consideration:
-Java Web Applet (because it runs on any browser with J2RE installed)
-runs on slow machine
-deployment of around 200 nodes and growing
Problems that i currently have:
-Listeners are all over the place. sometimes is inside the element.AddListener(new listener..). Sometimes is outside of the class, could be in another package that contain all the rest of listener.
Question: is it always good idea to put all listener in another package? if that is that case, i cant use "this." to get the reference i need.
-JTable this is a killer to me :( the problem i had on Cannot access the Jtable column data after set invisible still persist. Imagine i have JTable with 3 column. First column is a dropDown, second and third column is a textfield. Whenever a value choose from dropdown, i need to base on the selected value, and update to the second column and third column. the problem is, if the user click and it click on other row very fast, it will update to a column that is in the wrong row.
-Currently the program is coded in the sense of it is single thread. whenever the user does a http connection to the server side, reading a file, writing a file and etc, i need to make it as asynchronous process so it doenst feel like "program hang". what is the best way to do this?
Really appreciate help here! Thanks!
Lots of questions here and I'm not sure where to start but I can sympathize with you one this one. Unless you have a well seasoned team that has already gone through the pains of Swing application development things can quickly become out of control and unmanageable.
Before you adventure into re-writing a project I would start with defining some simple standards for development. Like package structures and listeners. I would also recommend splitting the application up into well unit tested modules or sub projects.
Also, ask yourself if you really need to re-write the application or does it just need some TLC. As a consultant and Director of IT I see developers always wanting to re-write applications just because they've learned something new or don't think it's up to par. When they come to me and tell me that it's junk and needs to be re-written I usually send them back and ask them to come up with alternative solutions to a re-write and the impact of each solution including - doing nothing. In a lot of cases we didn't write the application at all.
[UPDATE]
Lastly, If you are going to re-write I would use a Domain Driven Design and MVC approach. Yes, I said MVC for desktop applications!. We've had great success with these methodologies. It keeps a good separation of concern and makes things easily re-usable. It also provides the structure to easily switch out the presentation layer. Most importantly it's easy to unit test and any developer that understands MVC can understand the basics of your project without knowing the details.
I have some more thoughts but i'll leave it at that for now. ;)
use dsl for gui:
swinghtmltemplate
swixml
yaml
there are some more of them
this will remove the need to describe listeners, allow binding in dsl manner
Why dont you just reuse the eclipse framework to build your own gui instead of writing it from scratch in Swing ?
I have a very quick question - Is it possible to modify the source code of Java API e.g. Junit, JABX ?
I know it seems a very stupid question, but it has been bugging me for a while.
If you can get your hands on the source, then sure you can modify it. It might not be the best option. It might be better to just create subclasses (if possible) and overwrite implementations, and use your subclasses. Or use composition to proxy the library classes. Depends on what you need to do/fix.
Keep in mind if you modify the source of an external library, and upgrade, you have to modify the source again. You might have to change your extensions/proxies as well if you go that route, but experience has taught me that's typically less complicated.
for open source API such as JUnit: yes
We basically need to be able to adjust behaviour at start-up time, by providing desired classes to be produced by various factories inside our application (to avoid the hard binding of the "new" operator).
I am aware that this is provided by several large frameworks, but I was looking for something easily used by a stand-alone Java application without being gigantic.
Any suggestions?
Edit: It is my experience that frameworks tend to grow big as part of maturing (and complex too). I need this to be retrofittable to a legacy application as part of major refactoring (technical debt), so simplicity is essential of the used libraries. I do not mind having to do a bit of coding in our application, but it must be very visible what is going on. AOP has a tendency for moving stuff out of the way, and that may make the application harder to maintain.
Edit: We have now reached the point where we actually need to make a decision. The application will probably live for decades so we need to make a reversible decision with a framework that will be maintained for hopefully as long. I really like the static type check available with Guice, but not that the annotations bind explicitly to Guice instead of being external like in Spring. I also like that code appears to be more concise when using Guice as opposed to Spring. We need something that is robust and helpful. We do not need more than just DI at the moment. Is there a use case that definitive says go for one of these?
Edit 2011-07-27: The final decision was to use the JSR-330 API in code, and choose on a per-project basis if to use Spring, Guice or Weld. For stand-alone applications Guice has worked well so far as the JSR-330 implementation.
You can always use Spring Framework 2.5. It is a big one, but if you planning to use only DI you can use spring-core and spring-beans modules, which are pretty small (ca. 500KB and 300KB).
There is also Google Guice 2.0 which comes with a package with only basic stuff (no AOP) and it's 430KB.
Have you looked at the Google Guice framework? It's pretty lightweight and annotation-based, avoiding XML configuration files
There's also Pico- and Nano-container (from codehaus) which are quite lightweight although the last time I looked (admittedly a few years ago) the documentation was lacking.
I must say that I agree with others about what I assume is your presumption that Spring is massive and confusing. It's really a very simple IoC container and to be recommended.
There are a couple I know of you might find useful:
PicoContainer
Plexus (used in Maven)
I've found Plexus very useful in standalone apps as it has optional utility components for CLI interaction.
By "gigantic" I'm going to assume you're referring to Spring, but that's unfair, since you can cherry-pick the bits of Spring you want to use. If all you need is the IoC container, just use the appropriate JAR files and the appropriate bit of the API, and ignore the rest of it.
Most answers so far seem to be concerned with the size of the jar files to be added.
However I think the more important question is the impact on the project: How many lines of code must be added/changed in order to use the framework?
Even the "big" spring framework is actually very easy to use:
You basically need:
a xml file that describes your factories.
one line of code to initialize the container by loading the xml file
The nice thing is that spring is non-intrusive. So you do not have to implement specific interfaces or add any specific annotations or imports to your classes.
At best the single spot where you actually initialize the Spring container is the only
place in your application that has an actual dependency to spring classes.
I would strongly suggest to take a look at Spring ME. Although originally meant to be a way to use Spring on Java ME applications, it also works fine for standalone applications.
True, it doesn't give you all of the bells and whistles that Spring (Full) has to offer, but then again, Full Spring is much much more than a simple dependency injection framework.
On the plus side: it's based on a (compliant) subset of Spring's configuration files, and the footprint of the runtime is 0%. In fact, there isn't any. Spring ME will take your application context, and turn it into a class that has no dependencies on classes other than your own.
What's wrong with Spring?
These days it's packaged pretty well so you wouldn't need to take the whole kit and caboodle.
As an aside, I'm not a fan of the annotation based injection frameworks. This is because the annotations are bound to the class rather than the instance, the later being a pre-requisite, imho, for DI. This means every instance of a given class gets the same object(s) injected, which seems to defeat the point.
Also consider that DI doesn't even need a framework, what's wrong with your main method wiring together the application?
If you want something maximally simple and appropriate, then write some code that does what you want done. Presumably this involves wiring together factories based partly on fixed logic, and partly on run-time settings.
This has the advantage that the set of possible run-time configurations is known, and so documentable and testable.
It has the disadvantage that an deploying an unanticipated logic change inherently takes an extra second or so of compile time, and (more significantly) can't be sneaked into production without full testing by disguising it as 'just a configuration change'.
About a year ago I asked myself a question very like this. So I spend a few hours reading the Spring and Guice documentation. After about an hour with Spring I was left feeling that I could get a basic web app going, but had no idea how to use it in a stand alone application. After an hour with the Guice document everything had clicked and I could see just how I to do what I wanted to get done.
Now on to recommending Guice? Well no. What does your team already know? If someone already knows say Spring leaver that knowledge and have them spread it about. Like wise with Guice or Pico.
If you want something really light weight you might want to have a look at fuse it's fairly extendable so might be what you're looking for.
cheers
N
Developers who have used eclipse cannot miss out the Cntrl+Shift+G combo - the easiest way to find all references to a particular member/method/class in your workspace.
Consider a scenario where you are a new guy maintaining a web application written in java. Now, you are about to change a method signature, and you do a Cntl+Shift+G to find all references to the said method (yes, hoping that you are not doing depedency injection / reflection etc). However, a new guy, would want not to screw up any functionality in the application. How would ensure that the functional dependencies are not affected?
I guess..the question is a bit unclear.. lemme rephrase... Say you are changing something functional (an if loop in a business rule or whateva) - this will definetly CHANGE something else in the context of the application.. and at this point you wish there was something (a plugin?) in eclipse, that would tell you - "hey noob..don't change this - it would affect this..." - Now, if you were to create something that does this for eclipse (plugin?) - where would you start? (tagging parts of scr code and introducing a depdency tree? etc?)
Perhaps I failed to understand your question, but I think I might have an answer. Take a look at nWire for Java (or PHP). It is a plugin for code exploration. Focusing on a piece of code, the developer can quickly determine where the method is invoked, where the class is used, etc. This makes it easier to understand what you are about to change.
I am the developer of this plugin. If it is not exactly what you are looking for, let me know, I'll be happy to better understand what you are looking for.
Besides: ALT+SHIFT+C is the way to change a method signature. ALT+SHIFT+G "only" finds references, which is helpful of course.
vickirk mentionend the most important aspect here: Without having tests and a good code coverage you aren't able to apply any changes without risking a failing system afterwards.
The book "Working Effectively with Legacy Code" from Robert C Martin explains it nicely: All code, which is not covered by tests, is legacy code. You could draw the conclusion, that before you apply any functional change you need to ensure a sufficient test coverage.
Tagging parts in the source code seems like a bad idea, since these tags need to be additionally maintained, which usually never really happens in projects. :)
What about JDepend?