Transfer Object pattern question

Hi, developers!
I created a Transfer Object pattern class, that has an array field. See below:
class TOClass {
private int[] values;
//notice that I am using clone() method
public int[] getValues() {
return (int[])values.clone();
public void setValues(int[] values) {
this.values = (int[])values.clone();
}Would you do like I did?
Thanks in advance!

Thank you, you all!
I am testing the solution you presented, Saish, and I am verifying yet. But I see that the problem of manipulation of data continues, like dubway said. But, this discussion gave me a lot of ideas! (I didn�t know Collections.unmodifiableList() method yet, very interesting method). I will continue my researchs for the best solution.
But I have to worry only when the getter method is used, because I don�t know what other developers will do with the value returned. I don�t need to worry about setter, because the only person that sets is me, and nobody else.
And one more thing. My TO class does not contain only one field. There are other fields: Strings, BigDecimals, etc, but these other fields are easy, I just have to create getters and setters for them. There is only one field that has the "behaviour of an array". But because of the fact that there are other fields, to not make this class complicated and "dirty" visually, I really want to use simple getters and setters methods, only. Your solution is not providing getters and setters exactly, Saish. I want to follow the Transfer Object pattern, whose feature is the existence of getters and setters, only.

Similar Messages

Transfer Object Pattern and Concurrency Transaction Mgmt

I am developing an application that implements a remote rich client. For
performance reasons I have chosen to use the Transfer Object pattern. I
have been very successful with this from a performance standpoint, it
really paid off. I am using it in combination with an assembler pattern
to construct Transfer Objects for the view and to also reassemble domain
objects based on changes made to transfer objects on my client side.
Anyways the only problem I am having with it is I can't seem to figure
out how I should implement optimistic locking with it. Is there a best
practices to handle transaction control here?
I generally try to keep visibility of stale data down, but there are still
situations where concurrent clients could have requested to edit the same
the Transfer Object at the same time. I would ideally like to handle this
using a flavor of optimistic locking. I in fact have implemented
optimistic locking on the domain side, but now I am not sure how or if I
should integrate this into the Transfer Object or View side. The version
field used in optimistic locking is generally a hidden field. The only
way I can see to handle this with the view side is to expose this field on
the Domain Objects and actually store it into assembeled transfer objects.
This seems like it may be a bad idea from a design standpoint.
The problem is the client requests data and it assembled and delivered to the client. Then at some later time the client may send a request to the server to update this data. At this time a new transaction must be started where the server reloads the domain data and copies over the requested changes. Since the domain data was just loaded you wouldn't ever trigger a versioning problem unless the version was maintained on the transfer object and copied over as well. I am developing this project with hibernate on the back end and unfortunately hibernate doesn't acknowledge manual changes to the version field.
I just feel like there must be a better way to do this. I believe that using the Transfer Object or DTO pattern for remote client/server architectures is pretty common. So there must be a best practice to deal with concurrency? Suggestions, insight, lay it on me please.
thx

I personal respect both concepts and am using both in an application I am currently work.
Firstly, I have my Transfer Object which I call xxxData.
Next, the entities are called xxx
I have my DAO classes that handles all CRUD operation. but within the DAO class I have two methods
private <EntityClass> retrieveEntityFromObject(<EntityClassData> data) {}
private <EntityClassData> retrieveEntityFromObject(<EntityClass> entity) {}so with these methods, I separate my business logic from my data layer. My codes will alway use data objects instead of entities. For example, a create method will be
public ProductData createProduct(ProductData data)
entity.persist(retrieveEntityFromObject(data));
}I hope someone understands
Regards

Adobe Flex + PHP (Using Data Transfer Object pattern in amf)

hello
i'am using amf to connect my flex application to the php back end,but i want to use DTO(DataTransferObject), i haven't enough info about this pattern.
can you introduce me a reference or have you any suggestion?
thanks for your attention
Uniqe_max (amin shahnazary)

here is another way of doing it
http://www.youtube.com/watch?v=1n1uHQAP18Q
http://www.youtube.com/watch?v=fQsCBk9tvkQ

How to combine Session Facade and Transfer object?

Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
Thank you!
Astghik

Astghik wrote:
Hello All!
I'm working on an enterprise application. Presentation layer is a stand alone client, business logic is build on the Glassfish v2.1 and MySQL is used as a database. The client is connection to the GlassFishj server remotely using EJBs.
I have problems with business logic architecture.
Here is the brief description of backend application architecture design:
1. Session Facade pattern is used to simplify the client and application server interface and to provide application layers between backend (http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html).
I would simply recommend establishing a service tier. Your services should be stateless. You can go the extra mile and have a session facade, but in the majority of cases, coding to an interface for your service accomplishes the same goals.
2.Transfer Object pattern to define update transfer objects strategy in order to decrease network overhead during client and application server interactions and to provide version control for objects. Transfer objects are designed as simple java business serializable objects. (http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html)
The idea of the transfer object is very similar to the Command pattern. I think if you investigate that pattern, it will be more obvious. The transfer object reduces network latency by consolidating all the parameters into an object, ideally, this also consolidates multiple method calls. If you combine a transfer object (or command object) with a service tier, you get the best of both worlds. The service can delegate calls to helper objects (or other services or components) using the data in the transfer / command object.
3. Originally the backend application consisted of three modules: users, storage and orders, but at the end I have decided to divide my application into the following parts - assortments, map, menu, orders, transactions, users.
The is your domain. It will vary from application to application. The principles above are more general (e.g., patterns and architectural tiers) and should apply to most domains. However, your actual use case may require something different.
4. All MySQL database transactions are via JDBC using procedures. No use of entity beans.
Consider using something like iBatis or Spring's JDBC templating to make your life easier with JDBC.
Questions:
1. I have some doubts about using Session Facade and Transfer object patterns at the same time. At first I'd mike to cite the definitions of the patters from the SUN official web site.
* Use a session bean as a facade to encapsulate the complexity of interactions between the business objects participating in a workflow. The Session Facade manages the business objects, and provides a uniform coarse-grained service access layer to clients.
* Use a Transfer Object to encapsulate the business data. A single method call is used to send and retrieve the Transfer Object. When the client requests the enterprise bean for the business data, the enterprise bean can construct the Transfer Object, populate it with its attribute values, and pass it by value to the client.
* So, if I use Transfer Object along with Session Facade, it makes some difficulties with object version control, because I 2 or
3 transfer objects controls with the 1 bean class. The best option for Transfer object Pattern is that each transfer object should have its own bean class to provide ability of object's version control. In the case it can bring the network overhead because of frequent remote calls caused by the large number of the bean classes.
* So, should I use the both patterns? If yes, how to manage the interaction the patterns. If no, which one to use.
Versioning is a separate issue. Generally, the more coarsely grained your transfer / command object is, the more changes are likely to impact dependent objects.
Your command or transfer object does not have to be a vanilla JavaBean, where you are basically creating a bean that has data from other objects. You can simply use your command / transfer object to encapsulate already existing domain objects. I see no need to map to a JavaBean with what you have described.
Generally, a method signature should be understandable. This means that many times it is better to pass the method, say, two coarsely grained objects than a signature with a dozen primitives. There are no hard and fast rules here. If you find a method signature getting large, consider a transfer / command object. If you want one service to delegate calls to a number of other services, you can also create a transfer / command object to furnish the controlling service with the data it needs to invoke the dependent services.
2. E.g. I have a huge list of the Order objects and each Order object consists of other complicated objects. So, would I have trouble to transfer that list over network? If yes, how to manage it.
This is a large, open-ended question. If you are going to display it to a user on a screen, I do not see how you avoid a network transfer with the data. The general answer is to not pass the data itself but rather a token (such as a primary key, or a primary key and a start and stop range such as you see on a Google search result). You do want to limit the data over the network, but this comes at a cost. Usually, the database will receive additional load. Once that becomes unacceptable, you might start putting things into session. Then you worry about memory concerns, etc. There is no silver bullet to the problem. It depends on what issues you are trying to address and what trade-offs are acceptable in your environment.
Thank you!
AstghikBest of luck.
- Saish

Where to put logic with Transfer Objects?

I'm playing with Transfer Objects for the first time, and have got this one class I'm not sure how to design the Transfer Object for. The problem is that I have some logic that is needed by both the domain model and by the client.
The class is named Moment. It's basically a wrapper around the java.util.Calendar class because I don't like passing objects of that type around in my code. That Calendar class is just to complicated to expose everywhere.
So, an easy example is that internally, Moment stores time in millitary time. I need a method that will take an hour, a minute, and AM or PM and convert it to millitary time for storing internally in the Moment.
Before Transfer Objects, this was easy enough of a decision. Moment had several factory methods called makeMoment. One of these took three arguments: hour, minute, and AM or PM. And, it internally converted to millitary time and stored the time in the Moment. However, now that the client is operating on Transfer Objects and not Domain Objects, if I put that method on Moment in the domain model, it won't be available to the client. If the client takes user input in AM/PM format from the user, it would have to duplicate logic already implemented in the model.
Options I think I have:
1.) Put the conversion method in MomentTO, maybe make it static. Then, my Moment class calls this method on MomentTO to do the coversion. This would work, but it seems funny to have the domain model calling business logic inside the Transfer objects.
A variation of this solution is just whenever my domain model wants to create a Moment, have it first create a MomentTO via a factory method that could do the coversion, and pass the MomentTO to a Moment constructor. This seems even funnier though to have the domain model creating Transfer Objects for internal use. It just seems to me that the point of Transfer Objects is to export information about the domain model to the client, leaving a lot of the specifics behind. Not something that the domain model uses for processing internally.
I could put the conversion method on the MomentTO and just say anybody who wants to create a Moment using anything but millitary time is going to come from the client that will be using Transfer Objects. Nobody else will be creating moments using anything but straight millitary time. But, this approach seems inflexible.
2.) Make a separate library / package that is available to both the domain model and the client. The inital reason I don't like this solution include the fact that I don't need much more other logic to be shared like this, so this package would be really, really small.
Any suggestions? Just can't seem to find something that makes good sense. I do have several other things like this for this Moment class in creating a Transfer Object for it. But, it is just this one class that I'm having this problem with.

