[Design of JBoss Web Services] - Re: Stack independent addressing implementation
by adinn
anonymous wrote :
| First of all we need to keep in mind basic J2EE principle here Write once run everywhere. Thus proprietary api is always wrong approach from this point of view.
|
Well, I really want my WSTX implementation to be container-independent and the hope was that JaxWS would provide that independence in the transport layer. However, I have no choice but to use the WSA management API which lies outside the spec -- the WS-* transaction specs requires manipulation of addressing properties. In the absence of any definition from the specs I still need some API to code to and it it would be better if we could provide just one API.
If I were to build myself some facade classes to wrap around the CXF and JBoss WSA implementations of the WSA types I think I would still need to deploy stack-specific code at the interface to the stack (i.e. when I create addressing property values and when I install them or test for them on the client/server side of a connection). So, my code will end up being dual-image and deployment of my code will depend upon the WS deployment. Following this route seems doubly inappropriate in that the AddressingProperties classes are already facades.
Is it possible to deploy the javax.xml.ws.* interfaces in the CXF WS release but configure them to use the CXF builder classes to populate them? In other words to use the implementation provided by the underlying stack but make it available via the same API as the native WS release. If we do choose an API it would be better if it were located in the javax package (although, strictly, we are not supposed to pollute this namespace with our own definitions).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208897#4208897
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208897
15 years, 8 months
[Design of JBoss Identity] - typed interface of identity api
by tom.baeyens@jboss.com
after integrating the identity api in jbpm, i have 2 remarks:
1) typed interfaces are nice in oo design, but i believe they are counterproductive in this api. before i can do a query that involves a user and a group, i have to fetch the identity-object and group-object from the api. only then i can supply those objects into the query method.
this means 3 api calls instead of just 1. probably this will lead to 3 times DB access instead of 1.
in the jbpm api, we take primitives (id's) as method parameters in our session facade apis. and we provide typed objects as the return value. in case you would have the typed object and need to invoke a method, then you can always supply the id by doing someObject.getId().
2) i believe there should be no difference between a role and an association. role should be just an optional property of an association. this would make the whole model and the related api managers a lot simpler.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208892#4208892
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208892
15 years, 8 months
[Design of JBoss Portal] - Re: Design of Portal Deployer
by alesj
"mwringe" wrote :
| Thats the way the current sar is setup, I can be converted to a -beans.xml in the future. Is there a big reason to switch?
|
JMX might not be there for 6.x. ;-)
Our beans IoC is far superior to our JMX IoC.
sar == jar in MC
"mwringe" wrote :
| Because the deployers are started before the deployables, so I can't inject something from a deployable into a deployer (correct me if I am wrong, but I have tried this)
| So I use the MC kernel to get a reference to the objects at runtime which gives me the same result.
|
It depends how you inject them. ;-)
After each phase deploy - boot, deployers, deploy - a MainDeployer::checkComplete is called,
to make sure everything is deployed as it should be.
But you can make your injections optional, injected via callback.
So it will be almost the same as you have now,
except that your code will be MC agnostic, hence more flexible.
Think POJO. ;-)
"mwringe" wrote :
| So the common metadata driven approach is the best?
|
Best is relative term. ;-)
But I guess it's good, see our previous 4.x deployers vs. new VDF.
"mwringe" wrote :
| No, and there are other deployers which need to do similar things (sometimes even worst than the tld deployers). I know its not the best way of doing it, but it works. It something that will need to be looked into more and fixed (if possible).
What about if we did this on our own?
As it looks like we'll have to wait forever for Remy. :-)
Or get ThomasH to ping/push the new JBossAS bosses about this issue,
as it's crucial for you guys.
I think all we need is a VDF based DirContext + investigate how this affects .tld lookup.
There already is a VFS based one, but it's not used due to some legacy Servlet api crap.
Perhaps we could make this dynamic,
e.g. if we see JBP app use VDFDirContext, else fall back to default.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4208870#4208870
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4208870
15 years, 8 months