We Keep Coding

File operations with Wildly Ejb implementation

I want to make some file operations (copy) in stateless EJB Method. I know about not recommndig to do it. But it could be possible for some special EJB implementation. What is the best thing for Wildfly ?
EDIT Some disturbing old links:
"Sun blueprint: EJB Restrictions"
EJB Bad Practices: Use of Java I/O
Stackoverflow

What is the best thing for Wildfly ?
Just doing the file operation (seriously). It's not as-if there's a security manager installed to prevent you from doing this.
And a stateless EJB is not different from many other types of methods in beans in Java EE. It's not the case, as some people think, that it's not allowed in EJB methods but is allowed in CDI bean methods. This is simply not the case.
There's some old information out there, where the spec said that "EJB was not allowed to". But what was actually meant is that Java EE was not allowed to. At the time EJB was seen as equivalent to Java EE, so that's the origin of this wide spread confusion.
Later this myth was starting a life of its own where people dreamed up scenarios where it was supposedly allowed to do IO in Servlets, but not from an EJB, so they designed all kinds of crazy architectures to delegate IO (or threading, another favorite) from an EJB to a Servlet. Absolutely ludicrous!
The restriction (as mentioned above, intended for the whole of Java EE, not just EJB) was also put in too eagerly. There's simply no reason to absolutely forbid it.
Some of the answers that you quote are more retroactive reasons. People just make up reasons for a rule to somehow justify their world, even though the reason and the rule don't match.
For this reason, the rule has been removed from the EJB spec.
That's right, in the current EJB spec you will not longer find that it's forbidden to use IO from an EJB (which, again, never meant to say "EJB", but should be read as "Java EE").
See:
https://blogs.oracle.com/marina/entry/ejb_3_2_news
https://blogs.oracle.com/arungupta/entry/what_s_new_in_ejb
Of course, as with many things, you may or may not have to be cautious when using IO, but this is completely unrelated to Java EE or EJB and holds for almost any application, and is more dependent on the kind of IO, the kind of application you're coding and your situation.
Two small extreme examples:
Your very own personal Java EE application of which you are the only developer that you installed at home on your raspberry pi and that reads a small configuration file at startup from an external location -> pretty much always okay.
Large clustered enterprise application being developed by many different teams, integrated separately, deployed separately, highly transactional that wants to write temporary data to a filesystem but that has to be cleanedup again when the transaction ends -> likely not such a good idea.
Between those two that are literally an infinite amount of variations. We had for example a larger enterprise application that did IO to an external folder from a Singleton in a very controlled and specific way. The app served millions of users under intense load and there was never a problem with the IO. So even "enterprise" and "transactional" do not necessarily have to mean "no IO". It really depends.

How Spring and Hibernate with JPA enabled enterprise applications can be helpful to the business?

I was asked this question in an interview. My answer was as follows.
Spring makes Java/J2EE development easier, more efficient and more productive. Hibernate helps to get rid of complex and tedious data access code and reap the benefits of object oriented principles.
By blending spring with hibernate we can create scalable, robust, maintainable and database independent enterprise applications at lightning speed thus reduce time to market.
I am not satisfied with my answer as interviewer was expecting answer in business perspective and my answer was far away and has technical details.