>>
If this is for the pursuit of knowledge, then thatis
all well and good. However, if you actually wantto
do something with this application, I wouldrecommend
the following link:
http://xp.c2.com/YouArentGonnaNeedIt.html
- SaishI think you missed the part in the thread where I'm
not seeing the evil of Transfer Objects. Please
explain. They really don't seem that much work to
develop to me.
Fair enough. However, my point is that any time you develop something that 'might' be needed is time you are taking away from time developing things that 'are' needed.
One of the listed advantages of the Transfer Object
pattern in the Core J2EE Patterns is hiding
complexities of the domain model from the client.
This seems to be very handy for my application.The session facade pattern would accomplish the same effect.
. Many of the domain model objects are versioned,
but the first three iterations of development that I
want to complete before deployment need to know
nothing about the versions. With transfer objects,
this can all be safely hidden in the Application
Service objects.
I fail to see how transfer objects themselves would not require versioning or modification. Given a large enough transfer in the domain model, it woud be difficult to insulate an associated transfer object. Granted, these changes may occur less frequently.
Plus, I'm trying to figure out how the hell Commons
Validator works with Spring. Really wish I could
find a getting started guide. What I've found so far
makes it look like it's going to be easier to
validate Transfer objects than my domain model
objects, because all the validated fields will be on
one object. Not mostly on one object with some
fields scattered about like they would be with domain
model objects...I've found good FAQ and HOW-TO documentation at Jakarta while working on several Commons projects, including Log4J and FileUpload. Validator has no such online documentation?
For Spring, I recommend the new Johnson "J2EE Development with Spring" and (I forget the author) "Spring in Action".
- Saish

