Win a copy of liveProject: Protecting User Data with Spring Security and OAuth2 this week in the Spring forum!

Chris Nappin

Ranch Hand
+ Follow
since Aug 04, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chris Nappin

Yes, the private key has to be read every time for two reasons:

1. The electronic signature proves that a particular officer must have been present at the time.

2. The private key must never leave the hardware token.
14 years ago
I have a requirement to add digital signature functionality to a J2EE web application. Our customers would like to press a �sign� button on a web page, be prompted to connect their hardware security token (e.g. USB device or smart card), and the signatures stored inside our system for later verification (e.g. in court).

The main issue I can see is that when using hardware-based tokens the private key can never leave the device, so the device itself does the signing. Whereas our J2EE Web Application has all the code on the app server tier, and the data is located on the database (and in our architecture cannot be exported to client PCs for security reasons).

Does anyone know of any solutions to this kind of requirement? Any vendor toolkits that allow this? From what I�ve read from researching this subject the pieces are all there but most web-based security solutions only implement application login authentication of one sort or another.
14 years ago
Looking at the definition of various Java EE and Spring Annotations, I've come to the opinion that there is no meaningful @Target for a nested Annotation - seems to be a gap in the Java language?

If anyone knows otherwise please let me know!
14 years ago
I'm pretty new to Java 5, and am defining some annotations to be used as follows:

@BaseProperty(name="formView", value="createPerson"),
@BaseProperty(name="successView", value="createSucceeded")
public class ExampleFormController extends SimpleFormController {

I know I can set the @Target of @BaseProperties to be ElementType.TYPE, but how can I define a suitable @Target of @BaseProperty - so it can only be used within the outer annotation?

I couldn't see a suitable value in ElementType?
14 years ago
I would like to be able to get a list of all classes that can be loaded by the current class loader, so that I can then inspect them looking for specific annotations - like a Java EE 5 container does, but all the code would be sitting inside an application, not in the container. Is this possible in a reliable, portable manner in a J2EE container environment? I imagine hacks to locate physical .jar/.ear/.war files won't work accross containers, when some expand them and others don't?

Does anyone know if any of the AOP or byte-code manipulation libraries (cglib, BCEL, ASM etc) have APIs that might help here?
14 years ago

Originally posted by Palash Sahu:

Thanks a ton for your reply.
Actualy scenario is number of message processors will be invoked by Message Driven POJO(MDP), a spring's solution.

I'm familiar with Spring but not with it's Messaging integration, however you can certainly define whether Spring beans are singletons or not via the "singleton" bean attribute in the application context XML file.

Obviously a singleton solution will need to be a stateless class to avoid threading issues.

You can also get Spring to use static or instance factory methods (instead of constructors) so if you do have to go with your own pool management then your Factory method could hide that fact from the Spring dispatcher?

Originally posted by Stan James:
Can you move the code specific to each subtype into the subtype behind a common method?

I think that would be identical to the previous suggestion?

Originally posted by Stan James:

Or put the code specific to each subtype into its own Strategy?

Stategy is a nice pattern I'd consider if the amount of code involved was non-trivial. However if we are only talking about half a dozen lines of code in class B, then creating extra factories, interfaces and implementations would be a massive overkill?

Originally posted by Peer Reynders:

This is an indication that your abstraction/interface on A needs some work. In the simplest (but not the best) case you could just promote the B method to the A level and have C do nothing when that method is called. However it is more likely that you need to have a good look at the code that uses instanceof. Some of that code may need to go inside of A as a new suitably named method that makes sense for most, if not all subclasses of A. Then inside of that method, call template methods that the subclass can override - in which case B would put its code there, while C ignores it.

Thanks for the suggestion. Unfortunately you are saying to move a method unique to B into A, then add a default implementation of that method to A. That default implementation would have to do nothing, since that functionality makes no sense in the other subclasses (e.g. C). I think this may cause more confusion for Junior developers, and bloat A with unrelated concepts?

I have seen other solutions where Enums or ids are defined for each class (B, C) and code checks that instead of using "instanceof", however that seems to be treating the symptom rather than the cause.
Can you elaborate on your requirements?

Do you have to consider threading? Does the pool need to be dynamic?

If threading is not an issue then the best way to minimise memory use is to use the singleton pattern. However whatever solution you decide to use can be hidden behind a factory method so you can change it in the future if needed.
I run FindBugs on our project code, and one of the warnings I noticed recently was that I am using "instanceof" quite a lot, instead of nice general polymorphic methods.

This leads me to a question - am I structuring my code wrongly or not?

Lets say I have a hierarchy of classes, A, B and C. Not very imaginative, I know.

Any common code can be extracted into A, then inherited into B and C, nice and simple.

Any common behavior (but with different implementations) can be declared as an abstract method in A, implemented in B and C, then called via Polymorphic dispatch. Again, nice and simple.

However suppose I have some behavior in B that is completely unique to B, and would make no sense to exist in C. Then I have a piece of generic code that knows about the whole hierarchy of classes. How can I know whether to trigger some behavior in instances of B, other than using instanceof, then casting and calling the method(s) only present in B?

javax.xml.SoapElement is used by Web Services development tools when the XML Schema types in the WSDL is too complex for it to handle. If at all possible, I suggest you move to a newer version of WebLogic (e.g. 9.2) or even better still move to Java EE 5 and JAX-WS which has full support for all XML Schema types. Then your method signature should use JavaBeans, which is much simpler than manipulating XML.
14 years ago
Looking at the stack trace it seems unlikely that your error is caused by the WSDL, it looks more like something more fundamental has gone wrong.

I can't see anything obviously wrong with your WSDL, except that minOccurs="1" is the default for a sequence so you don't have to explicitly state it, although that isn't going to cause any problems.
14 years ago
When debugging Web Services, I use the fantastic "tcpmon" tool that comes with Apache Axis. Use this to redirect your SOAP call, then at least you will know whether the fault is at the client or server end. Then at least you have a starting point...
14 years ago
Thanks to Peer for your recent reply to my attempt to re-open this discussion, and for your previous lengthy reply which I didn't see at the time.

As for JSE 6, I'm afraid we need to develop this product now, not in a couple of years time! We're only just looking into the possibility of moving to JSE 5.

Your previous lengthy reply suggests that the world of Java Web Services is a lot less mature than I had hoped. Implementing my own Web Services stack is not a realistic option for us, neither is embedding a standard implementation (e.g. Axis, XFire etc) because of Application Server classpath clashes. The lack of replies from anyone else that has managed to achieve this makes me think I'm breaking new ground, which I'm sure I'm not?

> So if in fact you do actually need a web service component that is
> deployable on all J2EE servers, that has one unified Java interface,
> then you will need to find one tool that generates output that can be
> accommodated by all the application servers

That's why I am using Sun JWSDP. In "interface-only" mode, it generates Java code that only depends on the JAX-RPC 1.1 classes, so is completely portable (at least that's the theory!).

As I haven't been able to find a solution to the WebLogic-specific issue of supporting "unwrapped" services, I've reverted back to using JWSDP in "wrapped" mode. This approach is portable accross JBoss 4.0.4 (with JBossWS), BEA WebLogic 9.2 and Sun App Server 9. I'm currently trying to resolve an issue with Oracle on 10gAS.

Once I get all this working, if this really is breaking new ground, perhaps I should publish an article with the details?
[ October 26, 2006: Message edited by: Chris Nappin ]
14 years ago
(A re-phrasing of my recent posting that will hopefully facilitate a few more comments this time!)

I need to build and package a portable J2EE application that includes web services (both clients and services). I would like to be able to create a single .ear file that can be deployed on any of the major Application Server platforms (WebLogic, WebSphere, JBoss, Oracle, Sun).

Has anyone out there achieved this, and if so what high level approach was used?
14 years ago