Some of the key points I'd say is cost (it's open source, which means no licensing fees), speed of application development (turnaround time from getting an idea to having a deliverable is much shorter compared to other frameworks), portability (you can move the application to any server and it will more likely than not just work out of the box), flexibility (making changes to business logic is quick and easy), maintainability (java has been around for a long time and probably will be around for much longer, finding developers to work on the project in the future won't be that difficult as it is when using legacy code), stability (since the architecture is build upon a stable platform, downtime should not be an issue), scalability (if the userbase grows rapidly, moving to a cloud environment is straight forward, no extra cost changing the application)

If you agruee with Business Guyes you must use the terms:
cost (total cost of owner ship)
time to market
productivity
All what you said was right, but you missed the business related conclution:
"Spring, Hibernate, ... help to develop applications faster and in a very porductive style, so the time to market is reduced. On the other hand Spring and Hibernate tend the programmer to produce more maintainable and tested code. This will reduce the cost to maintain the software and provide the posibility to enhance the application at realative low cost."

spring + hibernate framework with jpa is provided a productive application. Because the framework is divided in to the layer that's why the new programmer can easily understand and can change easily in to the enterprises project. spring framework provides the dependency injection that means no need for the manually creation of object through the new key word. while spring provide the object and only programmer focus on the used of object. And hibernate is a orm framework which is fully rich in relation database. It used save/update/delete the data into the table by taking the java object only. It reduce the java code for the database connectivity and writing the sql query and much more . hibernate provide the methods for dml(data manipulation language) operations.

the Spring is the ultimate framework, and the hibernate supoort of it is just amazing,
it help a lot,
security features, helpful in TDD programing,
unit test, integration testing etc.
it is very helpful in maintaining very bulky project very easily.
today most of the heavy projects managers prefer spring with hibernate
hope it is helpful to you
thanks

Session Beans and EJB3 vs Spring

I was curious about the capabilities of Sessions Beans in EJB 3 and whether they can be replaced in a typical mid-scale enterprise application with Spring.
I found this article:
http://drag0sd0g.blogspot.com/2010/01/session-bean-alternative-spring.html
that states the following: "Because of heavy use of annotations,
you can pretty much avoid “XML Hell” using EJB 3; the same cannot be said of Spring.
Moreover, because it is an integral part of the Java EE standard, the EJB container
is natively integrated with components such as JSF, JSP, servlets, the JTA transaction
manager, JMS providers, and JAAS security providers of your application server. With Spring, you have to worry whether your application server fully supports the framework with these native components and other high-performance features like clustering, load balancing, and failover. If you aren’t worried about such things, then Spring is not a bad choice at all"
Do you agree with this statement? The Stateless Sessions Beans used to be considered a very powerful enterprise technology because of the pooling and management capabilities. My question is: when is it really necessary to use EJB 3 instead of or in addition to Spring (assuming a mission critical enterprise application in a large company)?

Looks like yet another Java EE vs. Spring post...
EJB/Java EE and Spring are now two mature, competitive Java-based technology stacks. Often there's no reason to complicate things and mix them up. EJB actually learned and used many ideas from Spring et al.
Neither of them drives you into the XML/configuration hell. Both are fairly easy to get started with, at least with the very basic stuff.
Spring is more than just IoC/SOA/transactions. It's more like a toolbox - it's ready to integrate with, or directly provides, frameworks for ORM and transactions, web/MVC, security, timers/scheduling etc. You can pick exactly the pieces you need. You're not forced to use a container (you can use it in your standalone "desktop" app).
EJB is part of Java EE stack. It is, well, the standard. It's not as broad, flexible as Spring, but it's by definition supported by all Java EE containers.
I prefer Spring for the freedom and being one step ahead.

I don't think there are many cases when the use of EJB 3 instead of Spring is absolutely necessary, but there are cases when using EJB 3 would be considerably easier. As the article states, the main advantages of EJB is the integration with the various other JEE technologies and, as of EJB 3, Enterprise Beans are much simpler to write than in they were in previous versions of the spec.
The classic reason for using EJB over POJOs or other middleware technologies is transactions. If your business logic needs to be transactional then EJB provides simple, declarative transnational demarcation and seamless integration with JTA via the container. While the article suggests that support for clustering, load balancing and performance management is an advantage, this is very much dependant on your choice of JEE application server.
I'd say the key factor in deciding whether to use Spring or EJB 3 is your container. If your target container is a fully JEE 5+ compliant application server and you need support for services such as transactions or messaging then EJB 3 is the obvious choice. If, however, you don't need to integrate with other JEE technologies or are deploying to a light-weight app server then using EJB would simply add unnecessary overhead.

How can anyone think EJB3's defining a data model using a series of java annotations spread out over several classes is superior to Hibernates simple model definition syntax is beyond me.
Its a maintainability nightmare. Why have you got an intersection table? It may be defined almost anywhere in the code base. Some junior programmer plays with the annotations and now your java classes are out of sync with the actual database.
Got a performance issues (and you will). Not only have you got the classic Hibernate "I don't know what SQL it's using" you also have the "I don't know why the table was built like that" problem.

Why and when to use EJB-based web services?

To transfer data from one system to another, through data interface, by web services, we normally get a result set by SQL query, and format them as a web service endpoint, and allow it to be retrieved by another side.
With EJB 3.0, it seems we can replace the result set by stateless session bean. So are there any advantages over the SQL-based web services? And when should we use it?

This is a very broad question on the system architect level. I will try to answer with my best knowledge without starting a flame war (FYI, I have used both ejb and spring).
As you know, building a stable/robust software application requires many building blocks, such as logging, connection pool, etc. Usually, you can find libraries of these building blocks, but not all of them have common api, so they may require integration. In the worst case, you may have to lock into some vendors. The main idea of EJB 3 (or Java EE) is to provide a more complete set of building blocks (via API, annotation or config), so developers can start working on the core business logic right away with an industry standard API/spec/config without training on the proprietary APIs. Additionally, you can change vendor without changing your codes since API/config are really the industry standard (well, your mileage may vary a lot in the real life. hopefully, the new Java EE will fix it).
Your application may already have some of the main elements that EJB 3 already provides. However, EJB 3 promises to provide more such as ORM mapping, RMI, Load balancing, failover, transactions, dynamic redeployment, logging, system management, thread managing, resource pooling (db connection), security, caching.
As you have an working application already, you can really consider if it is worth of your efford to migrate your codes to a standard system to gain more functionality vs integrate new functionality individually. Additionally, EJB 3.0 (or Java EE) is not really the framework that you can pick. You can also look into other framework, such as Spring.
My suggestion is to really figure what your system requirements, and then pick the right technologies instead of picking up the coolest technologies first.
Good luck

Should I use EJB3 or Spring for my business layer?

My team is developing a new service oriented product with a web front-end. In discussions about what technologies we will use we have settled on running a JBoss application server, and Flex frontend (with possible desktop deployment using Adobe AIR), and web services to interface the client and server.
We've reached an impasse when it comes to which server technology to use for our business logic. The big argument is between EJB3 and Spring, with our biggest concerns being scalability and performance, and also maintainability of the code base.
Here are my questions:
What are the arguments for or against EJB3 vs Spring?
What pitfalls can I expect with each?
Where can I find good benchmark information?

There won't be much difference between EJB3 and Spring based on Performance. We chose Spring for the following reasons (not mentioned in the question):
Spring drives the architecture in a direction that more readily supports unit testing. For example, inject a mock DAO object to unit test your business layer, or utilize Spring's MockHttpRequest object to unit test a servlet. We maintain a separate Spring config for unit tests that allows us to isolate tests to the specific layers.
An overriding driver was compatibility. If you need to support more than one App Server (or eventually want the option to move from JBoss to Glassfish, etc.), you will essentially be carrying your container (Spring) with you, rather than relying on compatibility between different implementations of the EJB3 specification.
Spring allows for technology choices for Persistence, object remoting, etc. For example, we are also using a Flex front end, and are using the Hessian protocol for communications between Flex and Spring.

The gap between EJB3 and Spring is much smaller than it was, clearly. That said, one of the downsides to EJB3 now is that you can only inject into a bean, so you can end up turning components into beans that don't need to be.
The argument about unit testing is fairly irrelevant now - EJB3 is clearly designed to be more easily unit testable.
The compatibility argument above is also kind of irrelevant: whether you use EJB3 or Spring, you're still reliant on 3rd party-provided implementations of transaction managers, JMS, etc.
What would swing it for me, however, is support by the community. Working on an EJB3 project last year, there just weren't a lot of people out there using it and talking about their problems. Spring, rightly or wrongly, is extremely pervasive, particularlty in the enterprise, and that makes it easier to find someone who's got the same problem you're trying to solve.

What are the arguments for or against EJB3 vs Spring?
Spring is always innovating and recognizes real-world constraints. Spring offered simplicity and elegance for the Java 1.4 application servers and didn't require a version of the J2EE specification that no one had access to in 2004 - 2006. At this point it is almost a religious debate that you can get sucked into - Spring + abstraction + open-source versus Java Enterprise Edition (Java EE) 5.0 specifications.
I think Spring complements more than competes with the Java EE specifications. As the features that were once unique to Spring continue to get rolled into the specification, many will argue that EJB 3 offers a 'good enough' feature set for most internal business applications.
What pitfalls can I expect with each?
If your treating this as persistence issue (Spring+JPA) versus EJB3 your really not making that big of a choice.
Where can I find good benchmark information?
I haven't followed the specj benchmark results for sometime, but they were popular for a while. It seems that each vendor (IBM, JBOSS, Oracle, and Sun) get less and less interested in having a compliant server. The lists get Shorter and shorter of certified vendors as you go from 1.3, 1.4. 1.5 Java Enterprise Edition. I think the days of a giant server that is fully compliant with all the specifications are over.

I would definitely recommend EJB3 over spring. We find that it's more streamlined, nicer to code in, and better supported. I have in the past used Spring and found it to be very confusing, and not as well documented as EJB3 (or JPA I guess at the end of the day)
As of EJB3 you no longer have to deal with external config files, and there's only one POJO that you annotate per database table. This POJO can be passed to your web tier without any problems. IDEs like Netbeans can even auto-generate these POJOs for you. We've used EJB3 now as the back end for quite a few large scale applications, and haven't noticed any performance problems.
Your Session Beans can be easily exposed as web services which you could expose to your Flex frontend.
Session beans are easy to lock down at either a method or class level to assign roles and things like that if you need to.
I can't speak that much about spring, as I only tried it out for a few weeks. But my overall impression of it was very poor. That doesn't mean it's bad framework, but our team here has found EJB3 to be the best for the persistence/business layer.

I tend to prefer Spring over EJB3 but my recommendation would be whichever approach you take, try to stick to writing POJOs and use the standard annotations where possible, like the JSR annotations such as #PostConstruct, #PreDestroy and #Resource which work with both EJB3 or Spring so you can pick whichever framework you prefer.
e.g. you could decide on some project to use Guice instead for IoC.
If you want to use pre-request injection such as in a web application you might find Guice is quite a bit faster for dependency injection than Spring.
Session beans mostly boil down to dependency injection and transactions; so EJB3 and Spring are kinda similar really for that. Where Spring has the edge is on better dependency injection and nicer abstractions for things like JMS

i have used a very similar architecture in the past. Spring + Java 1.5 + Actionscript 2/3 when combined with Flex Data Services made it all very easy (and fun!) to code.
though, a Flex front end means you need adequately powerful client machines.

Regarding your question:
What are the arguments for or against EJB3 vs Spring?
I suggest reading the response from the experts: A RESPONSE TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher. Read the comments to find Reza Rahman's remarks (EJB 3.0).

Another thing in favor of spring is that most of the other tools / frameworks out there have better support for integration with spring, most of them use spring internally as well (e.g. activemq, camel, CXF etc).
It is also more mature and there are a lot more resources (books, articles, best practices etc) & experienced developers available than for EJB3.

I think EJB is a good component technology but not a good framework.Spring is the best framework available as of today.So i should consider Spring as the best implementation of JEE in the sense of a framework and my recommendation is to use spring in every project which gives us the flexibility to integrate with any component technology easily .