Jason Ferguson

Greenhorn
+ Follow
since Jul 17, 2007
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 Jason Ferguson

I'm not intending to depend on "security through obscurity". At best, removing debugging symbols may just stop a few undereducated script kiddies. However, I maintain that security through obscurity is valid IF IT IS A SINGLE COMPONENT OF AN OVERALL SECURITY PLAN. If only 20% of potential attackers are script kiddies, then I've just decreased vulnerability by 20% by making it slightly harder for them.
11 years ago
My concern with the debugging symbols isn't primarily performance, it's security. I don't WANT the "bad guys" seeing traceback information. But I also want to exclude all junit-related jars (and test classes) off of the live server.
11 years ago
I think I've been missing the point with Maven Build Profiles and need help.

I'd like at least two separate maven build profiles, say "dev" and "live":

1. Dev would contain dependencies such as JUnit, etc.
2. Live would NOT contain JUnit, would not contain the Unit Tests, and would compile without debugging symbols.

Right now, all of my dependencies are in the overall <dependencies> section.

Questions:
1. Since all of my dependencies are not currently assigned to a specific profile, does that mean by creating the Dev profile and adding the dependencies to it, they would be added to the WAR as long as I specify a build with the Dev profile (i.e. inheriting the rest)?
2. How can I specify in the Live profile to compile without debugging symbols?

Thanks!

Jason
11 years ago
I'm looking for a Better Way (tm) than a method I'm using.

This algorithm is in a Hibernate ResultTransformer implementation, but I don't think this question is Hibernate specific so I'm asking it here.

The query is for an Organization, with some basic fields such as id, name, etc. However, the Organization also contains a Collection of child Organizations, which seriously impacts performance when building the hierarchy recursively (especially considering Hibernate many-to-one/one-to-many relationships with Organization).

In order to improve performance, I implemented the Nested Set model, where each item has a "left" and "right" value. To get all of the children of an organization, I simply query for results between its own left and right values.

However, I'm thinking the method I'm using to rebuild the hierarchy could stand improvement, and am open to suggestions.

Upon the initial return of the query results, I store everything in a Map<String, Object>. This is converted to a List<Map><String, Object>> by Hibernate.

I then create two more maps:
Map<Organization, Integer> childParentMap - maps the organization to the id of its parent.
Map<Integer, Organzation> organizationIdToObjectMap - maps the unique id of the object to the object.

Using these two maps, I can get the id of the parent from the childParentMap, then turn around and get the parent object itself from the organizationIdToObjectMap. Unfortunately, this requires an initial pass through the List<Map><String, Object>> to build the organizationIdToObjectMap and the childParentMap, then a second pass through the organizationIdToObjectMap to build the hierarchy.

The code involved is below.



My gut feeling is that there has to be a more efficient way to do this. Any ideas?

Jason
11 years ago

Jeanne Boyarsky wrote:Jason,
Don't you need to call manufacturerDao.flush() to force the delete to get to the database?

I'm going to move this to the Hibernate question since a Hibernate expert is going to be more help here than a testing one.



One word response: D'OH!

The idjits who originally wrote the DAO didn't put a flush method into their generic DAO, and I wasn't thinking about it.
First, I'm using a Spring 2.5/Hibernate 3.3.2 combination with the JUnit annotations.

I'm trying to unit test a DAO's delete method. Here is the code:



The second call to manufacturer.loadById(311) should obviously throw an exception but doesn't. I'm obviously being stupid here about the way transactions work, can anyone help me?
I need help.

I have a class, Region. Region has a Collection of Organizations belonging to it (i.e. an Organization exists in the Northeast, etc). It's defined as a bi-directional One-To-Many/Many-to-One:

Region.java:

@OneToMany(targetEntity = Organization.class, mappedBy = "region", fetch = FetchType.LAZY)
@NotFound(action = NotFoundAction.IGNORE)
@org.hibernate.annotations.Fetch(org.hibernate.annotations.FetchMode.SUBSELECT)
public Collection<Organization> getOrganizations() {
return organizations;
}

Organization.java:

@ManyToOne(targetEntity = Region.class, fetch = FetchType.LAZY)
@JoinColumn(name = "REGION_ID")
public Region getRegion() {
return region;
}

The Organization also has a child Collection of subordinate organizations, meaning that even though there may only be 8 Regions, Organizations are slow to initialize due to the recursive nature of the initialization. UNFORTUNATELY, since a region is geographic, an Organization's parent organization may not be in the same region as itself or its siblings. So, Region's Collection of Organizations does a ton of extra work initializing the organizations (because they initialize children, etc). But every organization is in the collection as a separate member, even if its parent is too. Still with me?

Unfortunately, I need the Organization's id field (an int) and name (a String), which triggers the initialization. (You should see how insane the console goes with Show SQL turned on).

Does anyone have any ideas for tuning this particular issue?

Jason




(Okay, value object, transfer object, model object, whatever you want to call them: basically an object that represents a "thing").

The "standard" way of developing a POJO follows the JavaBean spec:

- Data memembers
- Mutators (getters and setters)
- Empty Constructor

Then you can override equals() and hashCode(), implement Comparable, and all sorts of other fun things. One of these is to override toString() from Object to spit out some sort of String representation of the object. If it's not overriden, then toString() just spits out some default information about the Object.

Now, in the past, I've done things like create an interface called HashableEntity with a single method to export the data as a HashMap (trust me, it made sense at the time...), or other representations.

Now I find myself wanting to create an interface called something like SoapEntity, with a single method called toSoapMessage() (obviously returning an object of type SOAPMessage). Now, this is a bit more heavyweight than my previous examples, requiring the import of all sorts of stuff from the javax.xml.soap package.

The other option is a Utility class or Service class method to take the POJO and return a SOAPMessage.

(I suppose one other option would be a Decorator for the POJO, as well).

What would be the arguments for or against having the logic in the POJO (other than the overhead I mentioned previously)? I feel that putting the logic into the POJO would be okay, as we're not operating on the data, just representing it differently when asked.

Jason
[ November 18, 2008: Message edited by: Jason Ferguson ]
12 years ago
Background: I have developed a GUI client (launched via JNLP) that performs a function, gathers some data as Strings, then generates a SOAP message to a Web Service. That part is (mostly, excluding the JNLP) done.

However, I want to implement an extra layer of security by encrypting the data (the Strings) prior to generating the SOAP message (protection from network sniffing). However, I'm not sure how to proceed in implementing an encryption scheme.

It seems the simplest way is a simple symmetric encryption. However, I don't want to hard-code a key into the GUI or the server since changing it would require a rebuild and redeploy of both the client and server.

Any ideas? (Obviously, I'm kind of a newbie here)
12 years ago