Flex design pattern for BlazeDS transfer objects

Dear Community,
I have a question regarding the nature of objects transferd from BlazeDS backend to the Flex client.
According to some adobe docs all the presentation logic should be in flex and BlazeDS should provide only services.
The question is what kind of transfer objects should be used? with what level of abstraction?
To make it more clear let's talk about a simple forum application like adobe forums.
I have created a Forum service, which returns a Forum transfer object, which has a List of Threads, with each thread having a List of Messages.
Flex gets the Forum transfer object and does all the presentaiton work.
This is a very nice seperatin of concerns architecture BUT there are two major performance issues:
- when the forum becomes bigger the transfer object will be huge
- the flex will use huge client resources to create the presentation of the forum transfer object.
So my question is what is your strategy/ design pattern for such a problem.
An obvious answer would be create services that include the presentation logic and use transfor objects like ThreadListPage which will include only the first 10 threads.
Thanks in advance

I think you are going to get a few varied types of answers to a general question like this, but I will comment on a few things. First, you should only be transmitting the data that you need to use or display to the user at the time. If this forum was implemented in Flex (I wish) you wouldn't transfer the text for all the threads. You might not transfer the thread text at all (just the subjects), you'd make calls back to the server to fetch that data when and if you need it.
Also, I think you are overestimating the resources required for the Flex "presentation layer". If you think about it, these workstations we have here are pretty idle most of the time when you're at a website. Nowadays there's plenty of processing power just sitting there waiting, so as long as your design isn't flawed the CPU or memory are rarely going to be a bottleneck with Flex.
The way I design, BlazeDS (or GraniteDS etc) should mostly just be "serving data". There is some flexibility available, for example I don't see a problem with putting certain types of business rules (such as a limit on the number of results that can be recieved in a search) within server side code, and validation rules on the Flex side. So there's not too many "industry standards" in Flex yet beyond maybe what's done in the various standard architectures, at least not that I'm aware of.
You might find it beneficial to look into some of the various frameworks/architectures available like Cairngorm, Mate, Swiz, and so on. Learning how they work (looking at examples) would probably answer some of your questions too.

