3:38 p.m.
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 <bmcwhirt(a)redhat.com> wrote:
TorqueBox allows deployment of .yaml files. It's pluggable
enough.
Bob
On Wed, Jan 11, 2017 at 3:32 PM Stuart Douglas <stuart.w.douglas(a)gmail.com>
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 <rareddy(a)redhat.com> 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 <rareddy(a)redhat.com>
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
>
>
> > > wildfly-dev(a)lists.jboss.org
>
>
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> >
>
>
> > --
>
>
> > Brian Stansberry
>
>
> > Manager, Senior Principal Software Engineer
>
>
> > JBoss by Red Hat
>
>
> >
>
>
> >
>
>
> >
>
>
> >
>
>
> > _______________________________________________
>
>
> > wildfly-dev mailing list
>
>
> > wildfly-dev(a)lists.jboss.org
>
>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
>
>
> wildfly-dev mailing list
>
>
> wildfly-dev(a)lists.jboss.org
>
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
>
> wildfly-dev mailing list
>
> wildfly-dev(a)lists.jboss.org
>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev