[JBoss ESB Development] - Re: Synchronous Service Invoker Action
by Kevin.Conner@jboss.com
The PRD contains the following, but not all of it makes sense (for example the calling service does not know *how* it has been invoked nor can the response be received within the context of a transaction).
anonymous wrote : Invoking a service from the action chain of another service, blocking and waiting N amount of time for a response.
| Time-outs handling:
| - If the calling service (the one with the SSI action) is being executed synchronously then it needs to provide an exception back to its waiting client.
| - If the calling service is being executed asynchronously then the message needs to be sent to the Redelivery Service.
| The waiting for a response should still be within the context of a transaction so that a timeout of the SSI action causes a transactional rollback, no message loss due to SSI action timeout.
I think it would be better to have the timeout behaviour configurable, so the action has the option of throwing an exception to the caller or continuing the processing in some way. What do you think?
As for transactions, the action should allow for any encompassing transaction to be suspended (and always resumed on completion) but should not rollback on failure as timeouts are application behaviour.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261060#4261060
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261060
16 years, 5 months
[Embedded JBoss Development] - Re: embedded and bootsrap dependencies
by ALRubinger
Well, that's confined to jboss-bootstrap-api-embedded, which is for the Embedded AS. When we say "the bootstrap project itself", what does that really mean?
* Generic Bootstrap? (Lifecycle and some config w/ minimal dependencies)
* MC Bootstrap (Starts and installs the Kernel)
* AS Bootstrap (AS-specific configs and grammar)
There isn't presently an "Embedded" project with any code now. groupId org.jboss.embedded at the moment contains a build config, an assembly, and test suites. All other code is shuffled off to other components. The reason for this is because I allowed org.jboss.embedded stuff to depend upon AS itself. Embedded AS Bootstrap doesn't need to depend upon AS for anything.
I'm open to an argument that the Embedded Bootstrap belongs under the Embedded groupId. But regardless of where the code lives in SVN or its groupId, we can still do releases of it without affecting the AS.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261046#4261046
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261046
16 years, 5 months
[JBoss Microcontainer Development POJO Server] - Re: Adding a ClassLoader import exclusion filter
by adrian@jboss.org
"jason.greene(a)jboss.com" wrote : "alesj" wrote : You can already do all of these things,
| | most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration.
| |
|
| AFAICS a deployment can only exclude classes that it contains (excludes) or that it exports (excludeExport). A deployment could achieve this by defining all the package requirements for every EE and JBoss API it uses, however this could end up being overly verbose compared to a simple exclusion. What I am talking about would be something like a new excludeImport value which would take precedence over any import (either importAll or via module imports). However, I don't want to add it if this would violate the intentions of the design, or if you guys think it would be a bad practice.
I don't see a problem with it in principle.
If you add an "exclude import filter" to the ClassLoadingMetaData which gets copied
into the ClassLoaderPolicy then it would just be a simple piece of code
that goes directly to loadClassLocally() instead of loadClassFromDomain()
when it matches the filter - and the same for resources/packages.
The only thing it would complicate/break would be the consistency checking of the
ClassLoaderSpace. If one of your imports also has something but you always want
to use your local version then there is a potential for ClassCastException, etc.
in cross classloader calls.
However, if you are using this feature then you've already said you don't want
to share, so presumably you've done the analysis?
Such an analysis can get quite complicated.
e.g. the common problem is people putting a different version of the jaxp classes
in WEB-INF/lib which then has knock on effects if for example you want you're
jaxb stuff to use it rather than the version in the JDK and not get ClassCastExceptions.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261031#4261031
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261031
16 years, 5 months
[JBoss ESB Development] - Re: BaseCertLoginModule Does Not Work?
by h.wolffenbuttel
Hi Daniel,
Thanx for the assistance!
The problem was located in the certlogin-users.properties and certlogin-roles.properties. The username should be:
"CN\=test,\ OU\=test,\ O=\test,\ L=\test,\ ST\=test,\ C\=NL". This means escaping all "," and "=" characters, otherwise the user is not found.
Also the final configuration looks like this:
| <application-policy name = "CertLogin">
| <authentication>
| <login-module code="org.jboss.security.auth.spi.BaseCertLoginModule"
| flag = "required">
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="securityDomain">java:/jaas/CertLogin</module-option>
| <module-option name="verifier">org.jboss.security.auth.certs.AnyCertVerifier</module-option>
| </login-module>
| <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
| flag = "required">
| <module-option name="password-stacking">useFirstPass</module-option>
| <module-option name="defaultUsersProperties">props/certlogin-users.properties</module-option>
| <module-option name="defaultRolesProperties">props/certlogin-roles.properties</module-option>
| <module-option name="usersProperties">props/certlogin-users.properties</module-option>
| <module-option name="rolesProperties">props/certlogin-roles.properties</module-option>
| </login-module>
| </authentication>
| </application-policy>
|
Regards,
Hans
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4261030#4261030
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4261030
16 years, 5 months