Questions on scripts, tables & transfer objects between clients.

1. In script, how to use the same print program for two different layouts? with procedure.!
2. Why cant sapscripts be client independent.?
3. Want to maintain a table in dev server and if i update the data, it should simultanously update in Quality and Production servers. How? please explain in details.
4. How to transfer object between clients.? explain.
Points will be promptly rewarded for HELPFULL answers.!

Hi!
3. With SE01, you can create a transport request for all table entries.
SE01 - Create button - Workbench request - Give description and save
Select the created request and click on Display object list.
Click on Display - Change button
Insert line button
ProgID: R3TR
Object: TABU
Object name: Z_YOUR_TABLE
Double click on the table name
Insert line
Key: *
Save everything
Release the transport in SE10 transaction and transport with STMS transaction.
Regards
Tamá

Simple Question - Data Transfer Object

Hey gurus,
I like the option in JBuilder to automatically create Data Transfer Objects and an Assembler for it. But what? I used to make the assembler a Session Bean, and JBuilder makes it a normal Java class with static methods. I know JBuilder always ships with the best solutions, but...
what is the advantage of the static class here? And in my case, i have the session beans and the entity beans deployed on a different server, would that make a difference for the advantage?
greets,
Nick.

Hey gurus,
I like the option in JBuilder to automatically create
Data Transfer Objects and an Assembler for it. But
what? I used to make the assembler a Session Bean,
and JBuilder makes it a normal Java class with static
methods. I know JBuilder always ships with the best
solutions, but...
well....... not always
:-)

Transfer Object in JSF, Spring, and Hibernate

