Ken Blair

You forgot a " at the beginning of your String.

Often stored as a cookie.

I highly encourage you to look at a framework such as Apache Shiro or Spring Security to manage authentication.

Lucky J Verma wrote:
Hi Mark ,
Thanks for help.
Can you please give me an example on how to send data to @RequestBody for <display:table> column?
Adding it in form and then i use Will it automatically go to @RequestBody and not @RequestParam
. And data is sent in string.
Also i tried sneding POST data -by adding hidden fields to display:column and no which is not working .Since variables contain duplicated comma separated values
and no hint of what value was user-selected.
Furthur research taught me ts limitation of sending POST values.

That's not what he's talking about.

A GET sends parameters in the request URL. A POST sends parameters in the body of the request. Because the length of a URL is restricted the length of the parameters is inherently limited. If you need to send a lot of data through a parameter, or even just a lot of parameters, you should prefer using POST as it's less likely to run into the length issues.

@RequestParam works for both. @RequestBody has nothing to do with it.

If you're getting a comma separated value it means that the parameter was included more than once. Look at your form and request URL and ensure you haven't submitted the value in two different places at the same time. If you're expecting multiple values for a parameter then it should probably be a List.

public class UserController extends MultiActionController { public ModelAndView usersList(HttpServletRequest request,HttpServletResponse response) throws Exception { Map<String, Object> model = new HashMap<String, Object>(); EmpDaoImpl empDao = new EmpDaoImpl(); model.put("empList",empDao.listEmp()); return new ModelAndView("usersList", model); } }

Right, there's your problem. You used "new EmpDaoImpl()" so the object you've created is not managed by Spring. You never called setSessionFactory() and so SessionFactory is of course null, hence an NPE when you try to dereference it.

You probably want to be getting an EmpDao managed by the Spring container which means you need to inject it somehow in the controller. For example you could create a field in your controller and then setup a constructor or setter to inject it.

For example this is a very common pattern in the controllers we write:

@Controller public class ControllerA { private final EmployerService employerService; @Autowired public ControllerA(final EmployerService employerService) { this.employerService = employerService; } @RequestMapping("/findEmployer") public String findEmployer(final @RequestParam String employerId, final Model model) { model.setEmployer(employerService.findEmployer(employerId)); return "/employer/findEmployer"; } }

When the controller is constructed an EmployerService will be injected by Spring. In other words the EmployerService bean will be managed by Spring, so any injection we've setup in EmployerService will be taken care of as well.

index.html is probably the default page defined outside of Spring MVC. The model is provided by Spring. You add attributes to it, for example it appears the JSP you have open is expecting a "titre" attribute to be set on the model.

Read this if you haven't already.

http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/mvc.html

Your teacher couldn't get a job doing what they're teaching. That's awful.

My mistake.

You said the field was encoded in 8859-1

Yes. The field is a char(16) and the encoding is 8859-1.

The bytes are all valid 8859-1 characters.

8859-1 doesn't cover all 256 possible values does it? Aren't quite a few ranges "unused"?

*You* were the one that was talking about encoding the raw bytes and using toString, not me.

Yes, I'm thinking on paper. toString() is unsuitable because the length is too long because it's hex. I don't see anything in the UUID class that will give me a String or otherwise encode the bytes into something 16 characters in length. Hence I would have to do it myself. I don't see how that's possible with 8859-1 because of the above concerns.

You never said anything about needing a printable representation--not sure how I would be expected to guess that.

It didn't occur to me until I was typing that. So realistically, there's no way to get a UUID into a 16 character string or am I missing something?

In any case, good luck.

Thanks.

David Newton wrote:Those *are* the encoded raw bytes. Why can't you just write the UUID, which is 0-255 (which is what ISO-8859-1 defines)?

What happens when you write "c46f6ae1-7b2e-4baa-8df8-05fbdd91c075" into a 16 character field? You can't. Every single one of those character is going to get encoded into ISO-8859-1, one byte each, it's more than double the length of the field.

Furthermore, what happens when I grab the raw 16 bytes and encode each byte into ISO-8859-1 as 1 character per byte, as opposed to hexadecimal which requires two characters per byte, and the byte happens to be 7F? I'm betting the DB is going to puke at me and even if it doesn't I'm not sure what will happen when it gets to some place like SF and a salesperson is trying to copy & paste an ID with a control character in it.

David Newton wrote:Oh, I see. What does that have to do with encoding the raw bytes?

It's char(16).

UUID.toString() is hexadecimal. 32 characters not including the separators.

David Newton wrote:ISO-8859-1 is 0-255; unless you meant something different by encoding.

I only have sixteen bytes to work with

I misread the UUID docs as being 128 bytes.

David Newton wrote:How could there be a lot of collisions with 16 bytes of 0-255? That's a really big quantity of possibilities, like 3x10E38 or something ridiculous like that.

You're assuming it's random. It's not even close, the code is really bad.

David Newton wrote:And how does ISO-8859-1 preclude the built-in UUID?

It was the size not the encoding I was referring to. Looks like I misread the UUID documentation. I can use UUID but only if I encode the raw bytes myself.

Do you want to crop or scale? They're not the same thing. How are you acquiring the image, any guarantee it's in a compatible format for the system? That can have a HUGE impact on the performance of things like drawImage.

I have a site with a cluster of web servers. Previous developers have these web servers generating a UID that is used for the primary keys of nearly every table in the database. The code for it is atrocious, collisions are common and will only get worse as time goes on. I need to replace it.

Here's the catch: I only have sixteen bytes to work with, encoded as ISO-8859-1. Note that this catch kills UUID or even java.rmi.server.UID dead in it's tracks. There's no space for it. Changing the size is not an option.

Here's the good news: it doesn't need to be a UUID or global at all, it doesn't need to be particularly efficient, it can be presumed to be called at most a few hundred times a second per server, all servers have, and always will have, an IP that is unique amongst those servers, and finally the lifetime is short (less than a decade), server time will never move backwards.

Here's what I came up with at first blush, keeping the above in mind.
public class Foo { private final FooUIDGenerator uidGenerator; public Foo() throws UnknownHostException { uidGenerator = new FooUIDGenerator(Integer.toHexString(ByteBuffer.wrap(InetAddress.getLocalHost().getAddress()).getInt())); } public String makeUniqueId() { return uidGenerator.getUID().toUpperCase(); } } public class FooUIDGenerator { private final String host; private long suffix; public FooUIDGenerator(final String host) { this.host = host; } public synchronized String getUID() { return host + Long.toString(suffix++, 36); } }

Any holes (you see in the example) or suggestions are welcomed.

I don't know if there's an easy way to do it with the tools provided by the JDK but I don't think it'd be particularly difficult to write one in Java. Take a look at java.util.jar.JarFile which has a getManifest() method that will read and return the Manifest for a JAR file which you can in turn read Attributes from. Though I haven't done it I imagine it's rather trivial to grab what you're interested in and compile a file.

Of course, you'd have to actually find the JAR files to begin with. Though you should be able to specify a directory and recursively check each directory for any JAR files. I have no idea how long this would take.