[JCA Development] New message: "Re: Standalone JCA: JNDI binding for multiple connection factories..."
by Jesper Pedersen
User development,
A new message was posted in the thread "Standalone JCA: JNDI binding for multiple connection factories...":
http://community.jboss.org/message/528357#528357
Author : Jesper Pedersen
Profile : http://community.jboss.org/people/jesper.pedersen
Message:
--------------------------------------------------------------
> I assume that we need to handle JNDI binding connection factories that
> are serializable but don't implement Referenceable. If anyone knows
> otherwise, please speak up. For the serializable case, we will bind
> the CF directly to JNDI.
It is a requirement that a CF implements the javax.resource.Referenceable and java.io.Serializable - so that will always be the case. Hence the current instanceof check.
Dealing with resource adapters that doesn't implement this requirement could be something we could look at down the road - but ideally people should fix their code. That is why we have the validator.
> In either case, we will bind the CF under the jndi-name either specified
> in configuration or derived from the resource adapter name (minus the
> ".rar"). We should look at any current JNDI naming conventions that
> might make sense to preserve. It seems important to me that we bind
> under the expected name that applications will later use.
An idea could be to create a unique name for each CF, and then create an alias for the unique name that the user will use. That would allow us to move the primary names in the JNDI without having to change any user code. I thinking of java:/eis/, java:global, and other scenarios depending where the JCA container is deployed.
The key is to make it simple for users - a JNDI name should be optional, and in that case we would create an alias based on our default strategy, f.ex. java:/eis/resourceadapter as we have now.
Also we should consider how the deployment of the same resource adapter multiple times - under different names should work. Making the resource adapter archive name part of the unique name could be an idea - we can always use the metadata repository to search for information.
> At the very least, we should log (INFO level) the full jndi name that each CF is bound to.
Agreed.
> I also propose that we consider a logging configuration that controls
> what is logged/monitored in jboss-jca (e.g. whether to log jndi names,
> datasource/cci operations, enable debug wrappers). I'll write more
> about this if others like this idea.
That would be a requirement - currently discussed in TAG. David will probably have a lot of good ideas in near future.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528357#528357
16 years, 1 month
[JCA Development] New message: "Re: JBJCA-290: Make ant task for validate tool"
by Jesper Pedersen
User development,
A new message was posted in the thread "JBJCA-290: Make ant task for validate tool":
http://community.jboss.org/message/528352#528352
Author : Jesper Pedersen
Profile : http://community.jboss.org/people/jesper.pedersen
Message:
--------------------------------------------------------------
I think that we should extract the validator code from deployers/ into its own module (validator/).
Then have only
* jboss-jca-deployers-fungal.jar
* jboss-jca-deployers-mc.jar
in deployers/.
The jboss-jca-validator-*.jar could then depend on jboss-jca-common-impl.jar as the annotation / metadata classes would move to the common/ module.
The validator should be refactored into org.jboss.jca.validator -- and sub-packages.
The validator/ module should of course be built before deployers/ - as the deployers would depend on it.
The validator/ module should have
* jboss-jca-validator.jar (framework)
* jboss-jca-validator-cli.jar (standalone)
* jboss-jca-validator-ant.jar (Ant task)
* jboss-jca-validator-maven.jar (Maven plugin)
Let me know what you think.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528352#528352
16 years, 1 month
[Beginner's Corner] New message: "Error occurs when trying to incorporate Spring/BlazeDS"
by Camron Rushin
User development,
A new message was posted in the thread "Error occurs when trying to incorporate Spring/BlazeDS":
http://community.jboss.org/message/528349#528349
Author : Camron Rushin
Profile : http://community.jboss.org/people/iamcootis
Message:
--------------------------------------------------------------
My app was working fine until I tried to incoroporate Spring using this example http://ria.dzone.com/articles/introduction-spring-blazeds?page=0,2
I am using WTP and a JBoss 5.1.0.GA
Now I am getting this error:
org.jboss.deployers.spi.DeploymentException: Error determining structure: SoyBombs.war
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.vfs.plugins.structure.explicit.DeclaredStructure.determineStructure(DeclaredStructure.java:89)
at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:73)
at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:196)
at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:221)
at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:77)
at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:1004)
at org.jboss.deployers.plugins.main.MainDeployerImpl.determineDeploymentContext(MainDeployerImpl.java:440)
at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:390)
at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:300)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.addDeployment(MainDeployerAdapter.java:86)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:344)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:146)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:170)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.RuntimeException: java.util.zip.ZipException: error in opening zip file
at org.jboss.virtual.plugins.context.AbstractExceptionHandler.handleZipEntriesInitException(AbstractExceptionHandler.java:39)
at org.jboss.virtual.plugins.context.helpers.NamesExceptionHandler.handleZipEntriesInitException(NamesExceptionHandler.java:63)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:626)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.checkIfModified(ZipEntryContext.java:773)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.getChild(ZipEntryContext.java:817)
at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.createChildHandler(ZipEntryHandler.java:191)
at org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:684)
at org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild(ZipEntryHandler.java:165)
at org.jboss.virtual.plugins.context.DelegatingHandler.getChild(DelegatingHandler.java:107)
at org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:481)
at org.jboss.deployers.vfs.plugins.structure.explicit.DeclaredStructure.determineStructure(DeclaredStructure.java:64)
... 20 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:203)
at java.util.zip.ZipFile.<init>(ZipFile.java:234)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.ensureZipFile(ZipFileWrapper.java:175)
at org.jboss.virtual.plugins.context.zip.ZipFileWrapper.acquire(ZipFileWrapper.java:245)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.initEntries(ZipEntryContext.java:484)
at org.jboss.virtual.plugins.context.zip.ZipEntryContext.ensureEntries(ZipEntryContext.java:619)
... 28 more
Any idea what could be wrong?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528349#528349
16 years, 1 month
[JCA Development] New message: "Standalone JCA: JNDI binding for multiple connection factories..."
by Scott Marlow
User development,
A new message was posted in the thread "Standalone JCA: JNDI binding for multiple connection factories...":
http://community.jboss.org/message/528344#528344
Author : Scott Marlow
Profile : http://community.jboss.org/people/smarlow@redhat.com
Message:
--------------------------------------------------------------
RADeployer needs to deal with outbound resource adapters that have multiple connection factories (each of which should be bound to JNDI).
For the JNDI binding, if the connection factory is a javax.resource.Referenceable, we will bind a javax.naming.Reference to JNDI. The Reference represents the CF along with javax.naming.StringRefAddr values that contain configuration settings. This is currently working in jboss-jca/trunk with a simple single CF design. This note is about expanding our support to cover binding multiple CFs to jndi and other gap filling.
I assume that we need to handle JNDI binding connection factories that are serializable but don't implement Referenceable. If anyone knows otherwise, please speak up. For the serializable case, we will bind the CF directly to JNDI.
In either case, we will bind the CF under the jndi-name either specified in configuration or derived from the resource adapter name (minus the ".rar"). We should look at any current JNDI naming conventions that might make sense to preserve. It seems important to me that we bind under the expected name that applications will later use.
At the very least, we should log (INFO level) the full jndi name that each CF is bound to. I also propose that we consider a logging configuration that controls what is logged/monitored in jboss-jca (e.g. whether to log jndi names, datasource/cci operations, enable debug wrappers). I'll write more about this if others like this idea.
Comments?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528344#528344
16 years, 1 month