The application on which I am working deploys the JavaServer Faces, Spring and Hibernate frameworks.
We are going to use the "transfer object" to move data between J2EE tiers from the front end to the back end and vice versa. In addition, data "types" may need to be converted --
At the front end, the "type" of the data that are entered by users may not match that in the database table. For example, checkboxes may be marked or left blank by users. The "type" of the checkboxes is "boolean" in the JSF backing bean. However, we have either "Y" or "N" for the corresponding field in the database table.
The JSF backing bean holds data as well as controller functionality. Of course, the transfer object holds data only.
With regard to class properties, Is the transfer object an exact copy of the JSF backing bean? And at which tier the data are converted to match their correspoding "types" in the database tables?
We also have the "data objects" which are exact representation of database tables.
Thanks for your advices.

Small example: you can decide in the business layer
whether to convert it to boolean or Boolean (which
has a 3rd state: null).But it all goes back to your data model. If your data model supports null for that property, then of course boolean is a poor choice. If that case one could use Boolean. None of this has anything to do with re-usability, which was your objection.
I think the re-usability question goes back to the data model as well. Suppose your data model says this property is boolean valued. However if your database does not support booleans natively, then you need to map the value for storage in the database. But that is the data persistence layers problem.
OTOH, suppose your data model says that this property may be 'Y' or 'N'. Then the Java class represent the business object should not have a boolean property, we should make it match the data model.
However, I think that most cases where people are storing 'Y' or 'N' in a field in the database fall into the first case, where the data model is a boolean and they are working around limitations in the database. There is no reason in that case to perpetuate the same limitations in the Java code.

Transfer Objects in EJB 3.0

Hello,
I am building Enterprise application with EJB 3.0 and JSF. In many J2EE books there's that Trasfer Object pattern ( sometimes called Value Object or so), I just wonder what are your experiences in using TO in Java EE ( EJB 3.0).
Because entity beans in EJB 3.0 are POJOs I think that there is no need to
use TO pattern.
Im my app I receive entity from session bean and bind that entity to JSF components. This is the easisest solution for me because I don't build boring
transfer object, and don't have to wory about transformation between TO and Entity beans. Am I doing right or I am maybe missing something??
By reading EJB 3.0 spec. when session bean returns entity it becomes
detached so its just plain java object. ??
I know that using TO you can reduce coupling between client and EJB but
you must implement additional level with TO objects and transformations, so
it looks to me that by using TO you just get more complexity and problems ?
Tell me what are your thoughts and experiences.
Regards,
Niksa Jakovljevic
FOS

Hi Niksa,
Your intuition about EJB 3.0 is correct. One of the advantages of Java Persistence API entities
is that they can be passed directly to clients without having to convert their data to separate transfer
objects. The reason this was a common pattern in EJB 2.x and earlier is that CMP 2.x beans are 1st
class EJB components that are limited in their ability to be used outside of the ejb tier.
--ken

Business Objects(BOs) & Data Transfer Objects(DTOs)-both needed ?

In a J2EE system...
I know that "Business Objects" (BOs) are basically value objects (VOs) ...lots of getters and setters and some business logic. These are basically to model nouns in the system. Eg Student BO.
I know that "Data Transfer Objects" (DTOs) are value objects (VOs)....with getters and setters... with the purpose of avoiding multiple method calls...to avoid overhead...which effects performance. eg it's better to pass a Student DTO then say...pass the student ID and student name and student age etc etc.
Main question : Should a system have both ? If yes, why do I need a StudentBO.java and then another StudentDTO.java....when they are so similar ?...when both are basically VOs ? Can't I just use BOs to serve as DTOs ?
Thanks.

Hi,
I've started using BO's and DTO's since 3 months .With my experiece i understand we nned both of them.
The BusinessObject represents the data client. It is the object that requires access to the data source to obtain and store data.
DTO
This represents a Transfer Object used as a data carrier. The DataAccessObject may use a Transfer Object to return data to the client. The DataAccessObject may also receive the data from the client in a Transfer Object to update the data in the data source.
From this i want to tell you that We are not gonna do any operation on BO's but we do operations on DTO
Ashwin

