Quantcast

Deployment Root type other than XML or ZIP

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Deployment Root type other than XML or ZIP

Ramesh Reddy
Hi,

For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB (zip archive) file to define a virtual database artifact. We are planning to deliver a feature where a virtual database is written in DDL, for this we would like to deploy a file artifact like "foo-vdb.ddl".

I have written deployment processors for it, and added DEPLOYMENT_ROOT mounter to recognize the deployment artifact etc, however during the deployment scanning, WildFly always looks at anything other than ".xml" file as zip archive, or a exploded zip archive, so that it can do VFS mount on that file. I would like to add this ".ddl" extension file exactly similar to ".xml" file. Is there any way to achieve this?

Thank you.

Ramesh..
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Brian Stansberry
I’ll defer to our deployment processing gurus re the mount question.

As an aside though, for this to work with the deployment-scanner subsystem we’ll need to add some logic. Right now it would just ignore the file.

> On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:
>
> Hi,
>
> For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB (zip archive) file to define a virtual database artifact. We are planning to deliver a feature where a virtual database is written in DDL, for this we would like to deploy a file artifact like "foo-vdb.ddl".
>
> I have written deployment processors for it, and added DEPLOYMENT_ROOT mounter to recognize the deployment artifact etc, however during the deployment scanning, WildFly always looks at anything other than ".xml" file as zip archive, or a exploded zip archive, so that it can do VFS mount on that file. I would like to add this ".ddl" extension file exactly similar to ".xml" file. Is there any way to achieve this?
>
> Thank you.
>
> Ramesh..
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Ramesh Reddy
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.

----- Original Message -----

> I’ll defer to our deployment processing gurus re the mount question.
>
> As an aside though, for this to work with the deployment-scanner subsystem
> we’ll need to add some logic. Right now it would just ignore the file.
>
> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:
> >
> > Hi,
> >
> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB
> > (zip archive) file to define a virtual database artifact. We are planning
> > to deliver a feature where a virtual database is written in DDL, for this
> > we would like to deploy a file artifact like "foo-vdb.ddl".
> >
> > I have written deployment processors for it, and added DEPLOYMENT_ROOT
> > mounter to recognize the deployment artifact etc, however during the
> > deployment scanning, WildFly always looks at anything other than ".xml"
> > file as zip archive, or a exploded zip archive, so that it can do VFS
> > mount on that file. I would like to add this ".ddl" extension file exactly
> > similar to ".xml" file. Is there any way to achieve this?
> >
> > Thank you.
> >
> > Ramesh..
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Stuart Douglas
The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).

I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).

Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).

Stuart



On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.

----- Original Message -----
> I’ll defer to our deployment processing gurus re the mount question.
>
> As an aside though, for this to work with the deployment-scanner subsystem
> we’ll need to add some logic. Right now it would just ignore the file.
>
> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:
> >
> > Hi,
> >
> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB
> > (zip archive) file to define a virtual database artifact. We are planning
> > to deliver a feature where a virtual database is written in DDL, for this
> > we would like to deploy a file artifact like "foo-vdb.ddl".
> >
> > I have written deployment processors for it, and added DEPLOYMENT_ROOT
> > mounter to recognize the deployment artifact etc, however during the
> > deployment scanning, WildFly always looks at anything other than ".xml"
> > file as zip archive, or a exploded zip archive, so that it can do VFS
> > mount on that file. I would like to add this ".ddl" extension file exactly
> > similar to ".xml" file. Is there any way to achieve this?
> >
> > Thank you.
> >
> > Ramesh..
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Bob McWhirter
TorqueBox allows deployment of .yaml files. It's pluggable enough. 

Bob

On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).

I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).

Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).

Stuart



On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.





----- Original Message -----


> I’ll defer to our deployment processing gurus re the mount question.


>


> As an aside though, for this to work with the deployment-scanner subsystem


> we’ll need to add some logic. Right now it would just ignore the file.


>


> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:


> >


> > Hi,


> >


> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB


> > (zip archive) file to define a virtual database artifact. We are planning


> > to deliver a feature where a virtual database is written in DDL, for this


> > we would like to deploy a file artifact like "foo-vdb.ddl".


> >


> > I have written deployment processors for it, and added DEPLOYMENT_ROOT


> > mounter to recognize the deployment artifact etc, however during the


> > deployment scanning, WildFly always looks at anything other than ".xml"


> > file as zip archive, or a exploded zip archive, so that it can do VFS


> > mount on that file. I would like to add this ".ddl" extension file exactly


> > similar to ".xml" file. Is there any way to achieve this?


> >


> > Thank you.


> >


> > Ramesh..


> > _______________________________________________


> > wildfly-dev mailing list


> > [hidden email]


