Today I found an interesting fact. In OSX you have to sign apps otherwise a popup will get on your nerves. So users look for a workaround and sign apps manually. Does that really make sense if users start doing it with every app they would like to try?
It's actually pretty easy.
Check an application with:
codesign --verify --verbose /Applications/myapp.app
If this states that the certificate is invalid, you can use:
codesign -s [name of the certificate] -f /Applications/myapp.app
It requires a special certificate for signing code.
(See Certificate administration)
Start the application with the admin account.
Samstag, 31. Dezember 2011
Mittwoch, 24. August 2011
If it's too easy to be true
There are a lot of Java EE demos, slides and even documentations out there which show how easy and awesome a use-case can be solved which used to be complex in the past.
The summary:
Don't trust such slides without checking it on your own, if they are published by someone who would like to sell you something. That also applies to open-source companies. Usually it isn't that simple.
The details (by example):
There are a lot of slides and examples out there which show how simple it is to write CDI producers for JPA entities and conversation scoped entity managers. Esp. some Seam folks are publishing it on a regular basis. At the beginning it sounds just awesome but it turns out that it doesn't work well in medium to large sized applications. If you write your small intranet application for organizing your after-work party for your small department, go with it. But in all other cases don't use it.
The problem is that you have two containers (JPA and CDI) which manage the lifecycle of one bean/entity. In some cases it works with @New but it's very dangerous at all. With a simple producer (just using @Produces) you get dependent scoped beans. In the best case you inject it in a request scoped bean and you get a request scoped entity and your persistence provider can handle proxies created by the CDI implementation you are using. But in this case you can directly inject the service in the request scoped bean and load the entity which is even simpler than writing a producer for it. Otherwise, you get problems because you have a session or conversation scoped or custom scoped JPA entity. An entity manager just doesn't work that well with those scopes because it isn't serializable. Hibernate and with some configuration maybe also some other persistence providers supports it and in this case e.g. session replication is possible but doesn't scale (because the state of an entity manager tends to get large) and you have again a vendor lock-in because not every JPA implementation can handle proxies used by the CDI implementation. If you are ok with a vendor lock-in, you can use better ORM frameworks than any JPA implementation can be at the moment. For example eBean is awesome and you can continue to use JPA annotations for mapping your entities. If you like to keep it portable and correct and scaling, you have to use a request scoped entity manager. So you get a detached entity and you have to merge it back on subsequent requests. At this point there is just no point in injecting an entity compared to injecting the service and loading the entity. Furthermore, the idea shown by such slides,... just works for simple cases which require one instance of an entity. Otherwise you have to create qualifiers and the result gets even more complex. Furthermore, you have to provide the id of the entity to such producers, so you have to store them in the same bean as the producer (-> learn more about Java EE or your project will fail) or you can provide it as parameter to the producer and CDI will inject it (-> you created two producers for a simple use-case which just works in simple scenarios -> think about it ;-) ).
The conclusion:
Think beyond very simple demos from the very beginning and don't trust others just because they are e.g. the vendor of something. It's their job that it looks simple and awesome to you. It's better if you look at real communities like Apache projects (catchword: "Community first") which create stuff because they need it for their own big (and real) projects. If you find something which is too good to be true, it's always a good idea to check if there is an Apache project which does similar stuff. Check their documentation (if there is one), JIRA and even source-code or directly send a question to the community. E.g. after checking the Wiki of CODI I found out that they added some similar information about conversation scoped entity managers. It's good to know that there are people out there who don't try to sell you something and provide solutions you can tend to trust immediately, because it doesn't make any difference for them if they have 100 or 100.000 users.
The summary:
Don't trust such slides without checking it on your own, if they are published by someone who would like to sell you something. That also applies to open-source companies. Usually it isn't that simple.
The details (by example):
There are a lot of slides and examples out there which show how simple it is to write CDI producers for JPA entities and conversation scoped entity managers. Esp. some Seam folks are publishing it on a regular basis. At the beginning it sounds just awesome but it turns out that it doesn't work well in medium to large sized applications. If you write your small intranet application for organizing your after-work party for your small department, go with it. But in all other cases don't use it.
The problem is that you have two containers (JPA and CDI) which manage the lifecycle of one bean/entity. In some cases it works with @New but it's very dangerous at all. With a simple producer (just using @Produces) you get dependent scoped beans. In the best case you inject it in a request scoped bean and you get a request scoped entity and your persistence provider can handle proxies created by the CDI implementation you are using. But in this case you can directly inject the service in the request scoped bean and load the entity which is even simpler than writing a producer for it. Otherwise, you get problems because you have a session or conversation scoped or custom scoped JPA entity. An entity manager just doesn't work that well with those scopes because it isn't serializable. Hibernate and with some configuration maybe also some other persistence providers supports it and in this case e.g. session replication is possible but doesn't scale (because the state of an entity manager tends to get large) and you have again a vendor lock-in because not every JPA implementation can handle proxies used by the CDI implementation. If you are ok with a vendor lock-in, you can use better ORM frameworks than any JPA implementation can be at the moment. For example eBean is awesome and you can continue to use JPA annotations for mapping your entities. If you like to keep it portable and correct and scaling, you have to use a request scoped entity manager. So you get a detached entity and you have to merge it back on subsequent requests. At this point there is just no point in injecting an entity compared to injecting the service and loading the entity. Furthermore, the idea shown by such slides,... just works for simple cases which require one instance of an entity. Otherwise you have to create qualifiers and the result gets even more complex. Furthermore, you have to provide the id of the entity to such producers, so you have to store them in the same bean as the producer (-> learn more about Java EE or your project will fail) or you can provide it as parameter to the producer and CDI will inject it (-> you created two producers for a simple use-case which just works in simple scenarios -> think about it ;-) ).
The conclusion:
Think beyond very simple demos from the very beginning and don't trust others just because they are e.g. the vendor of something. It's their job that it looks simple and awesome to you. It's better if you look at real communities like Apache projects (catchword: "Community first") which create stuff because they need it for their own big (and real) projects. If you find something which is too good to be true, it's always a good idea to check if there is an Apache project which does similar stuff. Check their documentation (if there is one), JIRA and even source-code or directly send a question to the community. E.g. after checking the Wiki of CODI I found out that they added some similar information about conversation scoped entity managers. It's good to know that there are people out there who don't try to sell you something and provide solutions you can tend to trust immediately, because it doesn't make any difference for them if they have 100 or 100.000 users.
Dienstag, 23. August 2011
Java EE - all you need
This week we are going to finish our 3rd very large (100.000 LoC pure business logic) Java EE5+ project.
Some years ago, we started our first Java EE5 project with Seam2 but it didn't meet our needs. So we refactored it to Spring2 and Orchestra. Compared to Seam the conversation concepts of Orchestra were a lot better. With Java EE6 we tried to implement a whole project with Java EE6 without any other libraries. At the beginning it was a bit hard but we found workarounds for most things, but it got worse. Since we thought Seam3 should be better than Seam2 we gave it a try. If you ask me, they completely failed. Back then a colleague said that they should change the versioning. Seam3 is a complete new implementation and shares only the name with Seam2 and therefore we started calling it Seam 0.3 which reflects the current situation much better. So we thought that our project is going to fail because it was too late to refactor it to Spring3 and Orchestra. More or less in the last minute before we escalated it, we found MyFaces CODI (0.9.2 back then) and we saw it as our last chance to finish our project successfully. After reading the Wiki we already felt the potential and after about one week we called it CODI 9.2 because it was that awesome and very stable. We had almost no problem with it. It was the first week we could concentrate on our business-logic instead of thinking about workarounds or nasty bugs. In the 3rd project we started with Java EE 6 + CODI from the very beginning and we started to use some of the impressive features like type-safe view-configuration and navigation, custom project-stages,... . We didn't use it before, because there was no time for trying too much new stuff.
Conclusion:
If you would like to implement Java EE6 applications, you realy realy should give MyFaces CODI a try. It's just amazing what they did. Currently we are using 1.0.0 but today they announced 1.0.1 (that reminded me to blog about it). So don't think about what big marketing departments tell you and ignore that Open-Source projects tend to use humble version numbers. The result for us is one of the best application architectures we have seen, tested and used since we are implementing enterprise level applications and the productivity increased a lot!
Some years ago, we started our first Java EE5 project with Seam2 but it didn't meet our needs. So we refactored it to Spring2 and Orchestra. Compared to Seam the conversation concepts of Orchestra were a lot better. With Java EE6 we tried to implement a whole project with Java EE6 without any other libraries. At the beginning it was a bit hard but we found workarounds for most things, but it got worse. Since we thought Seam3 should be better than Seam2 we gave it a try. If you ask me, they completely failed. Back then a colleague said that they should change the versioning. Seam3 is a complete new implementation and shares only the name with Seam2 and therefore we started calling it Seam 0.3 which reflects the current situation much better. So we thought that our project is going to fail because it was too late to refactor it to Spring3 and Orchestra. More or less in the last minute before we escalated it, we found MyFaces CODI (0.9.2 back then) and we saw it as our last chance to finish our project successfully. After reading the Wiki we already felt the potential and after about one week we called it CODI 9.2 because it was that awesome and very stable. We had almost no problem with it. It was the first week we could concentrate on our business-logic instead of thinking about workarounds or nasty bugs. In the 3rd project we started with Java EE 6 + CODI from the very beginning and we started to use some of the impressive features like type-safe view-configuration and navigation, custom project-stages,... . We didn't use it before, because there was no time for trying too much new stuff.
Conclusion:
If you would like to implement Java EE6 applications, you realy realy should give MyFaces CODI a try. It's just amazing what they did. Currently we are using 1.0.0 but today they announced 1.0.1 (that reminded me to blog about it). So don't think about what big marketing departments tell you and ignore that Open-Source projects tend to use humble version numbers. The result for us is one of the best application architectures we have seen, tested and used since we are implementing enterprise level applications and the productivity increased a lot!
Samstag, 20. August 2011
Yes - again a new Blog :-)
This blog will show what really works in large Java EE Web-Applications. Our base principle is: "Use only the best piece of Software for your projects".
Abonnieren
Posts (Atom)