Value Object Pattern - Does EJB 2.0 Deprecate?

In the EJB 1.1 specification, there were no such things as Local Interfaces and Local Home Interfaces. In the Core J2EE Patterns book, they cite the main reason for using the Value Object Pattern as being a way to avoid much of the network overhead associated with using EJB; any call to an EJB potentially involves a remote call to the object even if it lives in the same JVM. But with EJB 2.0 you can have a Local Interface which seems to eliminate all this network overhead already.
Anyone care to register an opinion on whether or not there are still valid reasons for implementing the Value Object Pattern when using EJB 2.0?
Any input would be greatly appreciated!

Yes - the fact that it's generally a bad idea to "tie" stateful information (e.g. EntityBeans) to a stateless front-end.
In other words, it's better functionality to transfer "static" sets of data (Value Objects) in chunks from a business-layer (SLSBs, fronting the EntityBeans) than to have the front-end directly query the persistence tier. Also, using the Facade (and related) patterns as the go-between the view (front-end) layer and the persistence layer, you gain the flexibility of the persistence (and the business) layer changing without having to re-engineer the view at all.

Data Transfer Objects

Is it safe to assume that Data Transfer Objects should be populated by Business Objects that are local to entity beans or whatever is being used to populate them?

jschell wrote:
ttb999 wrote:
jschell wrote:
So if the point of DTOs is to reduce network traffic, why would you initially populate them using a remote object? That doesn't have anything to do with what I said.Well that was the jist of my question.Your statement has a historical perspective which probably doesn't mean much in current DTO usage.
Originally RMI was promoted as a a 'method' interface. As such you would have had the equivalent of a DTO with setter/getter for each attribute. Each setter/getter would invoke a remote procedure call to the server.
Thus a data object with 5 attributes would cause 5 network calls to 'populate' the attributes.
That was vastly inefficient.
Consequently the first DTO type (which was not called a DTO) was promoted as a way to avoid that.
If you want you can look up "Remote Procedure Call" (RPC) which would have been the origin of where the 'method' idiom originated.And quite apart from performance, populating a local object from the remote prevents disruption of the local data in case the network connection is (temporarilly) lost.

Value Object pattern implementation problem