> > https://lists.jboss.org/mailman/listinfo/wildfly-dev


>


> --


> Brian Stansberry


> Manager, Senior Principal Software Engineer


> JBoss by Red Hat


>


>


>


>


> _______________________________________________


> wildfly-dev mailing list


> [hidden email]


> https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Stuart Douglas
Ah, I guess you could just install an earlier DUP that attaches the DEPLOYMENT_ROOT yourself, then DeploymentRootMountProcessor will not run.

I'm not sure about the deployment scanner though. I think if you have a .dodeploy file it can attempt to deploy anything, however I can't see any way to make it deploy arbitrary files without a marker file.

Stuart

On Thu, Jan 12, 2017 at 8:09 AM, Bob McWhirter <[hidden email]> wrote:
TorqueBox allows deployment of .yaml files. It's pluggable enough. 

Bob

On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).

I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).

Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).

Stuart



On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.





----- Original Message -----


> I’ll defer to our deployment processing gurus re the mount question.


>


> As an aside though, for this to work with the deployment-scanner subsystem


> we’ll need to add some logic. Right now it would just ignore the file.


>


> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:


> >


> > Hi,


> >


> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB


> > (zip archive) file to define a virtual database artifact. We are planning


> > to deliver a feature where a virtual database is written in DDL, for this


> > we would like to deploy a file artifact like "foo-vdb.ddl".


> >


> > I have written deployment processors for it, and added DEPLOYMENT_ROOT


> > mounter to recognize the deployment artifact etc, however during the


> > deployment scanning, WildFly always looks at anything other than ".xml"


> > file as zip archive, or a exploded zip archive, so that it can do VFS


> > mount on that file. I would like to add this ".ddl" extension file exactly


> > similar to ".xml" file. Is there any way to achieve this?


> >


> > Thank you.


> >


> > Ramesh..


> > _______________________________________________


> > wildfly-dev mailing list


> > [hidden email]


> > https://lists.jboss.org/mailman/listinfo/wildfly-dev


>


> --


> Brian Stansberry


> Manager, Senior Principal Software Engineer


> JBoss by Red Hat


>


>


>


>


> _______________________________________________


> wildfly-dev mailing list


> [hidden email]


> https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Brian Stansberry

> On Jan 11, 2017, at 3:38 PM, Stuart Douglas <[hidden email]> wrote:
>
> Ah, I guess you could just install an earlier DUP that attaches the DEPLOYMENT_ROOT yourself, then DeploymentRootMountProcessor will not run.
>
> I'm not sure about the deployment scanner though. I think if you have a .dodeploy file it can attempt to deploy anything, however I can't see any way to make it deploy arbitrary files without a marker file.
>

Perhaps that is for the best. I was thinking about doing the capability driven thing you mentioned so people can register other types. But the primary point of registering other types would be to register some “file is complete” check handler that could be used to confirm that the file is complete. Without this deploying without a marker is not safe as the scanner can read a partially copied file. I’m not sure any “file is complete” check handler is practical for other file types, and if not just using the marker is the correct behavior.

Perhaps we could just count on java.nio.channels.FileLock for that, but that’s documented as only being advisory and working with a locked file has other limitations.[1]


[1] https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileLock.html#pdep

> Stuart
>
> On Thu, Jan 12, 2017 at 8:09 AM, Bob McWhirter <[hidden email]> wrote:
> TorqueBox allows deployment of .yaml files. It's pluggable enough.
>
> Bob
>
> On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
> The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).
>
> I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).
>
> Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).
>
> Stuart
>
>
>
> On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
> It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.
>
>
>
>
>
> ----- Original Message -----
>
>
> > I’ll defer to our deployment processing gurus re the mount question.
>
>
> >
>
>
> > As an aside though, for this to work with the deployment-scanner subsystem
>
>
> > we’ll need to add some logic. Right now it would just ignore the file.
>
>
> >
>
>
> > > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:
>
>
> > >
>
>
> > > Hi,
>
>
> > >
>
>
> > > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB
>
>
> > > (zip archive) file to define a virtual database artifact. We are planning
>
>
> > > to deliver a feature where a virtual database is written in DDL, for this
>
>
> > > we would like to deploy a file artifact like "foo-vdb.ddl".
>
>
> > >
>
>
> > > I have written deployment processors for it, and added DEPLOYMENT_ROOT
>
>
> > > mounter to recognize the deployment artifact etc, however during the
>
>
> > > deployment scanning, WildFly always looks at anything other than ".xml"
>
>
> > > file as zip archive, or a exploded zip archive, so that it can do VFS
>
>
> > > mount on that file. I would like to add this ".ddl" extension file exactly
>
>
> > > similar to ".xml" file. Is there any way to achieve this?
>
>
> > >
>
>
> > > Thank you.
>
>
> > >
>
>
> > > Ramesh..
>
>
> > > _______________________________________________
>
>
> > > wildfly-dev mailing list
>
>
> > > [hidden email]
>
>
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> >
>
>
> > --
>
>
> > Brian Stansberry
>
>
> > Manager, Senior Principal Software Engineer
>
>
> > JBoss by Red Hat
>
>
> >
>
>
> >
>
>
> >
>
>
> >
>
>
> > _______________________________________________
>
>
> > wildfly-dev mailing list
>
>
> > [hidden email]
>
>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
>
>
> wildfly-dev mailing list
>
>
> [hidden email]
>
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
>
> wildfly-dev mailing list
>
> [hidden email]
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Ramesh Reddy
In reply to this post by Bob McWhirter
Bob,

