Could someone recommend me an automatic migration tool for EJB?
Preferably some Eclipse plugin... Thanx!
I'd suggest using IntelliJ EJB refactoring tools:
http://www.jetbrains.com/idea/webhelp/migrating-to-ejb-3-0.html
Four years ago I wrote some tooling in perl. But from todays perspective I think going through the sources in a day, removing unneeded stuff and adding annotations by someone who has seen both technologies is the best.
It is at the end not enough to just put #Stateless into a bean class that had its stateless definition in xml before - you also want to use #EJB annotations to inject other beans and most likely remove old CMP or BMP data access with JPA, which uses a different semantics etc.
While some tooling may exist, I think best is going over the existing source with a fine comb so that you know what you are doing.
Related
I just started with symfony 4 and have a question about "multi-controller", if my application got many routes, should i go for more controllers to keep the files tiny and readable or is one controller enough / recommended?
There is no recommended way about multi-controllers on the official documentation.
If multi-controller is a good choice, how to split?
If there a good documentation on the inet?
Absolutely yes, you should have more than one controller. Symfony's best practices recommend to keep your controllers tiny and delegate much of your application logic to services that you create to handle different actions. For this, it is essential that you have a basic understanding of Dependency Injection, the Container pattern and, more specifically, how Symfony's DI Container works (how you can register services, for example).
There's tons of documentation on Symfony in the intenet. This one on controllers.
KnpUniversity has some really good tutorials to get you started. Start with the Symfony series, then follow with Symfony Internals.
Also, you will greatly benefit from the features of the maker bundle, that will generate code for you really quickly. You can install it with composer require maker. Then, you can create a controller running php bin/console make:controller.
I was going through the Symfony2 best practices and got confused on two things:
1 - Annotation usage - It says that for Routing and Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice?
http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused.
http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
Please note that "Best Practice" doesn't mean that doing anything different from what's suggested is wrong. Instead, anything is perfect if you know why you're doing it. The Best Practice guide is designed to take away some decisions for beginners. They already have a hard time learning the framework, having to make decisions like where to put code and which format to use would make things infinitely more difficult.
With that in mind, the reasons for the best practices you mentioned:
1 - Annotation usage - It says that for Routing n Cache we should use Annotations. But, I prefer to use annotations for ORM & Validation and YAML for Routing (one single file for all routes). How it is a bad practice? http://symfony.com/doc/current/best_practices/controllers.html#routing-configuration
Having less files makes it easier to follow what's going on. Imagine having a route, controller, an entity and some validation. This means that one has to learn the following locations: app/config/routing.yml, src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php, src/AppBundle/config/validation.yml and src/AppBundle/config/doctrine/SomeEntity.orm.yml. That's quite a big list to get familair with.
If Symfony recommends to use annotations for everything, you end up with the following list: src/AppBundle/Controller/StaticController.php, src/AppBundle/Entity/SomeEntity.php. That's quite an improvement. This is the reason that Symfony recommends to use annotations if you're starting to learn the framework. If you're familiar with Symfony, you probably make your own choices and decide which format you like and which you don't like (some people like annotations, others hate them and prefer XML or YAML).
2 - For reusable bundle (never created one), if I wish to include any JS library like jQuery then it's not a good practice? Confused. http://symfony.com/doc/current/cookbook/bundles/best_practices.html#vendors
It's often not very great to commit dependencies. For that reason, Composer was created. For front-end dependencies, Bower/BowerPHP was created. Using something like that means your code is easier to share.
Of course, as Symfony is a back-end framework, it's perfectly fine to use jQuery or whatever library you like.
1.that say:
Make your controller extend the FrameworkBundle base controller and use annotations to configure routing, caching and security whenever possible.
for that you have thin controller and you can only have routing & caching & security in your controller as annotaion.
orm mapping & validation are in entities no in controller
and that say:
In addition, using annotations for routing, caching and security simplifies configuration. You don't need to browse tens of files created with different formats (YAML, XML, PHP): all the configuration is just where you need it and it only uses one format.
because, routing & security & caching are related to a controller, but orm mapping & validation are diffrence and can use in onther places(controllers, repositories, services and ...)
2.
For reusable bundle (never created one), if I wish to include any JS library like JQuery then it is not good practice
and if you will use third-party bundles, that is better that you use a depedency manager as composer or bower.
see sonata admin bundle that is a good & big project that use bower for third-party bundles as jquery, bootstrap & ...
Let me preface this by saying that I am normally not a PHP developer, and am a complete beginner when it comes to Symfony2. I was kind of thrown into this project, and we are on a pretty tight deadline.
With that out of the way, here is my problem:
At my company, we have a PHP library for an internal API which is old; it doesn't use namespaces and it doesn't really follow any standard naming convention such as PSR-0 or PEAR. However, I need to use this in our Symfony2 project. Symfony2 obviously relies on namespaces a lot. Am I completely screwed if I don't update the library to follow the "new" conventions, or can I somehow use it anyway? The thing is, it is a pretty huge library, and we simply don't have time to do that right now (someone should have done it ages ago, but that is another topic...).
Theoretically, could I just place the lib under vendor/ and use good old old requires/includes in my bundles? Will this even work? Will I get a mob of angry Symfony/PHP developers after me by doing this?
Or, is there a better way that I'm not aware of?
You can do what you suggested, and you can even use the MapClassLoader, and give it a static map between your classes and your files, so that you don't even need to require files from your library. You don't have to write this map by hand, you can generate it with the class map generator
I am looking for an easy way to use HSQLDB with an OSGi Servlet. I allready created an OSGi Bundle out of the HSQLDB.jar following this guide:
http://www.vogella.com/articles/EclipseJarToPlugin/article.html
But now I can't seem to figure out how to use the HSQLDB from a Servlet inside another Bundle. I can't find any good step by step guides either. I would appreciate if someone could point me into the right direction.
Thanks in advance
HSQLDB has an 'official' bundle in the MvnRepository. Generally it pays off to look around for bundles before converting one yourself. Sometimes it's easy, but often it's trickier to get right.
Mind you, the article you quote is quite old and (while still correct as far as I can see), there are many more possibilities nowadays.
In any case, to work in OSGi, you need to understand how services work. From that point on, servlets are services, and no different than any other service.
When I started fooling around with OSGi, the Felix documentation was a great help to me. I also recommend taking a look at Declarative Services.
What are the benefits of Spring Actionscript considering Dynamic Proxies are not possible in the current version of Actionscript and Reflection is quite limited.
So for example I could specify my object creation in an XML application context, but why would I do that when I can simply specify that in code, and hence take advantage of static type checking etc.
It is by no means my intent to belittle the work done on Spring Actionscript but more to find an application for it in my projects.
Besides XML configuration, Spring ActionScript also supports MXML configuration. The type of config (XML, MXML) depends on the use cases your application needs to support. For the reasons you mention, it makes perfect sense to configure most of the context in MXML, but I would encourage you to externalize the config of service endpoints in every case.
In a past project we opted for XML config since the configuration was generated at runtime when a user logged on to the application. Depending on the user credentials, different endpoints and various different settings were used. We could not have done this elegantly with static MXML configs.
Both config types have their strengths and weaknesses, and it's up to you to decide what type you want to use. I think we could even support a mixture of MXML and XML quite easily actually if that would make sense. As soon as we have Dynamic Proxies and class loading, XML config will make a lot more sense.
I would agree with Sean in the general sense that trying to force Flex inside of the Java box is generally a bad idea. As many similarities as there are, Flex is not Java.
That being said, there are plenty of reasons why you might want to have some of your configuration in an external XML file, not the least of which is in the use case of configuring your service destinations and endpoints, where you may have a need to be able to change the endpoint URI without having to recompile your application.
There are several projects available that are simply misguided ports of philosophies from other platforms. Whenever starting in on a new platform, I think the best thing to do is figure out how people are effectively developing and go from there.
I say all of that because I think all of the java-esque frameworks for flex/flash leave you worse off than you started. You do need dependency injection, but there are good as3/mxml-friendly frameworks for that (Mate, Swiz). There is absolutely no point in using xml when you can use mxml, which is strongly typed.