Alexey Saenko

Ranch Hand
+ Follow
since Aug 18, 2008
Alexey likes ...
Eclipse IDE Spring Chrome
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexey Saenko

Hi all,

Does anyone know, how could be possible to read a Websphere Variable (created in Environment -> WebSphere Variables) within Spring configuration file? It looks like ${VARIABLE_NAME} is not working. Any further advices are welcome.

Thanks in advance.
7 years ago
Hi Santhosh,

take a look at stackoverflow, that problem seems to be quite similar to yours.
Finally, it started to work with the following configuration.

persistence.xml

web.xml

spring-beans.xml
7 years ago
@Kathleen for the moment there is only one datasource.

I've also forgotten to mention that persisting runs as follows
7 years ago
Hi all,

The problem is in the following. There is Websphere 8.5 application server where is set up XA datasource. And there is an application which is written on Spring 3.2.2 with Hibernate 4.1.7. I have a DAO class which has one persist() method marked with @Transactional annotation and should just persist an object to the database. As a result it returns persisted object with id (hibernate performs request for the new one), but actually the object is not written to the database and there are no stacktraces in the logs. TransactionSynchronizationManager.isActualTransactionActive() returns true in the method persist().

All persistence objects are configured with annotations.

Spring configuration is in xml-form and looks like this:

Do you have any ideas how could I make DAO save an object to the database?

Thanks in advance.
7 years ago
In other words, in terms of practice in the case of field-based access a developer annotates instance variables and in the case of property-based he (or she) annotates getters/setters, right? Is there really so big difference between such styles to annotate? It looks like these styles are completely identical. Am I wrong?
Hi guys,

There is written:

EJB3 in Action wrote:Defining O/R mapping using fields or instance variables of entity is known as field-based access, and using O/R mapping with properties is known as property-based access.



I have some doubts about the following questions:
What do the authors mean under "field-based access" and "property-based access"? What are fields and properties? and what is the difference between them?

Thanks a lot in advance,
Alex.
The @DeclareRoles annotation specifies all roles which are used in the given class (or method). Also it is possible to specify the roles list in DD. In case there is no specified roles neither in DD nor with @DeclareRoles annotations, the container builds the list automatically by inspecting the @RolesAllowed annotation.
hi Amru,

what exactly do you not understand?

The main idea (from "ejb3 in action") is stateless session beans are the beans which are not able to maintain conversational state.

As you may know stateless session beans are pooled and when a client invokes any method the container takes an instance of stateless session bean and then invokes this method. And it doesn't matter which exactly instance is chosen to invoke.

Hope, this will help.. isn't it?
yes, annotations are necessary for 310-091 exam. I think it would be useful for to read "ejb3 in action"
Physically, they can be used in beans, but it makes a hole in security of this application. Therefore they should not be used.
Hi Duran,

I think that this is about unsafety of attempts to use Reflections API to define (get access to) package/class and so on.

Deepthi Tirunahari wrote:The spec says

To support this case, the container must only inject a value for the environment entry if the application
assembler or deployer has specified a value to override the default value.


Can anybody explain the above statement. Does this mean that we should always specify <env-entry-value> in the dd even after we have given a default value in @Resource int maxExemptions = 4;. But that doesn't make sense.



I thinks this means the following: if a value for the env-entry has been specified, container must and will inject it. If there is no value in env-entries, container must not and will not inject this value and default value will be used. Also, env-entries always overrides default values (and those which were set in code, like int x = 4), because firstly jvm must create an object (or primitive) and then read the value from DD.

So, we can write down something like this in the bean code:
Hi Vish,

I think you can see all necessary topics (or objectives) here and also it will be useful to take a look at Mikalai Zaikin's SCBCD5 Study Guide (it contains information already grouped by exam objectives).

Good luck in preparing!