Can you please point me to your code references for this?

Ramesh..


TorqueBox allows deployment of .yaml files. It's pluggable enough. 

Bob

On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).

I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).

Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).

Stuart



On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.





----- Original Message -----


> I’ll defer to our deployment processing gurus re the mount question.


>


> As an aside though, for this to work with the deployment-scanner subsystem


> we’ll need to add some logic. Right now it would just ignore the file.


>


> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:


> >


> > Hi,


> >


> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB


> > (zip archive) file to define a virtual database artifact. We are planning


> > to deliver a feature where a virtual database is written in DDL, for this


> > we would like to deploy a file artifact like "foo-vdb.ddl".


> >


> > I have written deployment processors for it, and added DEPLOYMENT_ROOT


> > mounter to recognize the deployment artifact etc, however during the


> > deployment scanning, WildFly always looks at anything other than ".xml"


> > file as zip archive, or a exploded zip archive, so that it can do VFS


> > mount on that file. I would like to add this ".ddl" extension file exactly


> > similar to ".xml" file. Is there any way to achieve this?


> >


> > Thank you.


> >


> > Ramesh..


> > _______________________________________________


> > wildfly-dev mailing list


> > [hidden email]


> > https://lists.jboss.org/mailman/listinfo/wildfly-dev


>


> --


> Brian Stansberry


> Manager, Senior Principal Software Engineer


> JBoss by Red Hat


>


>


>


>


> _______________________________________________


> wildfly-dev mailing list


> [hidden email]


> https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Andrig Miller
In reply to this post by Brian Stansberry


On Wed, Jan 11, 2017 at 4:25 PM, Brian Stansberry <[hidden email]> wrote:

> On Jan 11, 2017, at 3:38 PM, Stuart Douglas <[hidden email]> wrote:
>
> Ah, I guess you could just install an earlier DUP that attaches the DEPLOYMENT_ROOT yourself, then DeploymentRootMountProcessor will not run.
>
> I'm not sure about the deployment scanner though. I think if you have a .dodeploy file it can attempt to deploy anything, however I can't see any way to make it deploy arbitrary files without a marker file.
>

Perhaps that is for the best. I was thinking about doing the capability driven thing you mentioned so people can register other types. But the primary point of registering other types would be to register some “file is complete” check handler that could be used to confirm that the file is complete. Without this deploying without a marker is not safe as the scanner can read a partially copied file. I’m not sure any “file is complete” check handler is practical for other file types, and if not just using the marker is the correct behavior.

Perhaps we could just count on java.nio.channels.FileLock for that, but that’s documented as only being advisory and working with a locked file has other limitations.[1]


[1] https://docs.oracle.com/javase/8/docs/api/java/nio/channels/FileLock.html#pdep

​This is advisory, because it depends on a specific POSIX API on LInux/Unix systems, that may or may not be there depending on the underlying file system.  We ran into this with HornetQ, since it relies on this for its journal lock for HA.  The GFS 2 file system didn't have this lock​
 
​so HA for HornetQ didn't work.  We had to implement a native code workaround to use the BSD based API that was functionally the same as the POSIX API.  Eventually the GFS team did add the POSIX API.  It turned out, all the other file systems that have been tested all worked and had the underlying POSIX API support (including NFS).

Andy​