Hi All!
I try to implement value object pattern in my bean as follows:
/* Simplified code */
public class Value implements Serializable {
private String s;
public setS(String value){
s = value
public getS(){return s}
bean class:
public class Bean extends Value implemets EntityBean {
public Value getValue(){return this}
Now question.
When I try run this code I get next message
org.omg.CORBA.MARSHAL: minor code: 0 completed: No
org.omg.CORBA.portable.InputStream com.visigenic.vbroker.orb.GiopStubDelegate.invoke(org.omg.CORBA.Object, org.omg.CORBA.portable.OutputStream, org.omg.CORBA.StringHolder, org.omg.CORBA.Context, org.omg.CORBA.ContextList)
org.omg.CORBA.portable.InputStream com.visigenic.vbroker.orb.GiopStubDelegate.invoke(org.omg.CORBA.Object, org.omg.CORBA.portable.OutputStream, org.omg.CORBA.StringHolder)
org.omg.CORBA.portable.InputStream com.inprise.vbroker.CORBA.portable.ObjectImpl._invoke(org.omg.CORBA.portable.OutputStream, org.omg.CORBA.StringHolder)
com.retailpro.cms.common.InventoryValue com.retailpro.cms.ejb._st_Inventory.getValue()
void com.retailpro.cms.inventory.SetInventory._jspService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
void oracle.jsp.runtime.HttpJsp.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
void oracle.jsp.app.JspApplication.dispatchRequest(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
void oracle.jsp.JspServlet.doDispatch(oracle.jsp.app.JspRequestContext)
void oracle.jsp.JspServlet.internalService(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
void oracle.jsp.JspServlet.service(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
void javax.servlet.http.HttpServlet.service(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
void oracle.lite.web.JupServlet.service(oracle.lite.web.JupRequest, oracle.lite.web.JupResponse)
void oracle.lite.web.MimeServletHandler.handle(oracle.lite.web.JupApplication, java.lang.String, int, oracle.lite.web.JupRequest, oracle.lite.web.JupResponse)
void oracle.lite.web.JupApplication.service(oracle.lite.web.JupRequest, oracle.lite.web.JupResponse)
void oracle.lite.web.JupHandler.handle(oracle.lite.web.JupRequest, oracle.lite.web.JupResponse)
void oracle.lite.web.HTTPServer.process(oracle.lite.web.JupRequest, oracle.lite.web.JupResponse)
boolean oracle.lite.web.HTTPServer.handleRequest(oracle.lite.web.JupInputStream, oracle.lite.web.JupOutputStream)
boolean oracle.lite.web.JupServer.handle(oracle.lite.web.JupInputStream, oracle.lite.web.JupOutputStream)
void oracle.lite.web.SocketListener.process(java.net.Socket)
void oracle.lite.web.SocketListener$ReqHandler.run()
Seems like object can't be serialized.
But when I change my getValue() to next
public Value getValue(){
Value result = new Value();
result.setS(s);
return result;
Everything goes fine!
Can anybody comments this situation?
Any information will be appreciated!
Mike
null

Have you tried using our Business Components for Java framework to assist in developing your EJB components. BC4J is a design pattern framework that implements the J2EE Blueprints design patterns out of the box:
[list][*]Session-Entity Fagade
[*]Paged-List
[*]Unified Data Access & Logic
[*]Value Object
[*]Model View Controller
[list]
and more...
So many things you don't have to code yourself when you use BC4J to turbocharge your development... Also, using BC4J insulates you from having to choose once and for all at the beginning of your project that you ARE USING EJB AT ALL COSTS on your project.
Many projects discover that they don't require a distributed objects configuration, but end up paying for it in architectural complexity and EJB's assumption that all beans might be located on remote VM's.
With BC4J, you can build an app, deploy to EJB if you need EJB for a given project, or deploy to CORBA, or just to simple Java classes for improved performance without the remoting overheads. All without touching your application code.
Pretty cool, I think. But of course, I'm biased :-)
Steve Muench
Lead Product Manager for BC4J and Lead XML Evangelist, Oracle Corp
Author, Building Oracle XML Applications

Bitmap pattern has seam ONLY when created with "Object → Pattern → Make"

I think I've encountered a bug with Adobe Illustrator CC 2014.
I'm trying to make a repeatable pattern out of a bitmap, which I downloaded from http://subtlepatterns.com
Most of the patterns I try, work correctly, but one in particular behaves strangely.
(This is the png in question: https://dl.dropboxusercontent.com/u/473648/pw_maze_black.png, Here is an example AI file that shows the problem: https://dl.dropboxusercontent.com/u/473648/Pattern%20Seam%20Example.ai)
When I create a pattern with the "Object → Pattern → Make" menu item and then apply it to a shape, I get hairline seams that appear in the pattern at various zoom levels. If I export the file with "Save for Web" to a PNG then the seam disappears, though if I use the plain "Export" feature to create a PNG the seams appear in the output file.
The strange thing is when I create a pattern from the above PNG by dragging it to the Pattern palette and use that pattern, the seams do not appear in any export files, or in the design window of AI.
Other patterns I've tried from subtlepatterns.com work correctly when created with the "Object → Pattern → Make" menu item.
Obviously I have a solution to this problem, but is there an explanation for the difference between creating the patterns with the two methods, or is it a bug?
Thanks,
Caleb Land

When dragging the pattern to the swatches panel works, just do it. You don't need the pattern editing mode for this one.

Transfer Object pattern question

Similar Messages

Maybe you are looking for