[Design of JCA on JBoss] - Re: JBAS-5023
by vickyk
"jesper.pedersen" wrote : Vicky, do you have some cycles to complete this task ?
Yes I have started looking into this .
Ales , I have been trying to figure out for the changes to be made in the RAR deployers so was trying to build and run the test from here
http://anonsvn.jboss.org/repos/jbossas/projects/jboss-deployers/trunk
I do get this error
C:\Documents and Settings\Vicky.JBOSS-VICKY\workspace\jboss-deployers>mvn instal
| l
| [INFO] Scanning for projects...
| [INFO] Reactor build order:
| [INFO] JBoss Deployers Build
| [INFO] JBoss Deployers Core SPI
| [INFO] JBoss Deployers Core
| [INFO] JBoss Deployers Client SPI
| [INFO] JBoss Deployers Client
| [INFO] JBoss Deployers Structure SPI
| [INFO] JBoss Deployers SPI
| [INFO] JBoss Deployers Impl
| [INFO] JBoss Deployers VFS SPI
| [INFO] JBoss Deployers VFS
| [INFO] JBoss Deployers Aggregator
| WAGON_VERSION: 1.0-beta-2
| [INFO] -------------------------------------------------------------------------
| ---
| [INFO] Building JBoss Deployers Build
| [INFO] task-segment: [install]
| [INFO] -------------------------------------------------------------------------
| ---
| Downloading: http://repo1.maven.org/maven2/org/jboss/maven/plugins/maven-jboss-d
| eploy-plugin/1.6/maven-jboss-deploy-plugin-1.6.jar
| [INFO] ------------------------------------------------------------------------
| [ERROR] BUILD FAILURE
| [INFO] ------------------------------------------------------------------------
| [INFO] A required plugin was not found: Plugin could not be found - check that t
| he goal name is correct: Unable to download the artifact from any repository
|
| Try downloading the file manually from the project website.
|
| Then, install it using the command:
| mvn install:install-file -DgroupId=org.jboss.maven.plugins -DartifactId=mave
| n-jboss-deploy-plugin \
| -Dversion=1.6 -Dpackaging=maven-plugin -Dfile=/path/to/file
| Alternatively, if you host your own repository you can deploy the file there:
| mvn deploy:deploy-file -DgroupId=org.jboss.maven.plugins -DartifactId=maven-jb
| oss-deploy-plugin \
| -Dversion=1.6 -Dpackaging=maven-plugin -Dfile=/path/to/file \
| -Durl=[url] -DrepositoryId=[id]
|
|
| org.jboss.maven.plugins:maven-jboss-deploy-plugin:maven-plugin:1.6
|
| from the specified remote repositories:
| central (http://repo1.maven.org/maven2)
|
| org.jboss.maven.plugins:maven-jboss-deploy-plugin:maven-plugin:1.6
|
| from the specified remote repositories:
| central (http://repo1.maven.org/maven2)
|
| [INFO] ------------------------------------------------------------------------
| [INFO] For more information, run Maven with the -e switch
| [INFO] ------------------------------------------------------------------------
| [INFO] Total time: 5 seconds
| [INFO] Finished at: Tue May 20 23:22:11 IST 2008
| [INFO] Final Memory: 5M/10M
| [INFO] ------------------------------------------------------------------------
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152099#4152099
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152099
18 years
[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?
by mark.little＠jboss.com
"maeste" wrote : "mark.little(a)jboss.com" wrote : We should definitely be storing the entire message. I'd suggest adding some option (maybe on the message) that indicates the duration for which it can be stored and, when it gets deleted by the store, we should have a "grave stone" (marker) for it so that we don't break referential integrity.
| |
|
| Is really it a responsibility you would leave totally in charge to message?
| Isn't it a governance responsibility?
|
It's both. There will be some messages that users will refuse (for legal reasons) to allow to be stored. But until we have hooks for governance ...
anonymous wrote :
| I would prefer message is responsible to classify itself in a more abstract manner (maybe some properties?), and leave to repository the decision how longer messages have to be stored.
|
ok
anonymous wrote :
| DNA could in fact classify messages, on properties base, and (maybe) refine this classification using metadata extracted by sequencer. This way drive to put configuration about repository at a different (higher) tier, where the decision of how long we keep them could depend also on which kind of use we would do of them (of course different kinds of analysis need different store duration).
| Of course it's just my humble opinion.
We definitely need some way of defining this as a policy across different "types" of messages, users and scenarios. Plus the capability to say "do not store" (I think we may have that already).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152080#4152080
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152080
18 years
[Design the new POJO MicroContainer] - Autowire bug on existing target
by alesj
I found a bug on my autowiring code. :-)
In case you provide an existing instance when installing bean metadata into Controller (Controller.install(bmd, myinstance)), that instance won't be part of matching contexts since the code that strips down the instance into its class, superclasses, interfaces, ... is in InstantiateAction.
And we skip that action when target already exists.
I'm thinking of adding something like
| public class AutowireAction extends InstallsAwareAction
| {
| protected void installActionInternal(KernelControllerContext context) throws Throwable
| {
| KernelController controller = (KernelController)context.getController();
| DependencyInfo dependencyInfo = context.getDependencyInfo();
| if (dependencyInfo != null && dependencyInfo.isAutowireCandidate())
| controller.addInstantiatedContext(context);
| }
|
| protected void uninstallActionInternal(KernelControllerContext context)
| {
| try
| {
| KernelController controller = (KernelController)context.getController();
| DependencyInfo dependencyInfo = context.getDependencyInfo();
| if (dependencyInfo != null && dependencyInfo.isAutowireCandidate())
| controller.removeInstantiatedContext(context);
| }
| catch (Throwable ignored)
| {
| log.debug("Ignored error unsetting context ", ignored);
| }
| }
|
| protected ControllerState getState()
| {
| return ControllerState.INSTANTIATED;
| }
|
| protected Class<? extends KernelControllerContextAware> getActionAwareInterface()
| {
| return InstantiateKernelControllerContextAware.class;
| }
| }
and then fix the KernelControllerContextActions to have this
| actions.put(ControllerState.INSTANTIATED, new AutowireAction());
|
And this also addresses this issue, e.g. you wanted to have some install callback in INSTANTIATE action, that wouldn't be triggered either, since we would skip that state. ;-)
OK?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152071#4152071
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152071
18 years
[Design of JBoss ESB] - Re: JCRMessageStoreImpl store only message body?
by maeste
"mark.little(a)jboss.com" wrote : We should definitely be storing the entire message. I'd suggest adding some option (maybe on the message) that indicates the duration for which it can be stored and, when it gets deleted by the store, we should have a "grave stone" (marker) for it so that we don't break referential integrity.
|
Is really it a responsibility you would leave totally in charge to message? Isn't it a governance responsibility?
I would prefer message is responsible to classify itself in a more abstract manner (maybe some properties?), and leave to repository the decision how longer messages have to be stored.
DNA could in fact classify messages, on properties base, and (maybe) refine this classification using metadata extracted by sequencer. This way drive to put configuration about repository at a different (higher) tier, where the decision of how long we keep them could depend also on which kind of use we would do of them (of course different kinds of analysis need different store duration).
Of course it's just my humble opinion.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4152059#4152059
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4152059
18 years