> Stuart
>
> On Thu, Jan 12, 2017 at 8:09 AM, Bob McWhirter <[hidden email]> wrote:
> TorqueBox allows deployment of .yaml files. It's pluggable enough.
>
> Bob
>
> On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
> The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).
>
> I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).
>
> Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).
>
> Stuart
>
>
>
> On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
> It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.
>
>
>
>
>
> ----- Original Message -----
>
>
> > I’ll defer to our deployment processing gurus re the mount question.
>
>
> >
>
>
> > As an aside though, for this to work with the deployment-scanner subsystem
>
>
> > we’ll need to add some logic. Right now it would just ignore the file.
>
>
> >
>
>
> > > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:
>
>
> > >
>
>
> > > Hi,
>
>
> > >
>
>
> > > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB
>
>
> > > (zip archive) file to define a virtual database artifact. We are planning
>
>
> > > to deliver a feature where a virtual database is written in DDL, for this
>
>
> > > we would like to deploy a file artifact like "foo-vdb.ddl".
>
>
> > >
>
>
> > > I have written deployment processors for it, and added DEPLOYMENT_ROOT
>
>
> > > mounter to recognize the deployment artifact etc, however during the
>
>
> > > deployment scanning, WildFly always looks at anything other than ".xml"
>
>
> > > file as zip archive, or a exploded zip archive, so that it can do VFS
>
>
> > > mount on that file. I would like to add this ".ddl" extension file exactly
>
>
> > > similar to ".xml" file. Is there any way to achieve this?
>
>
> > >
>
>
> > > Thank you.
>
>
> > >
>
>
> > > Ramesh..
>
>
> > > _______________________________________________
>
>
> > > wildfly-dev mailing list
>
>
> > > [hidden email]
>
>
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> >
>
>
> > --
>
>
> > Brian Stansberry
>
>
> > Manager, Senior Principal Software Engineer
>
>
> > JBoss by Red Hat
>
>
> >
>
>
> >
>
>
> >
>
>
> >
>
>
> > _______________________________________________
>
>
> > wildfly-dev mailing list
>
>
> > [hidden email]
>
>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
>
>
> wildfly-dev mailing list
>
>
> [hidden email]
>
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> _______________________________________________
>
> wildfly-dev mailing list
>
> [hidden email]
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Deployment Root type other than XML or ZIP

Bob McWhirter
In reply to this post by Ramesh Reddy

On Thu, Jan 12, 2017 at 10:30 AM, Ramesh Reddy <[hidden email]> wrote:
Bob,

Can you please point me to your code references for this?

Ramesh..


TorqueBox allows deployment of .yaml files. It's pluggable enough. 

Bob

On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <[hidden email]> wrote:
The problem with that is that the majority of the time this would be a mistake on the users part (at the moment it is 100% of the time, as we only deploy stuff we know how to process).

I think that ideally this should be pluggable. It would be easy enough to make DeploymentRootMountProcessor handle different file types (for instance add an AttachmentList of known REAL file types, and then install a DUP before it to add .ddl to the list).

Using capabilities and requirements we could probably add something similar to the deployment scanner as well, basically your subsystem would look for the deployment scanner capability, and if it is installed we could have some API to add additional file types (although this may be a bit racey, as the service may not know all file types for the initial scan, which could give odd results in some circumstances. There is probably a solution to this but I can't think of one off the top of my head).

Stuart



On Thu, Jan 12, 2017 at 6:51 AM, Ramesh Reddy <[hidden email]> wrote:
It would be good if the logic can be changed such that any thing other than with extension jar,war,ear and zip to consider them as file based deployments rather than zip archive based deployments.





----- Original Message -----


> I’ll defer to our deployment processing gurus re the mount question.


>


> As an aside though, for this to work with the deployment-scanner subsystem


> we’ll need to add some logic. Right now it would just ignore the file.


>


> > On Jan 11, 2017, at 8:34 AM, Ramesh Reddy <[hidden email]> wrote:


> >


> > Hi,


> >


> > For Teiid project (http://teiid.org), we typically deploy a .xml or .VDB


> > (zip archive) file to define a virtual database artifact. We are planning


> > to deliver a feature where a virtual database is written in DDL, for this


> > we would like to deploy a file artifact like "foo-vdb.ddl".


> >


> > I have written deployment processors for it, and added DEPLOYMENT_ROOT


> > mounter to recognize the deployment artifact etc, however during the


> > deployment scanning, WildFly always looks at anything other than ".xml"


> > file as zip archive, or a exploded zip archive, so that it can do VFS


> > mount on that file. I would like to add this ".ddl" extension file exactly


> > similar to ".xml" file. Is there any way to achieve this?


> >


> > Thank you.


> >


> > Ramesh..


> > _______________________________________________


> > wildfly-dev mailing list


> > [hidden email]


> > https://lists.jboss.org/mailman/listinfo/wildfly-dev


>


> --


> Brian Stansberry


> Manager, Senior Principal Software Engineer


> JBoss by Red Hat


>


>


>


>


> _______________________________________________


> wildfly-dev mailing list


> [hidden email]


> https://lists.jboss.org/mailman/listinfo/wildfly-dev





_______________________________________________


wildfly-dev mailing list


[hidden email]


https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________

wildfly-dev mailing list

[hidden email]

https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...