[JBoss Microcontainer Development] New message: "Re: VFS3 and symlinks"
by Ales Justin
JBoss development,
A new message was posted in the thread "VFS3 and symlinks":
http://community.jboss.org/message/528517#528517
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
* https://jira.jboss.org/jira/browse/JBVFS-138
> The question is.... Do we want to support the notion that they are always the same? I don't think so. I think if you provide the canonical path at mount time, that is what is mounted. If you provide the path with a symlink, that is what is mounted. Otherwise we would have to force it to the canonical path every time, or create mount the same filesystem at multiple mount points.
>
Afais, the fix is simple, simply try to convert every path in VFS::getChild(String path) to canonical path.
I would just put a flag, which would be false by default, if we should really do this for every invocation.
I hacked this already. :-)
But if there is a better way to do this, or if I missed some use case, feel free to fix it.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528517#528517
14 years, 10 months
[JBoss Microcontainer Development] New message: "VFS3 and symlinks"
by Ales Justin
JBoss development,
A new message was posted in the thread "VFS3 and symlinks":
http://community.jboss.org/message/528510#528510
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
Me:> Symlinks also don't work with VFS3 -- see added SymlinkTestCase test.
JohnB:
> I think the problem here is how the mounting is happening. Your test is mounting the EARs/JARs using the canonical path. So they are showing up in the VFS with the full non-symlinked path. Then when you test the URL you are providing the path with a symlink. It won't work is this mixed style as they are separate paths in the VFS. If you mount the EAR given the symlinked path, the test works fine as the path is used in the VFS and you can then continue to use the symlinked path from then on.
>
> The question is.... Do we want to support the notion that they are always the same? I don't think so. I think if you provide the canonical path at mount time, that is what is mounted. If you provide the path with a symlink, that is what is mounted. Otherwise we would have to force it to the canonical path every time, or create mount the same filesystem at multiple mount points.
>
> Thoughts?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528510#528510
14 years, 10 months
[jBPM Development] New message: "Re: jBPM4 History/Log implementation."
by Arul Kalai
JBoss development,
A new message was posted in the thread "jBPM4 History/Log implementation.":
http://community.jboss.org/message/528392#528392
Author : Arul Kalai
Profile : http://community.jboss.org/people/Kalairajan
Message:
--------------------------------------------------------------
Bug !!!
org.jbpm.pvm.internal.history.model.HistoryTaskImpl
Newly created HistoryDetail is not added to the collection of the HistoryTaskImpl(Highlighted).
public void updated(TaskImpl task) {
if ( (assignee==null && task.getAssignee()!=null)
|| (assignee!=null) && (!assignee.equals(task.getAssignee()))
) {
addDetail(new HistoryTaskAssignmentImpl(assignee, task.getAssignee()));
this.assignee = task.getAssignee();
}
if (priority!=task.getPriority()) {
addDetail(new HistoryPriorityUpdateImpl(priority, task.getPriority()));
this.priority = task.getPriority();
}
if ( (duedate==null && task.getDuedate()!=null)
|| (duedate!=null) && (!duedate.equals(task.getDuedate()))
) {
addDetail(new HistoryTaskDuedateUpdateImpl(duedate, task.getDuedate()));
this.duedate = task.getDuedate();
}
}
// details //////////////////////////////////////////////////////////////////
public void addDetail(HistoryDetailImpl detail) {
detail.setHistoryTask(this, nextDetailIndex);
*details.add(detail);*
nextDetailIndex++;
}
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528392#528392
14 years, 10 months
[JCA Development] New message: "Re: Standalone JCA: JNDI binding for multiple connection factories..."
by Jesper Pedersen
JBoss 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
14 years, 10 months
[JCA Development] New message: "Re: JBJCA-290: Make ant task for validate tool"
by Jesper Pedersen
JBoss 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
14 years, 10 months